What problem does it solve? Structural choices in a codebase lose their rationale over time, leaving future contributors asking why a library, boundary, or convention was chosen. This Skill captures those decisions as terse, immutable Architecture Decision Records (ADRs) so the reasoning survives team changes and parallel work. ## Core Features & Use Cases - Collision-free ADR files: Each decision owns one Markdown file named with an ISO date, readable slug, and UUID, so parallel contributors never coordinate over a shared counter or index. - Structured decision format: A terse frontmatter-plus-sections template records context, decision, consequences, at least two rejected alternatives, and concrete reversal cost. - Lifecycle and supersession: Records move through proposed, accepted, deprecated, and superseded states; accepted content is immutable and reversals happen only through a new superseding ADR. - Use Case: When adopting Server Actions for UI mutations, create an ADR documenting why tRPC and REST endpoints were rejected, the negative consequences accepted, and the migration cost of reversing the choice. ## Quick Start Ask the agent to write an ADR for the architectural decision you just made, including the alternatives you rejected and the cost of reversing it.
