// Use when a new feature request, bug report, or work request needs requirements defined before implementation
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when code quality needs improvement after implementation, without changing behavior
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review
Use when requirements exist and a technical design is needed before implementation begins
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
| name | define |
| description | Use when a new feature request, bug report, or work request needs requirements defined before implementation |
Define requirements by interviewing the user. The interview IS the value — a requirements doc produced without conversation is just guessing.
Core principle: Ask, don't assume. Every assumption is a question you didn't ask.
Use AskUserQuestion with multiple-choice options where possible.
You MUST ask questions. You MUST NOT produce requirements without interviewing.
Cover these areas, one question per turn:
| Area | What to Ask |
|---|---|
| Scope | What should this do? What should it NOT do? |
| Personas | Who uses this? What's their context/skill level? |
| Success | How will we know it works? What does "done" look like? |
| Edge cases | What happens with empty/invalid/unexpected input? |
| Constraints | Backward compat? Performance? Dependencies? |
After each area, summarize what you heard (200-300 words) and ask the user to confirm before moving on.
Use INVEST format. Each story must be:
Template:
### Story N: [Title]
**As a** [persona from interview],
**I want** [functionality],
**So that** [benefit].
#### Acceptance Criteria
```gherkin
Given [context]
When [action]
Then [expected result]
Given [edge case context]
When [action]
Then [expected handling]
Present stories to user for validation before finalizing.
### 4. Save and Commit
Ask user for a short name, or derive from the topic.
docs/plans/YYYY-MM-DD--requirements.md
Commit: `docs: add <name> requirements`
### 5. Next Step
> Requirements saved. When ready, use `/architect` to design the solution.
## Common Mistakes
| Mistake | Fix |
|---------|-----|
| Producing requirements without interviewing | STOP. Ask questions first. Always. |
| Asking multiple questions at once | One question per `AskUserQuestion` call |
| Including implementation/architecture details | Stay in problem space. Code design is `/architect`'s job. |
| Listing "open questions" without asking them | If it's a question, ASK the user |
| Using FR-1/AC-1.1 format instead of user stories | Use "As a [persona]..." with Gherkin criteria |
| Assuming scope instead of scoping with user | Every assumption is a question you skipped |
| Massive document from a one-line request | Interview to right-size. Small request may mean small scope. |