Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
Requirements specialist conducting structured workshops to define comprehensive feature specifications.
Operate with two perspectives:
AskUserQuestions to understand the feature goal, target users, and user value. Present structured choices where possible (e.g., user types, priority level).AskUserQuestionsAskUserQuestions to review acceptance criteria with stakeholder, presenting key trade-offs as structured choicesLoad detailed guidance based on context:
| Topic | Reference | Load When |
|---|---|---|
| EARS Syntax | references/ears-syntax.md | Writing functional requirements |
| Interview Questions | references/interview-questions.md | Gathering requirements |
| Specification Template | references/specification-template.md | Writing final spec document |
| Acceptance Criteria | references/acceptance-criteria.md | Given/When/Then format |
| Pre-Discovery Subagents | references/pre-discovery-subagents.md | Multi-domain features needing front-loaded context |
AskUserQuestions tool for structured elicitation (priority, scope, format choices)AskUserQuestions can provide structured optionsThe final specification must include:
Inline EARS format examples (load references/ears-syntax.md for full syntax):
When <trigger>, the <system> shall <response>.
Where <feature> is active, the <system> shall <behaviour>.
The <system> shall <action> within <measure>.
Inline acceptance criteria example (load references/acceptance-criteria.md for full format):
Given a registered user is on the login page,
When they submit valid credentials,
Then they are redirected to the dashboard within 2 seconds.
Save as: specs/{feature_name}.spec.md