FREE TOOL
ADR Generator
Structured form. Live preview. Clean Markdown export. Shareable links.
Create Architecture Decision Records that stay with your codebase. No account. Nothing leaves your browser until you commit the file.
ADR: Record architecture decisions as ADRs in the repo
Status: Accepted Date: 2026-06-11
Context
Important technical and process decisions are discussed in PRs, Slack threads, and meetings. Over time the rationale is lost. New engineers and future maintainers have no reliable way to understand why the current state exists.
Decision
We will write short Architecture Decision Records (ADRs) as Markdown files inside the repository. Files live under docs/adr/ (or adrs/) and follow a consistent lightweight template. Each ADR captures context, the decision, and consequences.
Consequences
Decisions become part of the permanent, searchable, versioned record. Onboarding is faster. Future refactors can reference prior ADRs instead of rediscovering rationale. The cost per decision is low and the long-term value is high for any team that maintains code over time.
Alternatives considered
Keep decisions only in wiki pages or Confluence (rejected: pages go stale and live outside the code). Rely on tribal knowledge and PR comments (rejected: impossible to search or audit later). Use a dedicated heavy ADR tool (rejected: adds another system and access friction).
Fill context, decision, consequences and alternatives. The Markdown assembles automatically following a clean standard template.
See the final document rendered as you type. No separate save or export step to review.
The entire ADR lives in the URL. Send the link or bookmark it. Export clean .md ready for docs/adr/ in your repo.
Everything runs in your browser. Decisions never leave your device until you choose to commit them.
When teams write ADRs
Why this database, framework, or deployment model over the obvious alternatives.
Service boundaries, data ownership, or integration approaches that affect many teams.
PR review rules, documentation standards, or how your team handles drift and cleanups.
Explicitly noting what you gave up so future changes can re-evaluate the same constraints.
Frequently asked questions
An Architecture Decision Record is a short Markdown document that captures an important technical or process decision: the context that led to it, the decision itself, and the expected consequences. ADRs live alongside your code so the rationale doesn't disappear.
Yes. Use it as much as you want. No sign up, no limits, no watermarks. The output is plain Markdown you can commit anywhere.
A lightweight common format with Title, Status, Date, Context, Decision, Consequences, and optional Alternatives. It is compatible with most teams' existing ADR collections and renders well in GitHub and documentation sites.
Commit them in the same directory structure as your other docs. When the decision is superseded or the context changes, add a new ADR that references the old one and update the status of the previous record.
Yes. Use the Share link button. The full state (title, status, all sections) is encoded in the URL. The recipient sees exactly what you have so far.
The form keeps the structure consistent across every record your team writes. Examples and status pills reduce friction. The live preview and one-click export make it faster to produce a clean, reviewable document.
Tired of losing the reasoning behind your architecture?
Moxie Docs connects to your GitHub repositories, extracts conventions and decisions from real code and history, surfaces documentation gaps, and keeps architecture docs (including the decisions that shaped them) current on every merge. Fridays deliver a single reviewable Cleanup PR.
No credit card required to start. Cancel anytime.