Agent Skills: ADR Writing

ADR Writing

Architecture Decision Records document significant architectural choices.

Core principle: Explain why you decided, not how you'll implement.

Write the prose with Skill(technical-writing), and load it before you start rather than after. An ADR is usually read once, by someone deciding whether the decision concerns them — so it stands or falls on its opening, which is exactly what that skill's TL;DR-first rule is for. The Y-statement below is already a TL;DR by construction; it only pays off if the words filling its six slots are concrete. Rewriting a finished ADR into that shape afterwards is more work than writing it that way. The skill covers German and English: match the language the surrounding documentation is in rather than switching.

When to Create ADRs

Required for significant decisions (expensive or painful to reverse):

• Technology, framework, or language choices
• Data persistence strategies
• Communication patterns (sync/async, protocols)
• Authentication or authorization approaches
• Deployment strategies
• Cross-cutting concerns
• Decisions affecting system as a whole or multiple components

Not required for:

• Implementation details within a component
• Routine feature additions following established patterns
• Tactical coding decisions

Required Sections

Context

Document status quo and circumstances leading to decision:

• What exists today?
• What problem are we solving?
• What requirements (functional or non-functional) drive this?
• What constraints exist (team, budget, timeline, existing systems)?

Without status quo documentation, future readers cannot understand why change was needed.

Decision

Capture the decision as a Y-statement — a single sentence with six parts:

In the context of {functional requirement or architectural component}, facing {non-functional requirement or quality concern},

we decided for {decision outcome} and against {rejected alternatives},

to achieve {benefits, requirements satisfied}, accepting that {drawbacks, costs, consequences}.

Each part appears on its own line for readability. Keep each part concrete and specific. An extra clause starting with "because" may supply additional justification. If a single Y-statement grows too long, split into multiple statements for separate concerns.

Example:

In the context of the Web shop service, facing the need to keep user session data consistent and current across shop instances,

we decided for the Database Session State pattern and against Client Session State or Server Session State,

to achieve data consistency and cloud elasticity, accepting that a session database needs to be designed and implemented.

Options Considered

The Y-statement's "and against" clause names rejected alternatives. This section expands on them when further detail is needed (2-3 main options):

• What alternatives were evaluated?
• What are specific trade-offs of each?
• For rejected options, provide concrete reasons

Concrete reasons for rejection:

• "Requires team retraining in technology X"
• "Adds monitoring complexity without benefits at our scale"
• "Incompatible with existing auth system"
• "Performance testing showed 3x latency increase"

Avoid vague reasons:

• "Has trade-offs" (everything has trade-offs)
• "Not ideal" (why not?)
• "Complexity" (what specific complexity?)

Scope and Detail Level

ADRs document decisions, not implementations.

Include:

• High-level approach and rationale
• Key constraints and requirements satisfied
• Technology choices and why
• Component boundaries and responsibilities
• Error handling strategy at system level

Exclude:

• API schemas (unless decision is about API design pattern)
• Detailed configuration
• Step-by-step implementation
• Code examples (unless illustrating approach)

File Naming

Name files by need, not solution.

Good:

• handling-user-sessions.md
• storing-time-series-data.md
• authenticating-api-requests.md

Bad:

• redis-implementation.md (names solution, not need)
• jwt-tokens.md (names solution, not need)

Anti-Patterns

Forbidden without justification:

• Creating ADRs for routine decisions
• Documenting implementation details
• Vague trade-off analysis ("has pros and cons")
• Missing status quo documentation
• No concrete reasons for rejected options
• Empty or vague "accepting that" consequences
• Prescribing exact implementation steps

Related skills

• technical-writing: how to write the context, decision and consequences this skill asks for. TL;DR first, German and English — see the note under "ADR Writing" above.

When Not to Use ADRs

Skip ADRs when:

• Decision follows established pattern
• Easy to reverse (low-risk change)
• Purely tactical (implementation detail)
• Team already aligned and context is obvious

Document these decisions in code comments or design docs instead.