plan-feature

name	plan-feature
description	Use when the user says "plan a feature", "design this", "how should we build", or before writing code for any non-trivial feature. Produces an approved task breakdown before implementation begins — plan first, build second.
license	Apache-2.0
metadata	{"authors":["Artem Rozumenko <[e-mail]>"],"version":"0.1.0"}

Feature Planning: Understand → Investigate → Plan → Approve

Core philosophy: plan before you build. The cheapest bugs are the ones you prevent during planning.

The seven steps

1. Understand the request
2. Investigate current state
3. Clarify unknowns
4. Feasibility analysis
5. Define acceptance criteria
6. Implementation plan
7. Get approval

1. Understand the request

Know exactly what's being asked before investigating. Ask yourself:

• What is being requested? (feature, change, improvement)
• Who benefits? (end user, developer, ops)
• Why now? (business driver, user feedback, tech debt)
• What does done look like? (measurable outcome)

If the request is vague, ask clarifying questions before investigating — don't dig into code for a direction that might change.

2. Investigate current state

Understand what exists before proposing changes. Grep for relevant terms, read existing implementation, look for patterns to follow and code to reuse, check git history for prior context. Document what already exists, what needs to change vs. what's new, existing patterns, and technical constraints.

3. Clarify unknowns

Resolve ambiguity before committing to a plan. Common unknowns: scope, integration, performance, security, edge cases. When presenting options to the user, lay out the trade-offs — don't force a pick without context.

4. Feasibility analysis

Assess effort, risk, and trade-offs. Build an impact table (area → impact → files affected), a risk table (risk → likelihood → impact → mitigation), and a dependency list (external, internal, blocking).

5. Define acceptance criteria

Testable definition of done, in Given/When/Then format. Every AC must be pass/fail — no "should be intuitive." Cover happy path, error cases, and edge cases. Include performance criteria when relevant.

6. Implementation plan

Ordered list of tasks with dependencies, grouped into phases. For each task define: what to build (not how — that's the developer's job), interface contract, acceptance criteria it satisfies, and which role owns it (python-dev, js-dev, qa-engineer). Call out parallel opportunities and the critical path.

7. Get approval

Alignment before implementation begins. Present summary, scope, task count, top risks, dependencies, acceptance criteria, and the plan. Ask explicitly: "Ready to proceed?" Don't start implementation until approved — plans are cheap, implementation is expensive.

Templates & recipes

All the investigation commands, feasibility table layouts, AC format, plan template, and approval presentation live in references/templates.md. Load that file when you need the exact format.

Anti-Patterns

• Don't plan in a vacuum — investigate the codebase first
• Don't propose solutions without understanding constraints
• Don't skip acceptance criteria — they're the contract with the developer
• Don't create monolithic tasks — break into parallel-friendly pieces
• Don't assume requirements — ask when ambiguous