smithery.ai

sdd-requirements

Generate EARS-formatted requirements for SDD workflow. Use when starting a new feature specification, creating requirements documents, or defining acceptance criteria. Invoked via /sdd-requirements <feature-name>.

First seen Mar 22, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,661 B
  • docs SUMMARY.md 237 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

SDD Requirements Generation

Generate comprehensive, EARS-formatted requirements documents that integrate with the SDD (Spec-Driven Development) workflow.

Prerequisites

Before generating requirements:

  1. Feature must be initialized with sdd-init MCP tool
  2. Check current phase with sdd-status MCP tool
  3. Review project steering documents in .spec/steering/

Workflow

Step 1: Gather Context

  1. Use sdd-status MCP tool to verify feature exists and check current phase
  2. Read project context from .spec/steering/product.md if available
  3. Review the feature description from .spec/specs/{feature}/spec.json

Step 2: Analyze Requirements

Identify and document:

  • Primary user goal: What problem are we solving?
  • Target users: Who will use this feature?
  • Core functionality: What must the system do?
  • Success criteria: How do we know it works?

Step 3: Generate EARS-Formatted Requirements

Use the EARS (Easy Approach to Requirements Syntax) format for all requirements.

EARS Patterns

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

Examples

## 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

Step 4: Structure the Document

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}

Step 5: Validate and Save

After generating requirements:

  1. Ensure all requirements are testable
  2. Verify EARS format is correctly applied
  3. Save to .spec/specs/{feature}/requirements.md
  4. Use sdd-approve MCP tool to mark phase complete when ready

MCP Tool Integration

This 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

Quality Checklist

Before completing requirements:

  • All requirements use EARS format
  • Each requirement is independently testable
  • Acceptance criteria are specific and measurable
  • Security requirements align with OWASP Top 10
  • Performance requirements have specific metrics
  • Requirements are traceable to user stories
  • No ambiguous terms (avoid "should", "may", "might")
  • Each FR has clear acceptance criteria

Steering Document References

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:

  • KISS: Keep requirements simple and unambiguous
  • YAGNI: Only specify what's actually needed now
  • Single Responsibility: Each requirement addresses one concern