@c0x12c/spartan-ai-toolkit 1.0.1

package/commands/spartan/interview.md

@@ -0,0 +1,154 @@
+---
+name: spartan:interview
+description: Generate Mom Test interview questions — talk about their life, not your idea
+argument-hint: "[product or feature name]"
+---
+
+# Interview Script: {{ args[0] | default: "your product" }}
+
+You are generating a user interview script based on **The Mom Test** by Rob Fitzpatrick.
+
+The core idea: even your mom will lie to you about your startup idea. So don't ask about your idea — ask about their life.
+
+---
+
+## The Mom Test Rules (ALWAYS enforce these)
+
+1. **Talk about their life, not your idea.** Don't pitch. Don't describe what you're building. Ask about what they do today.
+2. **Ask about specifics in the past, not generics or the future.** "Tell me about the last time you..." beats "Would you ever..."
+3. **Talk less, listen more.** If you're talking more than 30% of the time, you're doing it wrong.
+
+---
+
+## Red Flags (print these as warnings in the script)
+
+| Red Flag | What It Really Means | What to Do Instead |
+|---|---|---|
+| "That sounds great!" | They're being polite | Ask: "When was the last time you had this problem?" |
+| "I would definitely use that" | Future promises are worthless | Ask: "What did you do LAST TIME this happened?" |
+| "Yeah, that's a problem" | Generic agreement, no signal | Ask: "Can you walk me through the last time?" |
+| "I'd pay for that" | Talk is cheap | Ask: "How much do you spend on [current solution] now?" |
+| They change the subject | They don't actually care | Note it. This problem isn't top of mind for them. |
+
+---
+
+## Generate the Interview Script
+
+Based on {{ args[0] }}, generate a ready-to-use script. Ask the user first:
+
+> **"In 1-2 sentences, what problem does {{ args[0] }} solve and who has this problem?"**
+
+Then generate the full script:
+
+---
+
+### Opening (~2 min)
+
+**Goal:** Build rapport. Set the frame. Don't bias them.
+
+Script:
+```
+"Thanks for taking the time. I'm trying to understand how people
+deal with [problem area — NOT your solution]. I'm not selling anything.
+I just want to learn about your experience.
+
+There are no right or wrong answers. I'm most interested in stories
+about what you actually do day to day."
+```
+
+**DO NOT** say: "I'm building X and want your feedback." That biases everything.
+
+---
+
+### Group 1: Understanding Their World (5 questions)
+
+**Goal:** Understand their current workflow. What do they do today?
+
+1. "Can you walk me through how you handle [problem area] right now?"
+2. "What does a typical [day/week] look like when you're dealing with this?"
+3. "What tools or processes do you use for this today?"
+4. "What's the most annoying part of how you do this now?"
+5. "If you could wave a magic wand and fix one thing about this, what would it be?"
+
+**For each answer:** Follow up with "Can you give me a specific example?" and "When was the last time that happened?"
+
+---
+
+### Group 2: Finding the Pain (4 questions)
+
+**Goal:** How bad is the problem? Are they actively trying to fix it?
+
+6. "How often does [the problem] come up? Daily? Weekly? Monthly?"
+7. "The last time this happened, what did you do? Walk me through it step by step."
+8. "Have you tried to find a better way to handle this? What did you try?"
+9. "Have you spent any money trying to solve this? How much?"
+
+**Key signal:** If they haven't tried to solve it or spent money on it, the pain might not be bad enough.
+
+---
+
+### Group 3: Checking Importance (5 questions)
+
+**Goal:** Is this a top-3 problem or just a minor annoyance?
+
+10. "Where does this problem rank in your list of headaches? Top 3? Top 10?"
+11. "If this problem disappeared tomorrow, how much would your life change?"
+12. "What other problems compete for your attention and budget right now?"
+13. "Have you ever started fixing this and then stopped? Why?"
+14. "If someone solved this for you, what would that free you up to do?"
+
+**Key signal:** If it's not in their top 3, they won't pay for a solution or change their behavior.
+
+---
+
+### Closing (~2 min)
+
+**Goal:** Get referrals and next steps.
+
+Script:
+```
+"This has been really helpful. A couple more quick things:
+
+- Is there anything about [problem area] that I should have asked
+  but didn't?
+- Do you know 2-3 other people who deal with this same problem?
+  I'd love to talk to them too.
+- Would it be okay if I followed up in a few weeks with a quick update?"
+```
+
+---
+
+## Scoring Rubric
+
+After the interview, score the signal strength:
+
+| Signal | Score | What It Means |
+|---|---|---|
+| They described the problem with emotion and detail | STRONG | Real pain, they care |
+| They've spent money or significant time trying to solve it | STRONG | Willing to pay |
+| They asked YOU when it would be ready | STRONG | Pull signal — they want this |
+| They offered to introduce you to others with the problem | STRONG | They think this matters |
+| They gave generic answers, no specific stories | WEAK | Problem might not be real for them |
+| They were polite but didn't share any struggles | WEAK | No pain here |
+| They said "cool idea" but had no personal experience | NONE | Wrong person or wrong problem |
+
+### After the Interview
+
+Count your signals:
+
+- **3+ STRONG signals** = This problem is real. Keep digging with more interviews.
+- **1-2 STRONG signals** = Promising but need more data. Interview 3-5 more people.
+- **0 STRONG signals** = Wrong person or wrong problem. Try a different audience or rethink.
+
+---
+
+## Output
+
+Show the user:
+1. The complete interview script (ready to print/copy)
+2. The red flags cheat sheet (keep it visible during the interview)
+3. The scoring rubric (fill in after each interview)
+
+**Remind the user:** Talk to at least 5 people before making any decisions. One interview is not enough data.
+
+**Next step:** After 5+ interviews, run `/spartan:validate` to score the idea based on what you learned.

package/commands/spartan/kickoff.md

@@ -0,0 +1,52 @@
+---
+name: spartan:kickoff
+description: "Start a new idea: create project folder, brainstorm, then validate top picks (Stages 1-2)"
+argument-hint: "[theme or problem space]"
+---
+
+# Kickoff: {{ args[0] | default: "new idea" }}
+
+Runs Stage 1 (Brainstorm) and Stage 2 (Validate) back to back.
+Creates the project and gets you to a GO / PASS decision fast.
+
+## Steps
+
+### Setup
+1. Create project folder: `projects/[idea-name]/` with all stage subfolders
+2. Copy project readme template if available
+
+### Stage 1: Brainstorm
+3. Use the `brainstorm` skill
+4. Set the frame: space, target user, limits, goal
+5. Generate 8-15 ideas
+6. Rate each: demand signal, buildability, moat (0-5)
+7. Pick top 3
+8. Save to `01-brainstorm/brainstorm-session-{date}.md`
+
+### Gate 1 Check
+9. Show top 3 to user
+10. Ask: "Which ones should I validate? Or brainstorm more?"
+11. Wait for answer before continuing
+
+### Stage 2: Validate
+12. Use the `idea-validation` skill
+13. For each picked idea:
+    - Problem check (real pain or nice-to-have?)
+    - Quick market check
+    - Quick competitor check (5 min search)
+    - Distribution check
+    - Build check
+14. Give verdict: GO / TEST MORE / PASS
+15. Save to `03-validation/validation-{idea-name}-{date}.md`
+
+### Gate 2 Check
+16. Show verdicts
+17. If any GO: "Want me to run /spartan:deep-dive on this?"
+18. If all PASS: "These didn't make it. Want to /spartan:brainstorm a different space?"
+19. If TEST MORE: "Here's the cheapest test for each. Try those first."
+
+## Rules
+
+- Don't rush through gates. Pause and ask.
+- It's fine if nothing passes. That saves months of building the wrong thing.
+- If the user already has a specific idea (not a theme), skip brainstorm and go straight to validate.

package/commands/spartan/kotlin-service.md

@@ -0,0 +1,109 @@
+---
+name: spartan:kotlin-service
+description: Scaffold a new Kotlin Micronaut microservice following Spartan conventions and company rules
+argument-hint: "[service-name] [brief description]"
+---
+
+You are scaffolding a new Kotlin Micronaut microservice for the Spartan platform.
+
+**Before scaffolding, read these company rules:**
+- `rules/project/ARCHITECTURE_RULES.md` — Layered architecture
+- `rules/project/CORE_RULES.md` — Kotlin conventions
+- `rules/project/DATABASE_RULES.md` — Schema standards
+- `rules/project/API_RULES.md` — API design patterns
+
+## Service: {{ args[0] }}
+## Purpose: {{ args[1] }}
+
+Follow these steps exactly:
+
+### 1. Gather Context
+Ask the user:
+- What domain events does this service produce/consume?
+- What external dependencies (DB, Kafka, Redis, HTTP clients)?
+- What are the main domain entities?
+- Any specific SLA requirements?
+
+**Auto mode on?** → Infer from service name and description. Default: PostgreSQL, no Kafka, no Redis, standard REST. Proceed to scaffold immediately.
+**Auto mode off?** → Wait for answers before proceeding.
+
+### 2. Scaffold Directory Structure
+
+Create the following structure under `src/main/kotlin/com/spartan/{{ args[0] }}/`:
+
+```
+controller/        # @Controller classes, @Secured, @ExecuteOn
+manager/           # Business logic interfaces + implementations (returns Either)
+service/           # External API calls (HTTP clients)
+repository/        # Database access (Exposed ORM)
+model/             # Entities, DTOs, enums, value objects
+config/            # Micronaut configuration classes
+```
+
+### 3. Create Base Files
+
+**build.gradle.kts** — include:
+- io.micronaut:micronaut-http-server-netty
+- org.jetbrains.exposed:exposed-core
+- io.micronaut:micronaut-management
+- kotlinx-coroutines-reactor
+- testcontainers (test scope)
+- kotest or junit5
+
+**application.yml** — with:
+- micronaut.application.name
+- management endpoints (`/health`, `/info`)
+- placeholder for datasource (use env vars: `DATASOURCES_DEFAULT_URL`, etc.)
+
+**Main Application class**:
+```kotlin
+fun main(args: Array<String>) {
+    Micronaut.run(Application::class.java, *args)
+}
+```
+
+**Base error handling** — use Arrow's Either (per CORE_RULES):
+```kotlin
+// All Manager methods return Either<ClientException, T>
+// NEVER use sealed class Result<T> — use Either instead
+// NEVER throw exceptions for business errors
+
+suspend fun findUser(id: UUID): Either<ClientException, UserResponse> {
+    val user = userRepository.findById(id)
+        ?: return UserError.NOT_FOUND.asException().left()
+    return user.toResponse().right()
+}
+```
+
+### 4. Create First Test
+
+Create `src/test/kotlin/.../ApplicationContextTest.kt`:
+```kotlin
+@MicronautTest
+class ApplicationContextTest {
+    @Test
+    fun `application context loads`() { }
+}
+```
+
+### 5. Create Flyway Migration
+
+If PostgreSQL is a dependency:
+- `src/main/resources/db/migration/V1__create_initial_schema.sql`
+- Include base tables for the main domain entities
+
+### 6. Docker Compose for local dev
+
+Create `docker-compose.yml` with:
+- postgres:16 with healthcheck
+- (if Kafka) confluentinc/cp-kafka with zookeeper
+
+### 7. README.md
+
+Include:
+- Service description
+- Local setup instructions
+- Environment variables table
+- Key architectural decisions
+
+After scaffolding, run the TDD skill to write the first domain test.

package/commands/spartan/lean-canvas.md

@@ -0,0 +1,222 @@
+---
+name: spartan:lean-canvas
+description: Fill out a 9-block Lean Canvas one block at a time — end with your riskiest assumptions
+argument-hint: "[product or idea name]"
+---
+
+# Lean Canvas: {{ args[0] | default: "your idea" }}
+
+You are guiding the user through a **Lean Canvas** — one block at a time. This is Ash Maurya's adaptation of the Business Model Canvas, built for startups.
+
+Don't rush through it. Each block matters. Challenge weak answers. Ask follow-up questions.
+
+---
+
+## How This Works
+
+Walk through all 9 blocks in order. For each block:
+1. Explain what it means (one sentence)
+2. Ask the user to fill it in
+3. Challenge weak answers — push for specifics
+4. Move to the next block
+
+**Auto mode on?** → Still do each block as a conversation. The user needs to think about each one. Don't just fill it in for them.
+
+---
+
+## Block 1: PROBLEM
+
+> What are the top 3 problems your target customer has?
+
+Ask the user to list exactly 3 problems. Not 1, not 7 — three.
+
+**Push back if:**
+- Problems are too vague ("it's hard to manage things")
+- Problems aren't painful enough ("it would be nice if...")
+- Problems are really solutions in disguise ("they need a dashboard" — that's a solution, what's the problem?)
+
+Also ask: **"How do they solve each problem today?"** List the existing alternatives next to each problem.
+
+---
+
+## Block 2: CUSTOMER SEGMENTS
+
+> Who has these problems? Be specific.
+
+Ask for:
+- **Target customer:** Describe them. Job title, company size, situation.
+- **Early adopters:** Who has this problem the WORST? Who would try your product even if it's rough?
+
+**Push back if:**
+- "Everyone" or "all businesses" — that's not a segment
+- Too broad — "developers" has millions of sub-segments
+- No early adopter identified — you need to know who your first 10 users are
+
+---
+
+## Block 3: UNIQUE VALUE PROPOSITION
+
+> Single clear message: why are you different and worth buying?
+
+This is the hardest block. The UVP must:
+- Be one sentence
+- A stranger should understand it in 5 seconds
+- Say what you do AND why it matters
+- Not be generic ("best-in-class solution for your needs" — garbage)
+
+**Formula:** [End result customer wants] + [specific time period] + [address their objection]
+**Example:** "Get a clean inbox in 5 minutes a day — no rules to set up"
+
+Ask the user to write it. Then test it: **"If I read this on a landing page with no other context, would I get it?"**
+
+Rewrite together until it passes the 5-second test.
+
+---
+
+## Block 4: SOLUTION
+
+> Top 3 features that solve the top 3 problems.
+
+Map each solution to a problem from Block 1:
+- Problem 1 → Feature A
+- Problem 2 → Feature B
+- Problem 3 → Feature C
+
+**Push back if:**
+- More than 3 features — you're overbuilding v1
+- Features don't clearly map to problems
+- Features are "infrastructure" nobody sees — users care about outcomes, not architecture
+
+---
+
+## Block 5: CHANNELS
+
+> How do you reach your customers?
+
+Ask about each stage:
+- **Awareness:** How do they find out you exist? (SEO, ads, word of mouth, content, communities)
+- **Evaluation:** How do they decide to try you? (free trial, demo, reviews, referrals)
+- **Purchase:** How do they buy? (self-serve, sales call, app store)
+
+**Push back if:**
+- "We'll go viral" — that's not a channel, that's a wish
+- No specific plan — "social media" means nothing without knowing WHICH platform and WHAT content
+- Only paid channels with no budget — SEO and content take months, ads take money
+
+---
+
+## Block 6: REVENUE STREAMS
+
+> How do you make money?
+
+Ask:
+- **Pricing model:** Subscription? One-time? Usage-based? Freemium?
+- **Price point:** What would you charge? What are alternatives charging?
+- **Who pays:** Is the user the buyer, or do they need to convince a boss?
+
+**Push back if:**
+- "We'll figure out monetization later" — at least have a theory
+- Price is wildly different from alternatives with no justification
+- Revenue model doesn't match user behavior (charging subscription for something they use once a year)
+
+---
+
+## Block 7: COST STRUCTURE
+
+> What does it cost to run this business?
+
+Ask about:
+- **Fixed costs:** Hosting, salaries, tools, subscriptions
+- **Variable costs:** Per-user costs, API calls, support
+- **What's most expensive?** Usually it's time (your time building it)
+
+Keep it simple. Ballpark numbers are fine at this stage.
+
+---
+
+## Block 8: KEY METRICS
+
+> What numbers tell you it's working?
+
+Use the **AARRR framework** (Pirate Metrics):
+
+| Metric | Question | Your Number |
+|---|---|---|
+| **Acquisition** | How many people visit/sign up? | |
+| **Activation** | How many have a good first experience? | |
+| **Retention** | How many come back? | |
+| **Revenue** | How many pay? | |
+| **Referral** | How many invite others? | |
+
+**Push back if:**
+- Only tracking vanity metrics (page views, followers)
+- No retention metric — retention is the most important one
+- Too many metrics — pick 1-2 per stage that matter most
+
+---
+
+## Block 9: UNFAIR ADVANTAGE
+
+> What can't be easily copied or bought?
+
+Real unfair advantages:
+- Personal authority / reputation in the space
+- Network effects (product gets better with more users)
+- Community / audience you already have
+- Proprietary data or technology
+- Domain expertise from years in the industry
+- Existing relationships with target customers
+
+**"Nothing" is an honest answer.** Most startups don't have an unfair advantage yet. That's okay — acknowledge it and figure out how to build one over time.
+
+**Push back if:**
+- "Our technology" — code can be copied
+- "First mover" — rarely lasts
+- "Our team" — teams change
+
+---
+
+## Complete Canvas
+
+After all 9 blocks, show the complete canvas in a formatted table:
+
+```
+## Lean Canvas: [product name]
+
+| PROBLEM              | SOLUTION             | UVP                  |
+| 1.                   | 1.                   |                      |
+| 2.                   | 2.                   |                      |
+| 3.                   | 3.                   |                      |
+|                      |                      |                      |
+| Existing alternatives| KEY METRICS          | UNFAIR ADVANTAGE     |
+| -                    |                      |                      |
+| -                    |                      |                      |
+|                      |                      |                      |
+| CHANNELS             | CUSTOMER SEGMENTS    |                      |
+| -                    | Target:              |                      |
+| -                    | Early adopter:       |                      |
+|                      |                      |                      |
+| COST STRUCTURE       | REVENUE STREAMS      |                      |
+| -                    | Model:               |                      |
+| -                    | Price:               |                      |
+```
+
+---
+
+## Top 3 Riskiest Assumptions
+
+After showing the canvas, identify the 3 riskiest assumptions. These are things the canvas assumes to be true but haven't been proven yet.
+
+For each one:
+1. **The assumption:** What are we assuming?
+2. **Why it's risky:** What happens if it's wrong?
+3. **How to test it:** The cheapest, fastest experiment to validate or kill it
+
+**Example:**
+- **Assumption:** "Freelancers will pay $20/month for this"
+- **Risk:** Maybe they use free tools and won't pay
+- **Test:** Put up a landing page with a "Buy" button. See if anyone clicks. Run for 2 weeks.
+
+---
+
+**Next step:** Validate your riskiest assumption first. Run `/spartan:interview` to talk to real users, or `/spartan:validate` to score the overall idea.

package/commands/spartan/map-codebase.md

@@ -0,0 +1,72 @@
+---
+name: spartan:map-codebase
+description: Deep codebase analysis with parallel agents. Produces 7 structured documents covering stack, architecture, conventions, testing, integrations, and concerns. Use before major refactoring, milestone planning, or team onboarding.
+argument-hint: "[optional: focus area e.g. 'auth' or 'api']"
+---
+
+# Map Codebase: {{ args[0] | default: "full analysis" }}
+
+You are performing a **deep codebase analysis** using parallel mapper agents. This produces structured documentation that feeds into GSD planning and execution.
+
+---
+
+## When to Use This vs /spartan:brownfield
+
+| Command | Purpose | Output | Depth |
+|---------|---------|--------|-------|
+| `/spartan:brownfield` | Quick onboarding overview | 1 file: CONTEXT-MAP.md | Surface-level, 10 min |
+| `/spartan:map-codebase` | Deep technical analysis | 7 files in .planning/codebase/ | Thorough, 4 parallel agents |
+
+**Use brownfield** when joining a project for the first time and need a quick overview.
+**Use map-codebase** when preparing for major work: refactoring, new milestone, architecture review, or team onboarding docs.
+
+---
+
+## What Gets Produced
+
+7 documents in `.planning/codebase/`:
+
+| Document | Focus | What It Captures |
+|----------|-------|-----------------|
+| `STACK.md` | Tech | Languages, frameworks, dependencies, build tools, runtime |
+| `INTEGRATIONS.md` | Tech | External APIs, databases, auth providers, webhooks, env vars |
+| `ARCHITECTURE.md` | Architecture | Patterns, layers, data flow, entry points, error handling |
+| `STRUCTURE.md` | Architecture | Directory layout, key file locations, where to add new code |
+| `CONVENTIONS.md` | Quality | Code style, naming patterns, import organization, formatting |
+| `TESTING.md` | Quality | Test framework, patterns, coverage, mocking, fixtures |
+| `CONCERNS.md` | Concerns | Tech debt, known bugs, security risks, fragile areas, scaling limits |
+
+All documents include **file paths in backticks** so Claude can navigate directly to relevant code during planning and execution.
+
+---
+
+## Execution
+
+Delegate to GSD's map-codebase workflow:
+
+**Run this command now:**
+
+```
+/gsd:map-codebase {{ args[0] }}
+```
+
+GSD will:
+1. Check for existing maps in `.planning/codebase/` (offer refresh/skip if found)
+2. Spawn 4 parallel mapper agents (tech, arch, quality, concerns)
+3. Each agent writes documents directly to `.planning/codebase/`
+4. Verify all 7 documents exist and are non-empty
+5. Scan for accidentally leaked secrets
+6. Commit results
+
+---
+
+## After Mapping
+
+Once mapping is complete, suggest next steps based on context:
+
+- **Starting a new project?** → `/spartan:project new` (map feeds into roadmap creation)
+- **Planning a phase?** → `/spartan:phase plan N` (agents read codebase docs automatically)
+- **Major refactoring?** → `/spartan:quickplan "refactor description"` (informed by CONCERNS.md)
+- **Team onboarding?** → Share `.planning/codebase/` docs with new team members
+
+The codebase map is consumed automatically by GSD planning and execution agents — no manual wiring needed.

package/commands/spartan/migration.md

@@ -0,0 +1,82 @@
+---
+name: spartan:migration
+description: Create a database migration script following company DATABASE_RULES (TEXT not VARCHAR, no FK, soft deletes, UUID PKs)
+argument-hint: "[description of the migration]"
+---
+
+Create a migration for: {{ args[0] }}
+
+**Before creating, read:** `rules/project/DATABASE_RULES.md`
+
+## Hard Rules (from DATABASE_RULES)
+- **TEXT not VARCHAR** — always
+- **No REFERENCES / foreign keys** — handle at application level
+- **No CASCADE** — handle deletions in application
+- **UUID primary keys** — `gen_random_uuid()`
+- **Soft delete** — `deleted_at TIMESTAMP`, never hard delete
+- **Standard columns** on every table: `id`, `created_at`, `updated_at`, `deleted_at`
+
+## Steps
+
+1. **Find the next migration version**:
+   ```bash
+   ls src/main/resources/db/migration/ | sort | tail -5
+   ```
+   Use the next version number (e.g., if last is V7, create V8).
+
+2. **Create the migration file**:
+   Path: `src/main/resources/db/migration/V{N}__{snake_case_description}.sql`
+
+3. **Template for new table**:
+```sql
+-- Migration: {{ args[0] }}
+-- Reason: [explain business need]
+
+CREATE TABLE IF NOT EXISTS table_name (
+    id          UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
+    -- business columns here (always TEXT, never VARCHAR)
+    name        TEXT        NOT NULL,
+    status      TEXT        NOT NULL DEFAULT 'active',
+    description TEXT,
+    -- NO REFERENCES / FOREIGN KEYS — handle at application level
+    -- standard columns (required on ALL tables)
+    created_at  TIMESTAMP   NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    updated_at  TIMESTAMP   NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    deleted_at  TIMESTAMP
+);
+
+CREATE INDEX idx_table_name_column ON table_name(column);
+CREATE INDEX idx_table_name_deleted_at ON table_name(deleted_at);
+
+-- Auto-update updated_at trigger
+CREATE OR REPLACE FUNCTION update_updated_at_column()
+RETURNS TRIGGER AS $$
+BEGIN NEW.updated_at = CURRENT_TIMESTAMP; RETURN NEW; END;
+$$ language 'plpgsql';
+
+CREATE TRIGGER update_table_name_updated_at
+    BEFORE UPDATE ON table_name
+    FOR EACH ROW EXECUTE FUNCTION update_updated_at_column();
+
+-- To rollback:
+-- DROP TABLE IF EXISTS table_name;
+```
+
+4. **Template for ALTER TABLE**:
+```sql
+-- Migration: {{ args[0] }}
+
+ALTER TABLE existing_table
+    ADD COLUMN IF NOT EXISTS new_column TEXT,
+    ADD COLUMN IF NOT EXISTS another_col BOOLEAN NOT NULL DEFAULT false;
+
+-- To rollback:
+-- ALTER TABLE existing_table DROP COLUMN IF EXISTS new_column;
+```
+
+5. **After creating, also generate Exposed Table object** using `/database-table-creator` skill if this is a new table.
+
+After creating, verify:
+```bash
+./gradlew flywayValidate
+```