How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/aws-samples/sample-aidlc-decisions-driven-skill --skill aidlc-requirementsBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Requirements Skill
Base:shared/base.md(full on first load, §Summary on chain). Actions: load per-step fromactions/.
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
languagefield) — 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.yamlif it exists - Resolve project context — read only `## Summary` section during init
- If blueprints exist, read Summary sections. Read
resources.mdin 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"→ loadactions/generate.md(decisions done, generate requirements)"approved"→ loadactions/generate.mdrouting-decision section


