Architecture decision record

What problem does it solve? Engineering decisions get made and forgotten, leaving future maintainers unable to understand why a choice was made or whether its trade-offs still hold. This Skill structures the writing of an architecture decision record so the reasoning survives long after the decision. ## Core Features & Use Cases - Five-Section Structure: Enforces Context, Options, Decision, Consequences, and Status so every ADR is complete and dated. - Honest Trade-Off Capture: Requires a Consequences section listing costs and ruled-out paths, not just benefits. - Fair Treatment of Rejected Options: Ensures alternatives are described seriously so future readers do not redo the analysis. - Use Case: A team choosing between PostgreSQL and a document store writes an ADR recording the constraints, the options weighed, the one-sentence decision, and what the choice makes harder, so a new engineer two years later can judge whether to revisit it. ## Quick Start Write an architecture decision record for our choice to adopt event sourcing for the billing service, including the rejected alternatives and the costs we accepted.