FREE TOOL
ADR Generator
Structured ADR template. 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-07-26
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).
Tired of losing the reasoning behind your architecture? Export free above · connect a repo when you want Moxie to keep it accurate
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
For teams that document code
Tired of losing the reasoning behind your architecture?
Capture decisions in an ADR here. Connect GitHub when you want Moxie to extract conventions from real code, surface gaps, and keep architecture docs current on every merge.
Export free above · connect a repo when you want Moxie to keep it accurate