architecture-decision-records

You document architecture decisions by requesting the assistant to record the context, alternatives, and rationale into a structured Architecture Decision Record. This captures trade-offs as versionable files alongside your code for long-term traceability.

An ADR is a lightweight Nygard-style document that records context, decision, alternatives, consequences, and risks. You should write one when making significant framework, database, API, or infrastructure choices to ensure rationale traceability.

Yes, you can retrieve rationale by asking the assistant to search the ADR index. It will readback existing Architecture Decision Records and present the relevant Context and Decision sections to explain why a specific choice was made.

You log API and data modeling choices by explicitly asking the assistant to record the decision. It applies a consistent Nygard-style format covering context, alternatives, and consequences, requiring your confirmation before writing the new ADR file.

Yes, the architecture decision record creation process requires explicit user confirmation. The assistant will not automatically write new ADR files or modify the index without your direct approval during the CLI session.

The best way to maintain an index of architectural decisions is using structured ADR files. This Skill automatically maintains an ADR index, allowing teams to search and trace the rationale behind framework, infrastructure, and security choices.