write-spec

Write Spec — EARS Format Spec Generator

Generate a complete three-file spec from a feature description, using EARS (Easy Approach to Requirements Syntax) notation for unambiguous acceptance criteria.

What is EARS?

EARS provides five structured patterns for writing testable requirements:

Pattern	Syntax	Use Case
Event-driven	WHEN [event] THE System SHALL [response]	User action triggers
Conditional	IF [condition] THEN THE System SHALL [response]	State-dependent
State	WHILE [state] THE System SHALL [response]	Ongoing behaviors
Feature	WHERE [feature enabled] THE System SHALL [response]	Feature flags
Ubiquitous	THE System SHALL [response]	Always-on behaviors

Instructions

Step 1: Understand the Feature

Read $ARGUMENTS as the feature description. If vague, ask clarifying questions:

• What problem does this solve?
• Who is the user?
• What is explicitly NOT in scope?

Do NOT proceed until scope is confirmed.

Step 2: Determine Spec Location

Check if .kiro/specs/ directory exists. If yes, create the spec there:

.kiro/specs/{feature-name}/
├── requirements.md
├── design.md
└── tasks.md

Otherwise, ask the user where to put the spec.

Step 3: Generate requirements.md

Use the template at ${CLAUDE_SKILL_DIR}/../templates/requirements.md as reference.

Key rules:

• Every acceptance criterion uses EARS format (WHEN/IF/WHILE/WHERE...SHALL)
• Use SHALL (mandatory) vs SHOULD (recommended)
• Include negative cases (WHEN invalid input...)
• One requirement per statement
• Avoid vague terms ("quickly", "efficiently", "user-friendly")
• Include priority labels: P0 (must-have), P1 (should-have), P2 (nice-to-have)

Step 4: Generate design.md

Use the template at ${CLAUDE_SKILL_DIR}/../templates/design.md as reference.

Key rules:

• Use real code for interfaces (TypeScript/Swift/etc.), not pseudocode
• Include Correctness Properties that reference requirement numbers
• Include error handling table
• Include testing strategy

Step 5: Generate tasks.md

Use the template at ${CLAUDE_SKILL_DIR}/../templates/tasks.md as reference.

Key rules:

• Organize into Phases with dependency declarations
• Every task has a testable acceptance criterion
• Mark human-required tasks with [HUMAN] and explain why
• End each task group with _Requirements: X.X, Y.Y_
• Phase-end checkpoints with verification commands
• Max two levels of nesting (Phase → Task)

Step 6: Summary

After generating all three files, show:

1. Total requirements count
2. Total tasks count (AI vs HUMAN)
3. Estimated pipeline modules needed
4. Suggest running /review-spec before proceeding to pipeline