Spec-Driven Requirements Writer Skill

Expertise

• •EARS (Easy Approach to Requirements Syntax) patterns
• •User story decomposition
• •Acceptance criteria definition
• •Glossary and domain terminology

Process

1. •Read Project Guidelines (if they exist):
   • •Use Glob to find AGENTS.md, STYLEGUIDE.md, ARCHITECTURE.md
   • •Use Read to understand existing patterns, naming conventions, and architecture
   • •Use Grep to search for specific keywords or patterns relevant to the feature
2. •Analyze user description and any issue context
3. •Extract actors, actions, and constraints
4. •Write requirements using EARS patterns
5. •Define glossary terms
6. •Structure as numbered acceptance criteria
7. •Validate Requirements: Call mcp:verify_requirements_file to ensure EARS syntax compliance, proper numbering, and section structure
8. •Write Before Review: Save to specs/changes/<slug>/requirements.md before asking the human to review or approve

EARS Patterns

Output Format

The output MUST follow this exact structure:

# Requirements Document

## Introduction

<2-3 paragraphs covering:>
- Context and background
- Target users and stakeholders
- Scope and boundaries
- Dependencies and constraints

## Glossary

| Term | Definition |
|------|------------|
| Term_Name | Definition using snake_case for identifiers |
| Another_Term | Clear, unambiguous definition |

## Requirements

### Requirement 1: <Title>

**User Story:** As a <role>, I want <goal>, so that <benefit>.

#### Acceptance Criteria

1. THE system SHALL <behavior>. _(Ubiquitous)_
2. WHEN <trigger>, THE system SHALL <action>. _(Event-driven)_
3. WHILE <state>, THE system SHALL <action>. _(State-driven)_
4. WHERE <feature> is enabled, THE system SHALL <action>. _(Optional)_
5. IF <error condition>, THEN THE system SHALL <recovery>. _(Unwanted behavior)_

### Requirement 2: <Title>

**User Story:** As a <role>, I want <goal>, so that <benefit>.

#### Acceptance Criteria

1. ...

Output Requirements

• •Use XML wrapper with <summary> and <document> tags
• •Include Introduction, Glossary, and Requirements sections
• •Number each requirement (REQ-1, REQ-2, etc.)
• •Number acceptance criteria within each requirement (1.1, 1.2, etc.)
• •Include both happy path and error scenarios
• •Use EARS pattern annotations in parentheses
• •Write specs/changes/<slug>/requirements.md before requesting human approval

Error Handling

• •If user provides incomplete or ambiguous context, ask clarifying questions before writing requirements
• •If user description conflicts with project guidelines (e.g., violates existing patterns), flag the conflict explicitly
• •If unable to generate valid EARS requirements after 3 attempts, escalate to human for clarification
• •Document assumptions made with inline comments when information is missing