Twelve-Factor Design
Use this skill to design or review an application before implementation or major refactoring. It turns requirements, architecture notes, and platform constraints into a factor-by-factor design review with decisions, risks, evidence needs, and remediation candidates.
Triggers
- "Design this service as a Twelve-Factor app"
- "Review this architecture against 12+ Factor criteria"
- "Generate a cloud-native operational design checklist"
- "Check whether this design is platform portable and observable"
Behavior
- Identify the application boundary: service name, runtime, deployment model, backing services, operators, users, and platform targets.
- Collect available design inputs: requirements, ADRs, API contracts, event schemas, service diagrams, deployment notes, runbooks, test strategy, and security assumptions.
- Review the original Twelve-Factor dimensions: codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.
- Review modern 12+ Factor extensions: API-first contracts, telemetry and observability, security by default, supply-chain provenance, dependency hygiene, runtime disposability, and platform portability.
- For each factor, produce a status of
pass, partial, fail, or not_applicable, with rationale and missing evidence.
- Map factors to requirements, ADRs, tests, code/config paths, and operational artifacts when they exist.
- Generate remediation tasks for gaps that block implementation, readiness review, or continuous audit.
Output
Return a design review with these sections:
- Application boundary and assumptions
- Factor coverage summary
- Factor-by-factor design decisions and risks
- Required evidence for later audit
- Remediation backlog candidates
- Open questions for humans
Examples
Input:
Review the checkout API design for 12+ Factor readiness. Inputs: ADR-004, OpenAPI spec, Dockerfile, Kubernetes deployment, runbook, and CI workflow.
Expected output:
Design status: partial
High-risk gaps: config separation, dev/prod parity, telemetry SLOs
Remediation: externalize payment provider config; add OpenTelemetry trace plan; add ADR for backing-service attachment and failover.
References
- @$AIWG_ROOT/agentic/code/addons/twelve-factor/checklists/design-checklist.md
- @$AIWG_ROOT/agentic/code/addons/twelve-factor/templates/remediation-backlog.md
- @$AIWG_ROOT/agentic/code/addons/twelve-factor/rules/twelve-factor-evidence.md
1---2name: twelve-factor-design3description: Generate or review application architecture against Twelve-Factor and modern 12+ Factor design criteria.4---56# Twelve-Factor Design78Use this skill to design or review an application before implementation or major refactoring. It turns requirements, architecture notes, and platform constraints into a factor-by-factor design review with decisions, risks, evidence needs, and remediation candidates.910## Triggers1112- "Design this service as a Twelve-Factor app"13- "Review this architecture against 12+ Factor criteria"14- "Generate a cloud-native operational design checklist"15- "Check whether this design is platform portable and observable"1617## Behavior18191. Identify the application boundary: service name, runtime, deployment model, backing services, operators, users, and platform targets.202. Collect available design inputs: requirements, ADRs, API contracts, event schemas, service diagrams, deployment notes, runbooks, test strategy, and security assumptions.213. Review the original Twelve-Factor dimensions: codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.224. Review modern 12+ Factor extensions: API-first contracts, telemetry and observability, security by default, supply-chain provenance, dependency hygiene, runtime disposability, and platform portability.235. For each factor, produce a status of `pass`, `partial`, `fail`, or `not_applicable`, with rationale and missing evidence.246. Map factors to requirements, ADRs, tests, code/config paths, and operational artifacts when they exist.257. Generate remediation tasks for gaps that block implementation, readiness review, or continuous audit.2627## Output2829Return a design review with these sections:3031- Application boundary and assumptions32- Factor coverage summary33- Factor-by-factor design decisions and risks34- Required evidence for later audit35- Remediation backlog candidates36- Open questions for humans3738## Examples3940Input:4142```text43Review the checkout API design for 12+ Factor readiness. Inputs: ADR-004, OpenAPI spec, Dockerfile, Kubernetes deployment, runbook, and CI workflow.44```4546Expected output:4748```text49Design status: partial50High-risk gaps: config separation, dev/prod parity, telemetry SLOs51Remediation: externalize payment provider config; add OpenTelemetry trace plan; add ADR for backing-service attachment and failover.52```5354## References5556- @$AIWG_ROOT/agentic/code/addons/twelve-factor/checklists/design-checklist.md57- @$AIWG_ROOT/agentic/code/addons/twelve-factor/templates/remediation-backlog.md58- @$AIWG_ROOT/agentic/code/addons/twelve-factor/rules/twelve-factor-evidence.md