Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

Documentation and ADRs Overview Document decisions, not just code. The most valuable documentation captures the why — the context, constraints, and trade offs that led to a decision. Code shows what was built; documentation explains why it was built this way and what alternatives were considered . This context is essential for future humans and agents working in the codebase. When to Use Making a significant architectural decision Choosing between competing approaches Adding or changing a public API Shipping a feature that changes user facing behavior Onboarding new team members (or agents) to the project When you find yourself explaining the same thing repeatedly When NOT to use: Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes. Architecture Decision Records (ADRs) ADRs capture the reasoning behind significant technical decisions. They're the highest value documentation you can write. When to Write an ADR Choosing a framework, library, or major dependency Designing a data model or database schema Selecting an authentication strategy Deciding on an API architecture (REST vs. GraphQL vs. tRPC) Choosing between build tools, hosting platforms, or infrastructure Any decision that would be expensive to reverse Match the existing convention first Before creating an ADR, inspect the available repository context for an established convention — existing ADRs, project instructions, and ADR related configuration or tooling (e.g. an .adr dir file). An established convention overrides the defaults below. Match: Location and format — e.g. docs/adr/ .md , Documentation/Decisions/ .rst , a MADR layout, or an adr tools setup. Match the existing directory, file extension, and markup (Markdown vs reStructuredText). Numbering and naming — continue the existing sequence and filename pattern ( ADR 004 Title.rst , 0004 title.md , …); don't restart at 001 or introduce a second scheme. Section headings — reuse the project's heading set rather than imposing this template's. If the available evidence conflicts, surface the conflict rather than silently introducing another scheme. Only when no convention can be established do you apply the default below. ADR Template Store ADRs in docs/decisions/ with sequential numbering (unless the project already uses another location — see above): ADR Lifecycle Don't delete old ADRs. They capture historical context. When a decision changes, write a new ADR that references and supersedes the old one. Inline Documentation When to Comment Comment the why , not the what : When NOT to Comment Document Known Gotchas API Documentation For public APIs (REST, GraphQL, library interfaces): Inline with Types (Preferred for TypeScript) OpenAPI / Swagger for REST APIs README Structure Every project should have a README that covers: Changelog Maintenance For shipped features: Documentation for Agents Special consideration for AI agent context: CLAUDE.md / rules files — Document project conventions so agents follow them Spec files — Keep specs updated so agents build the right thing ADRs — Help agents understand why past decisions were made (prevents re deciding) Inline gotchas — Prevent agents from falling into known traps Common Rationalizations Rationalization Reality "The code is self documenting" Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. "We'll write docs when the API stabilizes" APIs stabilize faster when you document them. The doc is the first test of the design. "Nobody reads docs" Agents do. Future engineers do. Your 3 months later self does. "ADRs are overhead" A 10 minute ADR prevents a 2 hour debate about the same decision six months later. "Comments get outdated" Comments on why are stable. Comments on what get outdated — that's why you only write the former. Red Flags Architectural decisions with no written rationale Public APIs with no documentation or types README that doesn't explain how to run the project Commented out code instead of deletion TODO comments that have been there for weeks No ADRs in a project with significant architectural choices Documentation that restates the code instead of explaining intent Verification After documenting: [ ] ADRs exist for all significant architectural decisions [ ] README covers quick start, commands, and architecture overview [ ] API functions have parameter and return type documentation [ ] Known gotchas are documented inline where they matter [ ] No commented out code remains [ ] Rules files (CLAUDE.md etc.) are current and accurate

documentation-and-adrs