Requirements are hypotheses about what will solve a problem. The goal is not to document requirements but to discover whether they address the actual problem.
MUST NOT discuss architecture or implementation until requirements are validated. Use /empire-dev:shape only after reaching RA5.
SHOULD read CONTEXT.md at repo root before proceeding — use its vocabulary verbatim; never substitute synonyms.
SHOULD scan docs/adr/ for decisions in the area under analysis — respect accepted ADRs; do not re-litigate closed decisions.
If neither exists, proceed without them. Do not create these files unprompted.
RA0: No Problem Statement
Symptoms: Starting with "I want to build X" (solution, not problem). Can't articulate who has what problem. "Everyone needs this" reasoning. Feature list without problem grounding. Copying existing solutions without understanding why they exist.
Key questions: What happens if this doesn't exist? Who suffers? What are people doing today instead? What triggered you thinking about this now?
Interventions: Jobs-to-be-Done interview: "When I [situation], I want to [motivation], so I can [outcome]." Problem archaeology: trace the idea back to a specific frustration. "Five users" test: name 5 specific people who would benefit.
RA1: Solution-First Thinking
Symptoms: Requirements describe implementation ("needs a database", "should use React"). Can't explain requirements without referencing technology. Answering "what" with "how." Technology choice before problem clarity.
Key questions: If that technology didn't exist, what would you need? What outcome does this feature produce? Are you solving YOUR problem or copying someone else's solution?
Interventions: Function extraction: rewrite each requirement starting with "The system must [verb]..." without technology words. "Remove the solution" exercise: describe the need without ANY implementation. Constraint vs. preference distinction: is this technology required, or just familiar?
RA2: Vague Needs
Symptoms: "Users should be able to..." without specifics. Requirements that can't be tested. Adjective requirements: "fast", "easy", "intuitive", "modern." No acceptance criteria imaginable. Can't describe what "done" looks like.
Key questions: How would you know if this requirement is met? What's the minimum that would satisfy this need? Can you give a specific example scenario?
Interventions: Specificity ladder: who specifically? doing what specifically? when specifically? Acceptance scenario writing: "Given X, when Y, then Z." Testability check: if you can't test it, you don't understand it yet.
RA3: Hidden Constraints
Symptoms: Discovering blockers mid-implementation. "Oh, I forgot to mention..." Assumptions treated as facts. Surprise dependencies appearing late.
Key questions: What's definitely true about this context (real constraints)? What are you assuming is true (assumptions to validate)? What resources/skills/time do you actually have? What external dependencies exist?
Interventions: Constraint inventory: list budget, time, skills, dependencies, integrations. Assumption mapping: validated vs. unvalidated. Risk pre-mortem: "It's 6 months later and this failed. Why?" Dependency discovery: what must exist before this can work?
RA4: Scope Creep
Symptoms: Requirements expanding faster than they're satisfied. "While we're at it..." additions. Can't distinguish core from nice-to-have. No clear boundary between V1 and future. Every feature feels equally important.
Key questions: What's the smallest thing that would be useful? What could you cut and still solve the core problem? If you could only ship 3 things, what are they? What triggers reconsidering deferred items?
Interventions: MoSCoW prioritization: Must / Should / Could / Won't. Walking skeleton identification: thinnest useful version. Force-rank exercise: strict ordering, no ties. Cut-first approach: start with everything out, add back only what's essential.
RA5: Requirements Validated
Indicators: Problem articulated without mentioning solutions. Each requirement has acceptance criteria. Constraint inventory separates facts from assumptions. V1 boundary is explicit with deferred items listed. You know what would make the requirements wrong.
Next step: Hand off to /empire-dev:shape with Validated Requirements Document.
Problem discovery: What's the problem? Who has it (be specific)? What do they do today without this? What triggered this idea?
Need clarification: What must the solution accomplish? How would you know if it's working? What's the minimum viable version?
Constraint discovery: What's your actual time budget? What skills do you have / need? What must this integrate with? What assumptions haven't you validated? What would kill the project?
Scope definition: What's in V1 vs. later? What would you cut if forced? What triggers reconsidering deferred items? What's explicitly NOT in scope?
The Solution Specification — requirements that describe implementation, not needs. "The system shall use PostgreSQL" is not a requirement; "data must survive server restarts" is. Fix: for each requirement, ask "could this be satisfied a different way?"
The Stakeholder Fiction — solo developer imagining requirements instead of discovering them. Fix: if you're the user, be honest about YOUR needs. Don't invent users.
The Infinite Backlog — everything is equally important. Fix: force-rank. If you could only ship ONE thing, what is it?
The Premature Precision — specifying details that don't matter yet. Fix: identify which requirements need precision now vs. can be deferred.
The Constraint Blindness — not inventorying real constraints, then hitting them mid-build. Fix: explicit constraint inventory BEFORE requirements.
The Feature Transplant — copying features from existing products without understanding if they solve YOUR problem. Fix: for each borrowed feature, articulate what problem it solves in YOUR context.
