aidlc-requirements

Como usar

Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
Consulte no original as ferramentas, credenciais e ambientes necessários.
Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.

npx skills add https://github.com/aws-samples/sample-aidlc-decisions-driven-skill --skill aidlc-requirements

Antes de começar

A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.

Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

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