architectural-decision-recordslisted

# Architectural Decision Records (ADRs) ## Why this skill exists Code shows *what* the system does. It almost never shows *why* it was built that way — why Postgres over DynamoDB, why events instead of synchronous calls, why this auth model, why the retry budget is 3. That "why" is the single most expensive thing to reconstruct later. When it's lost, teams re-litigate settled questions, quietly violate constraints they don't know exist, and rip out load-bearing decisions because nobody recorded the forces behind them. An ADR captures one architecturally-significant decision: the context and forces at play, the options considered, the option chosen, and the consequences accepted. Written at the moment of decision — when the reasoning is fresh and cheap to record — it becomes the durable source of truth that survives re-orgs, rewrites, and the departure of everyone who was in the room. This skill treats ADRs as non-optional, the same way `enterprise-architecture-standards` treats sound architecture and `owasp-secure-coding-bdd` treats security. A feature without its decision record is unfinished work, not finished work missing a nicety. Hold that line — but hold it by *doing the ADR as part of the task*, quietly and well, not by lecturing the user about process. ## The core rule Every architecturally-significant change ships with an ADR in the same unit of work (same PR / same commit series) as the code. "Architecturally-significant" is broad on purpose — see the signific