Mode d’emploi
- Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
- Consultez le document original pour les outils, identifiants et environnements requis.
- Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/aws-samples/sample-aidlc-decisions-driven-skill --skill aidlc-requirementsAvant de commencer
- L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
- Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
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
