add-feature

name	add-feature
description	Implements a new feature in react-gts-app using a dialogue-first workflow: researches the codebase, asks one clarifying question at a time, explores 2–3 approaches with trade-offs, validates the chosen design section-by-section, then implements after approval. Use when implementing new functionality or a significant change.
user-invocable	true
disable-model-invocation	true
argument-hint	<feature description>
effort	high

Add Feature

Feature request: $ARGUMENTS

Phase 1: Understand

• Read AGENTS.md + the relevant files under example/src/.
• Find similar existing implementations as reference (App.tsx, App.test.tsx, reportWebVitals.ts).
• Identify all files that would be affected — including co-located tests and CSS.
• Note the RTL query priority used in existing tests (getByRole > getByText > getByTestId).

Phase 2: Clarify (one question at a time)

Ask focused questions one at a time. Prefer multi-choice over open-ended. Topics to cover (skip any resolved by Phase 1 or by $ARGUMENTS):

• Scope boundaries — what's in and out.
• UI / UX decisions — placement, interaction, accessibility.
• Edge cases and error handling.
• Integration points — where does this hook into <App />?
• Testing strategy — what behavior to cover.

Do not batch bullets. One question per message.

Phase 3: Explore Approaches

Propose 2–3 approaches with trade-offs. Lead with a recommendation.

I see three directions here:

**Option A: [name]** (recommended)
- how it works: …
- pros: …
- cons: …

**Option B: [name]**
- how it works: …
- pros: …
- cons: …

Which direction appeals to you?

Phase 4: Design (incremental validation)

Once an approach is selected, present the design in 200–300 word sections and ask after each whether it looks right. Cover:

• Component placement and composition.
• State management (local useState / lifted / context).
• Data flow.
• Error handling and loading states.
• Testing strategy (which RTL queries, which behaviors to cover).

Be ready to backtrack if something doesn't make sense.

Phase 5: Next Step

Use AskUserQuestion to confirm how to proceed:

{
  "questions": [{
    "question": "Design looks complete. What's next?",
    "header": "Next step",
    "options": [
      {"label": "Enter plan mode", "description": "Native plan mode with approval gate before implementation"},
      {"label": "Start now", "description": "Begin implementing directly"}
    ],
    "multiSelect": false
  }]
}

Phase 6: Implement

• Follow the approved plan step by step.
• After each file write, run /lint (or npm run fix) on the touched file — nothing auto-lints here.
• Write tests alongside implementation (co-located *.test.tsx).
• Before declaring done, run npm test -- --watchAll=false yourself and fix any failures — fix the code, not the test.
• Ask before committing. Do not auto-commit.

Principles

• One question at a time — don't overwhelm.
• Multi-choice preferred when possible.
• YAGNI ruthlessly — remove unnecessary scope.
• Always 2–3 approaches before committing to one.
• Incremental validation — catch misunderstandings early.
• Lead with a recommendation — have an opinion, but let the user decide.