Menú
Create a concise ADR for a durable, consequential architectural decision.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | create-architectural-decision-record |
| description | Create a concise ADR for a durable, consequential architectural decision. |
Use only for a durable, consequential choice with considered alternatives and costly reversal. Keep ordinary implementation decisions in the spec, plan, code, or review evidence.
Derive context, decision, alternatives, and consequences from the task and existing artifacts. Read .ai/current-work.md and related artifacts when the decision originated in tracked work. Ask only for critical missing information; do not invent rationale, alternatives, or stakeholders.
Use a task-provided path. Otherwise use docs/adr/ relative to the repository only when that directory or its convention exists; otherwise ask where to save it. Follow the repository's existing ADR naming convention. Do not write outside the repository root.
Follow the local ADR convention. If none exists, use this minimal format:
# ADR-<nnn>: <decision title>
- **Status**: proposed | accepted | superseded
- **Date**: YYYY-MM-DD
## Context
[Constraint or problem that makes this decision necessary.]
## Decision
[Chosen direction and rationale.]
## Consequences
[Benefits, costs, and follow-up constraints.]
## Alternatives considered
- [Alternative] — [why not chosen]
Use concise, precise language. Preserve real rationale and rejected alternatives. ADRs are append-only history: supersede old ADRs; do not rewrite them.
project-memory — tracked-work context and archive rules.Implement a bounded code change from a request, spec, or implementation plan. Use when executing implementation work and choosing between quick, bounded, and tracked modes.
Manage tracked feature work with `.ai/current-work.md`, handoffs, and archive rules.
Turn a bounded functional spec into an implementation plan. Use when architecture, code structure, sequencing, migration, and verification must be decided before implementation.
Turn current context into a concise implementation spec. Use when a user wants to define what to build, capture requirements, or create a bounded technical/product spec before implementation.
Map a large or unclear initiative into facts, decisions, open frontier, and next work without writing a spec or implementation plan. Use when scope, architecture, dependencies, or sequencing are still genuinely uncertain before creating a spec.
Collapses deterministic multi-step repository research, aggregation, indexing, validation, and transformation into one small purpose-built local script and one Bash run. Use when a task would otherwise require 6+ related read/search/tool calls, iterates over many files or records, cross-references results, or requests batch analysis; do not use for small exploration or broad mutations.