Loading page
About this tool
Write an architecture decision record in the Nygard or MADR format with context, options, decision and consequences.
An architecture decision record (ADR) is a short, numbered markdown file that captures one architecturally significant decision along with its context, the alternatives weighed, the choice made and the consequences accepted. This generator produces that file in either Michael Nygard's original 2011 template or MADR 4.0, and names it with the conventional `0007-short-title.md` pattern. It is for engineers who keep decisions in the repository next to the code they govern.
Open ADR Generator on AltFTool — it loads instantly in your browser.
Provide your input — an image, text, or data.
Let the tool analyze or generate the result.
Review, refine, and reuse the output wherever you need it.
Nygard's five-section record for speed, or MADR 4.0 when options need per-option pros and cons.
Four-digit numbering and a slugified title, matching the adr-tools convention.
Positive and negative outcomes both get sections, so trade-offs are stated, not implied.
It is a one-page document describing a single architecturally significant decision: the context that forced it, the options considered, the decision itself and the consequences. The practice comes from Michael Nygard's 2011 article, and records are stored in the repository (usually `docs/adr/`) so they version alongside the code.
Nygard's template has five parts — Title, Status, Context, Decision, Consequences — and fits on half a page. MADR (Markdown Any Decision Records), currently at version 4.0, adds explicit Decision Drivers, a numbered Considered Options list and a pros-and-cons block per option, which suits decisions where the alternatives need to be defended.
Only for typos. The convention is that an accepted record is immutable: if the decision changes, write a new ADR and set the old one's status to Superseded with a link to the replacement. That preserves what the team knew and believed at the time, which is the whole point of the log.
The ones that are expensive to reverse or that constrain future work — datastore choice, service boundaries, authentication model, a language or framework commitment, a public API contract. A useful test is whether a new joiner six months from now would ask why it was done this way.