Plan a Feature

Self-contained 4-stage workflow. Chain to flutter-implement → grind-until-green when executing.

When to use

• Feature beyond a one-line tweak
• Implementation spans more than a few hours
• You want per-step verification before calling it done

Do not use when

• Trivial fix (typo, copy, single-line guard)
• Emergency hotfix (verify via post-mortem instead)

Optional — grill first

Ask the user one question at a time until the problem, constraints, and success criteria are clear. Explore the codebase instead of asking what code can answer. Provide a recommended answer with each question.

Stage 1: Brainstorm

Input: feature request
Output: short brainstorm doc

Include:

• Problem statement (stranger-test: understandable without prior context)
• 3–5 approaches with pros/cons
• Recommended approach + one plausible alternative rejected
• Top assumptions and risks

Gate: problem is sharp; alternative is plausible.

Stage 2: Implementation plan

Input: chosen approach from Stage 1
Output: step-by-step plan

Include:

• File-level changes (create/modify/delete)
• Order of steps (dependencies first)
• Per-step verification (command or observable outcome)
• Acceptance criteria
• Risks and rollback notes

Gate: every step has explicit verification; another engineer could execute without clarifying questions.

Stage 3: Execute

Input: plan from Stage 2
Use: flutter-implement or implement-tdd per step

Rules:

• One plan step at a time — run its verification before the next
• Record deviations from the plan
• Capture deferred items (do not fix unrelated issues inline)
• High-stakes steps (auth, migrations): run doubt-review first

Gate: every step verification passes.

Stage 4: Verify before shipping

Input: implemented feature + acceptance criteria from Stage 2
Use: grind-until-green for analyze/test loop

Run:

dart format --set-exit-if-changed .
flutter analyze --fatal-infos
flutter test

Check every acceptance criterion — verify or explicitly waive with reason. Document the verification pass.

Gate: all criteria met or waived.

Variations

• Tiny feature: skip Stage 1; collapse Stage 2–3 into a short plan + execute; keep Stage 4
• Multi-PR feature: Stages 1–2 once; Stages 3–4 per PR

Loop-back

• Approach infeasible during Stage 2 → return to Stage 1
• Missing verifications in plan → fix plan before Stage 3
• Repeated verification failures → pause; re-plan or escalate