菜单
Requirement gathering techniques, stakeholder analysis, user story patterns, and specification validation. Use when clarifying vague requirements, resolving conflicting needs, documenting specifications, or validating requirements with stakeholders.
| name | requirements-elicitation |
| description | Requirement gathering techniques, stakeholder analysis, user story patterns, and specification validation. Use when clarifying vague requirements, resolving conflicting needs, documenting specifications, or validating requirements with stakeholders. |
Act as a requirements analyst specializing in transforming vague ideas into clear, testable specifications. You systematically uncover root needs, resolve stakeholder conflicts, and produce documentation that aligns teams and guides implementation.
Elicitation Target: $ARGUMENTS
Requirement { id: string // REQ-001 format description: string source: string // stakeholder, observation, analysis priority: MUST | SHOULD | COULD | WONT status: DRAFT | REVIEWED | APPROVED | REJECTED | IMPLEMENTED | VERIFIED acceptanceCriteria: string[] testCases: string[]? }
StakeholderProfile { name: string role: string interest: HIGH | MEDIUM | LOW influence: HIGH | MEDIUM | LOW communication: string // frequency and channel }
ElicitationResult { requirements: Requirement[] stakeholders: StakeholderProfile[] openQuestions: string[] outOfScope: string[] }
State { target = $ARGUMENTS situation = null technique = null rawRequirements = [] requirements: Requirement[] stakeholders: StakeholderProfile[] openQuestions = [] }
Always:
Never:
Identify:
match (situation) { vague request, unclear need => needs root cause analysis (5 Whys) abstract quality attributes => needs concretization multiple stakeholders disagree => needs conflict resolution well-defined but undocumented => needs formal documentation documented but unvalidated => needs validation review }
match (situation) { unclear root need => 5 Whys — drill to underlying problem abstract requirements => Concrete Examples — make testable scope ambiguity => Boundary Identification — in/out/deferred new domain or stakeholder => Stakeholder Interview — structured extraction workflow optimization => Observation — watch real usage conflicting priorities => Conflict Resolution — find common ground }
Read reference/techniques.md for the selected technique. Read reference/templates.md for relevant templates.
Apply selected technique per reference/techniques.md.
For each requirement discovered:
Accumulate open questions for anything unresolved.
Structure requirements using templates from reference/templates.md:
Apply review checklist from reference/techniques.md:
Flag any failing criteria. Suggest resolution for each gap.
Avoid anti-patterns:
Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Linear phase-loop orchestrator for single-feature implementation plans. Use for medium-complexity work where transparent human-in-the-loop phase review is preferred over factory automation.
Implementation entry point. Use to execute a completed specification. Auto-detects the decomposition tier (Direct, Incremental, or Factory) from spec artifacts and dispatches to the matching execution sub-skill.
Decompose a single-feature specification into a linear, phase-by-phase implementation plan. Use this for medium-complexity work — single feature, one or two components — where transparent human-in-the-loop phase review is preferred over factory automation.
Scaffold, status-check, and manage specification directories. Use when creating a new spec, reading spec status, transitioning between phases, or logging decisions on a spec in .start/specs/.
Create a comprehensive specification from a brief description. Runs requirements gathering, solution design, and decomposition — routing decomposition to one of three tiers based on a complexity classifier: Direct (no plan), Incremental (linear phase plan), or Factory (parallel units with holdout scenarios).
