ADR Writing
Overview
Generate Architectural Decision Records (ADRs) following the MADR template with systematic completeness checking.
Quick Reference
CODEBLOCK0
When To Use
- - Documenting architectural decisions from extracted requirements
- Converting meeting notes or discussions to formal ADRs
- Recording technical choices from PR discussions
- Creating decision records from design documents
Workflow
Step 1: Get Sequence Number
If a number was pre-assigned (e.g., when called from /beagle:write-adr with parallel writes):
- - Use the pre-assigned number directly
- Do NOT call the script - this prevents duplicate numbers in parallel execution
If no number was pre-assigned (standalone use):
CODEBLOCK1
This outputs the next available ADR number (e.g., 0003).
For parallel allocation (used by parent commands):
CODEBLOCK2
Step 2: Explore Context
Before writing, gather additional context:
- 1. Related code - Find implementations affected by this decision
- Existing ADRs - Check
docs/adrs/ for related or superseded decisions - Discussion sources - PRs, issues, or documents referenced in decision
Step 3: Load Template
Load references/madr-template.md for the official MADR structure.
Step 4: Fill Sections
Populate each section from your decision data:
| Section | Source |
|---|
| Title | Decision summary (imperative mood) |
| Status |
Always
draft initially |
| Context | Problem statement, constraints |
| Decision Drivers | Prioritized requirements |
| Considered Options | All viable alternatives |
| Decision Outcome | Chosen option with rationale |
| Consequences | Good, bad, neutral impacts |
Step 5: Apply Definition of Done
Load references/definition-of-done.md and verify E.C.A.D.R. criteria:
- - Explicit problem statement
- Comprehensive options analysis
- Actionable decision
- Documented consequences
- Reviewable by stakeholders
Step 6: Mark Gaps
For sections that cannot be filled from available data, insert investigation prompts:
CODEBLOCK3
These prompts signal incomplete sections for later follow-up.
Step 7: Write File
IMPORTANT: Every ADR MUST start with YAML frontmatter.
The frontmatter block is REQUIRED and must include at minimum:
CODEBLOCK4
Full frontmatter template:
CODEBLOCK5
Validation: Before writing the file, verify the content starts with --- followed by valid YAML frontmatter. If frontmatter is missing, add it before writing.
Save to docs/adrs/NNNN-slugified-title.md:
CODEBLOCK6
Step 8: Verify Frontmatter
After writing, confirm the file:
- 1. Starts with
--- on the first line - Contains
status: draft (or other valid status) - Contains
date: YYYY-MM-DD with actual date - Ends frontmatter with
--- before the title
File Naming Convention
Format: NNNN-slugified-title.md
| Component | Rule |
|---|
| INLINECODE13 | Zero-padded sequence number from script |
| INLINECODE14 |
Separator |
|
slugified-title | Lowercase, hyphens, no special characters |
|
.md | Markdown extension |
Reference Files
- -
references/madr-template.md - Official MADR template structure - INLINECODE18 - E.C.A.D.R. quality criteria
Output Example
CODEBLOCK7
ADR 编写
概述
按照MADR模板生成架构决策记录(ADR),并进行系统性完整性检查。
快速参考
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ 获取序号 │ ──▶ │ 探索上下文 │ ──▶ │ 填充模板 │
│ (获取下一个 │ │ (上下文, │ │ (模板 │
│ 序号) │ │ ADRs) │ │ 章节) │
└─────────────┘ └──────────────┘ └─────────────┘
│ │
│ ▼
│ ┌─────────────┐
│ │ 验证 │
│ │ (完成定义 │
└─────────────────────────────────│ 检查清单) │
└─────────────┘
使用时机
- - 从提取的需求中记录架构决策
- 将会议记录或讨论转换为正式ADR
- 记录PR讨论中的技术选择
- 从设计文档创建决策记录
工作流程
步骤1:获取序号
如果已预先分配序号(例如,从/beagle:write-adr并行调用时):
- - 直接使用预分配序号
- 不要调用脚本——防止并行执行时产生重复序号
如果未预先分配序号(独立使用):
bash
python scripts/nextadrnumber.py
输出下一个可用ADR序号(例如0003)。
用于并行分配(由父命令调用):
bash
python scripts/nextadrnumber.py --count 3
输出:0003, 0004, 0005(每行一个)
步骤2:探索上下文
编写前,收集额外上下文:
- 1. 相关代码——查找受此决策影响的实现
- 现有ADR——检查docs/adrs/中相关或被取代的决策
- 讨论来源——决策中引用的PR、问题或文档
步骤3:加载模板
加载references/madr-template.md获取官方MADR结构。
步骤4:填充章节
根据决策数据填充每个章节:
初始始终为draft |
| 上下文 | 问题陈述、约束条件 |
| 决策驱动因素 | 按优先级排序的需求 |
| 考虑方案 | 所有可行替代方案 |
| 决策结果 | 选定方案及理由 |
| 影响 | 正面、负面、中性影响 |
步骤5:应用完成定义
加载references/definition-of-done.md并验证E.C.A.D.R.标准:
- - Explicit(明确的问题陈述)
- Comprehensive(全面的方案分析)
- Actionable(可执行的决策)
- Documented(记录完整的影响)
- Reviewable(可供利益相关者审查)
步骤6:标记缺口
对于无法从现有数据填充的章节,插入调查提示:
markdown
- * [调查:查看PR #42讨论以获取更多驱动因素]
- [调查:与安全团队确认合规要求]
- [调查:对方案2与方案3进行性能基准测试]
这些提示标记不完整的章节,供后续跟进。
步骤7:写入文件
重要:每个ADR必须以YAML前置元数据开头。
前置元数据块是必需的,至少必须包含:
yaml
status: draft
date: YYYY-MM-DD
完整前置元数据模板:
yaml
status: draft
date: 2024-01-15
decision-makers: [alice, bob]
consulted: []
informed: []
验证: 写入文件前,确认内容以---开头,后跟有效的YAML前置元数据。如果缺少前置元数据,在写入前添加。
保存到docs/adrs/NNNN-短横线连接标题.md:
docs/adrs/0003-use-postgresql-for-user-data.md
docs/adrs/0004-adopt-event-sourcing-pattern.md
docs/adrs/0005-migrate-to-kubernetes.md
步骤8:验证前置元数据
写入后,确认文件:
- 1. 第一行以---开头
- 包含status: draft(或其他有效状态)
- 包含date: YYYY-MM-DD及实际日期
- 在标题前以---结束前置元数据
文件命名规范
格式:NNNN-短横线连接标题.md
分隔符 |
| 短横线连接标题 | 小写、短横线、无特殊字符 |
| .md | Markdown扩展名 |
参考文件
- - references/madr-template.md——官方MADR模板结构
- references/definition-of-done.md——E.C.A.D.R.质量标准
输出示例
markdown
status: draft
date: 2024-01-15
decision-makers: [alice, bob]
使用PostgreSQL存储用户数据
上下文与问题陈述
我们需要一个数据库来存储用户账户数据...
决策驱动因素
- * 数据完整性要求
- 查询灵活性需求
- [调查:与基础设施团队确认扩展预测]
考虑方案
- * PostgreSQL
- MongoDB
- CockroachDB
决策结果
选定方案:PostgreSQL,因为...
影响
正面
负面
中性