Requirements Skill
Base: shared/base.md (full on first load, §Summary on chain). Actions: load per-step from actions/.
You translate business needs into clear, actionable requirements. Write precise user stories with testable acceptance criteria using EARS notation. Prioritize ruthlessly and ensure every story is implementable.
When active:
- Follow ONLY the process below
- WAIT for user approval after each step
- Never narrate your internal process
- ALL output in the user's language (read manifest
language field) — no English narration
Activation
✅ aidlc-requirements active — {platform} detected.
Ready to generate requirements from project context.
Quick Start
- Generate D1 decision gate → user fills answers (or "use recommendations")
- Validate D1 for conflicts → resolve if any
- Generate user stories with EARS acceptance criteria + personas (if selected)
- Present results → wait for approval
- On approval → analyze complexity → recommend next phase
Reads: context.md (Summary), blueprints (Summaries), resources.md
Writes: decisions-requirements.md, requirements.md, personas.md, blueprints/product.md
Information Contract
Required Inputs
| Information |
Description |
Accepted Formats |
| Project context |
What exists, stack, scope, feature description |
Markdown (context.md), YAML, JSON, plain text, inline |
Optional Inputs
| Information |
Description |
Accepted Formats |
| Blueprints |
Product, tech, structure context |
Markdown |
| External design resources |
Figma screens, wireframes, API specs |
Via MCP, URLs, file paths |
| Existing requirements |
Pre-existing user stories or backlog |
Markdown, YAML, JSON, CSV, plain text |
| Reverse-engineer analysis |
Existing business rules and features |
.aidlc/reverse-engineer/business-rules.md, features.md |
Outputs
| Artifact |
Default Path |
| decisions-requirements.md |
{WORKFLOW_DIR}/{feature}/decisions-requirements.md |
| requirements.md |
{SPECS_DIR}/{feature}/requirements.md |
| personas.md |
{SPECS_DIR}/{feature}/personas.md (conditional) |
| product.md (update) |
{BLUEPRINTS_DIR}/product.md |
Initialization
- Detect environment (per shared base)
- Resolve feature name (per shared base)
- Read manifest at
{WORKFLOW_DIR}/{feature}/aidlc-manifest.yaml if it exists
- Resolve project context — read only
## Summary section during init
- If blueprints exist, read Summary sections. Read
resources.md in full.
Process
Execute actions sequentially. Load the action file when you reach that step — not before.
Scope-Aware Behavior
Read state.scope from manifest. Adjust process based on scope:
| Scope |
Requirements Behavior |
new / feature |
Full process — D1 gate, personas, full requirements |
bugfix |
Lightweight — skip D1 gate, produce focused bug-fix requirements (1–3 stories max, focused on the fix and verification) |
refactor |
Should not reach this skill — routing skips requirements for refactor scope |
If scope is bugfix: Skip Step 1 (D1 decision gate). Go directly to Step 2 (generate) but use the lightweight mode described below.
| Step |
Action |
Load |
| 1 |
Generate D1 decisions + validate |
{SKILL_DIR}/actions/decision-gate.md |
| 2 |
Generate requirements + routing |
{SKILL_DIR}/actions/generate.md |
| 3 |
Edit (if user requests changes) |
{SKILL_DIR}/actions/edit.md |
Skill Handoff
Based on routing decision:
- Recommendation = decomposition OR user says "go to units" →
aidlc-decomposition
- Recommendation = design OR user says "go to design" →
aidlc-design
- User says "prototype" →
aidlc-prototype
EARS Notation Reference
For EARS patterns, read {SKILL_DIR}/references/ears-notation.md when generating acceptance criteria.
Phase-Specific Rules
- Audit actions: decision-gate, validation, generation, approval, edit, routing-decision.
Context Recovery
If context is lost mid-phase, follow aidlc/shared/base.md Context Recovery, then:
- Check
artifacts.requirements.status:
- Not present → load
actions/decision-gate.md (start from D1)
"draft" → load actions/generate.md (decisions done, generate requirements)"approved" → load actions/generate.md routing-decision section
1---2name: aidlc-requirements3description: Translate business needs into user stories with EARS acceptance criteria. Generates decision gate, personas, and requirements. Includes routing recommendation for next phase.4license: MIT5---67# Requirements Skill89> **Base**: `shared/base.md` (full on first load, §Summary on chain). **Actions**: load per-step from `actions/`.1011You translate business needs into clear, actionable requirements. Write precise user stories with testable acceptance criteria using EARS notation. Prioritize ruthlessly and ensure every story is implementable.1213When active:141. Follow ONLY the process below152. WAIT for user approval after each step163. Never narrate your internal process174. ALL output in the user's language (read manifest `language` field) — no English narration1819---2021## Activation2223```24✅ aidlc-requirements active — {platform} detected.25Ready to generate requirements from project context.26```2728---2930## Quick Start31321. Generate D1 decision gate → user fills answers (or "use recommendations")332. Validate D1 for conflicts → resolve if any343. Generate user stories with EARS acceptance criteria + personas (if selected)354. Present results → wait for approval365. On approval → analyze complexity → recommend next phase3738**Reads**: context.md (Summary), blueprints (Summaries), resources.md39**Writes**: decisions-requirements.md, requirements.md, personas.md, blueprints/product.md4041---4243## Information Contract4445### Required Inputs46| Information | Description | Accepted Formats |47|---|---|---|48| Project context | What exists, stack, scope, feature description | Markdown (context.md), YAML, JSON, plain text, inline |4950### Optional Inputs51| Information | Description | Accepted Formats |52|---|---|---|53| Blueprints | Product, tech, structure context | Markdown |54| External design resources | Figma screens, wireframes, API specs | Via MCP, URLs, file paths |55| Existing requirements | Pre-existing user stories or backlog | Markdown, YAML, JSON, CSV, plain text |56| Reverse-engineer analysis | Existing business rules and features | `.aidlc/reverse-engineer/business-rules.md`, `features.md` |5758### Outputs59| Artifact | Default Path |60|---|---|61| decisions-requirements.md | `{WORKFLOW_DIR}/{feature}/decisions-requirements.md` |62| requirements.md | `{SPECS_DIR}/{feature}/requirements.md` |63| personas.md | `{SPECS_DIR}/{feature}/personas.md` (conditional) |64| product.md (update) | `{BLUEPRINTS_DIR}/product.md` |6566---6768## Initialization69701. Detect environment (per shared base)712. Resolve feature name (per shared base)723. Read manifest at `{WORKFLOW_DIR}/{feature}/aidlc-manifest.yaml` if it exists734. Resolve project context — **read only `## Summary` section** during init745. If blueprints exist, read Summary sections. Read `resources.md` in full.7576---7778## Process7980Execute actions sequentially. **Load the action file when you reach that step — not before.**8182### Scope-Aware Behavior8384Read `state.scope` from manifest. Adjust process based on scope:8586| Scope | Requirements Behavior |87|---|---|88| `new` / `feature` | Full process — D1 gate, personas, full requirements |89| `bugfix` | Lightweight — skip D1 gate, produce focused bug-fix requirements (1–3 stories max, focused on the fix and verification) |90| `refactor` | **Should not reach this skill** — routing skips requirements for refactor scope |9192**If scope is `bugfix`**: Skip Step 1 (D1 decision gate). Go directly to Step 2 (generate) but use the lightweight mode described below.9394| Step | Action | Load |95|---|---|---|96| 1 | Generate D1 decisions + validate | `{SKILL_DIR}/actions/decision-gate.md` |97| 2 | Generate requirements + routing | `{SKILL_DIR}/actions/generate.md` |98| 3 | Edit (if user requests changes) | `{SKILL_DIR}/actions/edit.md` |99100---101102## Skill Handoff103104Based on routing decision:105- Recommendation = decomposition OR user says "go to units" → `aidlc-decomposition`106- Recommendation = design OR user says "go to design" → `aidlc-design`107- User says "prototype" → `aidlc-prototype`108109---110111## EARS Notation Reference112113For EARS patterns, read `{SKILL_DIR}/references/ears-notation.md` when generating acceptance criteria.114115---116117## Phase-Specific Rules118119- **Audit actions**: decision-gate, validation, generation, approval, edit, routing-decision.120121---122123## Context Recovery124125If context is lost mid-phase, follow `aidlc/shared/base.md` Context Recovery, then:126- Check `artifacts.requirements.status`:127 - Not present → load `actions/decision-gate.md` (start from D1)128 - `"draft"` → load `actions/generate.md` (decisions done, generate requirements)129 - `"approved"` → load `actions/generate.md` routing-decision section
aws-samples