adrlisted

# Architecture Decision Records This skill governs the execution layer for ADRs: deciding whether an ADR is needed, reading the existing decision history, creating or superseding ADR files, and keeping decision prose out of tests and implementation. Use this together with `tsdd` when the work involves both executable behavior and architectural rationale. `tsdd` owns the methodology; this skill owns the mechanics of recording the decision. ## Core Rule When a change introduces or reverses a broad project decision, create or update an ADR under `docs/adr/` as part of the same task. Do not leave ADR creation as an optional follow-up. If the rationale matters for future maintainers or future agents, record it before finishing the work. ## When To Load Load this skill before making or reviewing changes involving: - Architecture Decision Records, decision records, ADRs, or `docs/adr/`. - Library, framework, database, protocol, hosting, or tooling selection where real alternatives exist. - Architectural patterns such as server-rendered vs SPA, sessions vs tokens, monolith vs services, sync vs async, polling vs events, or generated vs handwritten artifacts. - Durable constraints that are not obvious from code, such as "no runtime dependencies", "Nix owns this configuration", or "tests are the only requirements source". - Reversing, superseding, deprecating, or intentionally rejecting a previous decision. Do not load it for a local implementation detail that can be understood