架构决策记录¶

在编码会话期间，将架构决策记录为结构化文档。决策不再只存在于 Slack 线程、PR 评论或某人的记忆中，本技能会生成与代码并行存在的结构化 ADR 文档。

触发时机¶

• 用户明确说“记录这个决定”或“创建这个 ADR”
• 在重要备选方案之间做出选择（框架、库、模式、数据库、API 设计）
• 用户说“我们选择了……”或“我们之所以用 X 而不是 Y，是因为……”
• 用户问“为什么选择 X”（阅读现有的 ADR）
• 在规划阶段讨论架构权衡时

ADR 格式¶

使用 Michael Nygard 提出的 ADR 格式，并针对 AI 辅助开发进行了调整：

# ADR-NNNN: [決定タイトル]

**Date**: YYYY-MM-DD
**Status**: proposed | accepted | deprecated | superseded by ADR-NNNN
**Deciders**: [関係者]

## Context

この決定または変更を促すどのような問題や状況が見られるのか？

[2～5文で状況、制約条件、作用する力について説明]

## Decision

提案または実施する変更は何か？

[決定を明確に述べる1～3文]

## Alternatives Considered（検討された代替案）

### Alternative 1: [名前]
- **Pros**: [利点]
- **Cons**: [欠点]
- **Why not**: [この選択肢が拒否された特定の理由]

### Alternative 2: [名前]
- **Pros**: [利点]
- **Cons**: [欠点]
- **Why not**: [この選択肢が拒否された特定の理由]

## Consequences（結果）

この変更により、何がより簡単になり、何がより難しくなるか？

### Positive
- [利点1]
- [利点2]

### Negative
- [トレードオフ1]
- [トレードオフ2]

### Risks
- [リスクと軽減策]

工作流程¶

捕获新的 ADR¶

当检测到决策时刻时：

1. 初始化（仅首次） — 如果 docs/adr/ 不存在，在获得用户确认后，创建该目录、以索引表头填充的 README.md（参见下面的 ADR 索引格式），以及供手动使用的空白 template.md。未经明确同意，不得创建文件。
2. 识别决策 — 提取正在做出的核心架构选择
3. 收集上下文 — 导致此问题的背景是什么？存在哪些约束条件？
4. 记录备选方案 — 考虑过哪些其他选项？为什么被否决？
5. 说明结果 — 有什么权衡？什么变得更容易/更困难？
6. 分配编号 — 扫描 docs/adr/ 中现有的 ADR 并递增编号
7. 确认并写入 — 向用户展示 ADR 草稿以供审阅。仅在明确批准后写入 docs/adr/NNNN-decision-title.md。如果用户拒绝，则丢弃草稿，不写入任何文件。
8. 更新索引 — 在 docs/adr/README.md 中追加条目

阅读现有的 ADR¶

当用户问“为什么选择 X”时：

1. 检查 docs/adr/ 是否存在 — 如果不存在，则回复“在此项目中未找到 ADR。您想开始记录架构决策吗？”
2. 如果存在，扫描 docs/adr/README.md 索引中的相关条目
3. 读取匹配的 ADR 文件，显示 Context 和 Decision 部分
4. 如果未找到匹配项，则回复“未找到关于该决策的 ADR。现在要记录它吗？”

ADR 目录结构¶

docs/
└── adr/
    ├── README.md              ← すべてのADRのインデックス
    ├── 0001-use-nextjs.md
    ├── 0002-postgres-over-mongo.md
    ├── 0003-rest-over-graphql.md
    └── template.md            ← 手動使用用の空白テンプレート

ADR 索引格式¶

# Architecture Decision Records

| ADR | Title | Status | Date |
|-----|-------|--------|------|
| 0001 | Use Next.js as frontend framework | accepted | 2026-01-15 |
| 0002 | PostgreSQL over MongoDB for primary datastore | accepted | 2026-01-20 |
| 0003 | REST API over GraphQL | accepted | 2026-02-01 |

决策检测信号¶

注意对话中这些表明架构决策的模式：

显式信号 - “我们采用 X 吧” - “应该用 X 而不是 Y” - “这个权衡是值得的，因为……” - “把这个记录为 ADR”

隐式信号（建议记录 ADR — 未经用户确认不要自动创建） - 比较两个框架或库并得出结论 - 做出有明确依据的数据库模式设计选择 - 在架构模式之间进行选择（单体 vs 微服务、REST vs GraphQL） - 决定认证/授权策略 - 在评估备选方案后选择部署基础设施

好的 ADR 是什么样的¶

应该做的事¶

• 具体明确 — 使用“Prisma ORM”，而不是“使用 ORM”
• 记录理由 — 理由比什么都重要
• 包含被否决的备选方案 — 未来的开发者需要知道考虑过哪些选项
• 如实说明结果 — 每个决定都有权衡
• 保持简短 — ADR 应在 2 分钟内读完
• 使用现在时 — 使用“我们使用 X”，而不是“将使用 X”

不应该做的事¶

• 记录琐碎的决定 — 变量名或格式选择不需要 ADR
• 写成散文 — Context 部分超过 10 行就太长了
• 省略备选方案 — “只是选了它”不是有效的理由
• 不加标记地补记 — 如果记录过去的决定，请注明原始日期
• 让 ADR 过时 — 被取代的决定必须引用取代它的 ADR

ADR 生命周期¶

proposed → accepted → [deprecated | superseded by ADR-NNNN]

• proposed：决定正在考虑中，尚未最终确定
• accepted：决定有效，并且正在遵循
• deprecated：决定已不再相关（例如：功能已被移除）
• superseded：新的 ADR 取代了它（始终链接到取代它的 ADR）

值得记录的决策类别¶

与其他技能的集成¶

• Planner 智能体：当 Planner 提出架构更改时，建议创建 ADR
• Code reviewer 智能体：对引入架构更改但没有对应 ADR 的 PR 标记提示