From sdd-mcp
Generates EARS-formatted requirements documents for Spec-Driven Development (SDD) workflows. Use for new feature specifications, requirements docs, or acceptance criteria via /sdd-requirements <feature-name>.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sdd-mcp:sdd-requirementsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate comprehensive, EARS-formatted requirements documents that integrate with the SDD (Spec-Driven Development) workflow.
Generate comprehensive, EARS-formatted requirements documents that integrate with the SDD (Spec-Driven Development) workflow.
Before generating requirements:
sdd-init MCP toolsdd-status MCP tool.spec/steering/sdd-status MCP tool to verify feature exists and check current phase.spec/steering/product.md if available.spec/specs/{feature}/spec.jsonIdentify and document:
Use the EARS (Easy Approach to Requirements Syntax) format for all requirements.
| Pattern | Syntax | Use When |
|---|---|---|
| Ubiquitous | The <system> SHALL <action> | Always true requirement |
| Event-Driven | WHEN <trigger> THEN the <system> SHALL <action> | Response to event |
| State-Driven | WHILE <state> THE <system> SHALL <action> | During specific state |
| Optional | WHERE <feature enabled> THE <system> SHALL <action> | Configurable feature |
| Unwanted Behavior | IF <condition> THEN the <system> SHALL <action> | Exception handling |
## FR-1: User Authentication
WHEN a user submits valid credentials
THEN the system SHALL authenticate the user and return a session token
## FR-2: Session Management
WHILE a user session is active
THE system SHALL maintain the session for up to 24 hours of inactivity
## NFR-1: Performance
The system SHALL respond to authentication requests within 200ms
Generate requirements.md with this structure:
# Requirements: {Feature Name}
## Overview
Brief description of the feature and its purpose.
## Functional Requirements
### FR-1: {Requirement Name}
**Objective:** As a {user type}, I want {goal}, so that {benefit}
**EARS Specification:**
WHEN {trigger}
THEN the system SHALL {action}
**Acceptance Criteria:**
1. {Specific, testable criterion}
2. {Specific, testable criterion}
### FR-2: {Next Requirement}
...
## Non-Functional Requirements
### NFR-1: Performance
{Performance requirements with specific metrics}
### NFR-2: Security
{Security requirements aligned with OWASP guidelines}
### NFR-3: Scalability
{Scalability requirements if applicable}
## Constraints
{Technical or business constraints}
## Assumptions
{Assumptions made during requirements gathering}
After generating requirements:
.spec/specs/{feature}/requirements.mdsdd-approve MCP tool to mark phase complete when readyThis skill works with these MCP tools:
| Tool | When to Use |
|---|---|
sdd-status | Check current workflow phase before starting |
sdd-validate-gap | Validate requirements against existing codebase |
sdd-approve | Mark requirements phase as approved |
Before completing requirements:
Apply these steering documents during requirements generation:
| Document | Purpose | Key Application |
|---|---|---|
.spec/steering/principles.md | SOLID, DRY, KISS, YAGNI | Ensure requirements follow KISS (simple, unambiguous) and YAGNI (only what's needed now) |
Key Principles for Requirements:
npx claudepluginhub yi-john-huang/sdd-mcpFormalizes BRD/PRD features into atomic, testable EARS requirements using WHEN-THE-SHALL-WITHIN syntax. Use after BRD and PRD exist.
Drafts or audits SRS with requirement IDs, functional requirements, acceptance criteria, constraints, NFR hooks, and traceability.
Central hub for specification-driven development workflows. Navigates to specialized skills for EARS, Gherkin, Kiro, Spec Kit; supports format conversions, quality checks, and 5-phase Spec Kit workflow.