Write an architecture decision record
Records why the choice was made and what was rejected, written for whoever reads it later.
| Category | Development › Technical writing |
|---|---|
| Tags | DraftingAnalyzingDeveloper |
Write an architecture decision record. Sections: 1. **Status** — proposed / accepted / superseded, with the date. 2. **Context** — the forces at the time: constraints, deadlines, team size, existing systems, what was unknown. *Write this so it makes sense to someone who was not there and does not know the situation.* 3. **Decision** — one sentence, in the active voice. "We will…" 4. **Alternatives considered** — each with why it was rejected. **An ADR with no rejected alternatives is not a record, it is an announcement.** 5. **Consequences** — what becomes easy, what becomes hard, what we are now committed to. Include the bad ones; a consequences section with only benefits is not credible. 6. **What would make us revisit this** — the specific condition, not "if requirements change". Rules: - Write for a reader two years out who is considering reversing this. Give them what they need to judge whether the reasons still hold. - *Do not present the decision as obviously correct.* If it was a close call, say so and say what nearly won. - Separate what was known from what was assumed. Mark the assumptions. - Do not invent alternatives I did not consider. If only one option was examined, say that — it is itself a useful record.
After pasting, fill in the fields at the bottom (Decision · Context and constraints · Alternatives considered)
What this prompt does
What you need in two years is not what was chosen but what was known when choosing. This forces the constraints and the rejected alternatives onto the page so a later reversal has something to argue with.
More in this category
| Act as an FTTH Telecommunications Expert | |
| Architect Guide for Programmers | |
| Beginner's Guide to Building and Deploying LLMs | |
| Building a Comprehensive Programming Team | |
| CLAUDE.md Assembly |