architecture-decision-record · git:20260810.2f916d1 · 2026-08-10 · sha256 eee5709cd1920347

architecture-decision-record git:20260810.2f916d1A

Immutable. This exact content never changes and is served at /api/v1/blob/eee5709cd1920347.

---
name: architecture-decision-record
description: 在已经形成具体技术决策、需要判断是否应记录 ADR,或需要创建/更新架构决策记录时使用。适用于有真实备选方案、取舍、不可逆约束或未来维护者需要理解“为什么这么选”的场景。
---

# 架构决策记录

## 目标

判断一个技术决策是否值得写成 ADR,并在需要时创建或更新 `docs/adr/NNNN-<slug>.md`。

本 skill 不替代架构探索。它只记录已经有足够上下文的决策:为什么要选、认真考虑过哪些备选、接受了什么代价、未来维护者应该知道什么。

## 何时使用

- 用户明确要求写 ADR、decision record、架构决策记录
- `brainstorming` 或 `writing-plans` 已经比较过多个方案,并确认了一个会影响未来实现的选择
- 改动引入新的数据模型、存储、队列、缓存、权限边界、外部服务、部署方式或兼容策略
- 未来读代码的人如果只看 diff,会不知道为什么没有选另一个方案

## 何时不要使用

- 只是单点 bugfix、命名调整、样式修改或机械迁移
- 没有真实备选方案,只是采用仓库既有约定
- 决策还没有成形,还需要先做探索或方案对比
- 用户只是要实现,不希望新增文档;这时只在计划或总结里标记文档债务

## ADR 值得记录的标准

满足下面任意 2 条,默认建议写 ADR:

1. 有多个认真考虑过的备选方案
2. 有非平凡取舍:接受了真实成本,而不是单纯“X 更好”
3. 不容易回滚,或会约束未来设计
4. 如果缺少“为什么”,未来维护者会困惑

只满足 1 条时,通常不写 ADR;把理由放到 PR body、设计文档或代码注释中即可。

## 工作模式

### 评估

用于判断是否应该写 ADR。

输出:

```text
结论:建议写 ADR / 不建议写 ADR
满足标准:1, 3
原因:<一句话,必须基于上面的标准>
建议标题:<如果推荐写 ADR>
```

### 创建

用于创建 ADR。

1. 收集决策上下文:
   - 决策摘要
   - 为什么需要这个决策
   - 真正考虑过的备选方案
   - 已知取舍和接受的成本
   - 最终选择
   - 可参考的 issue、PR、计划、代码或会议记录
2. 检查 `docs/adr/`:
   - 不存在则创建
   - 读取已有 ADR,确定下一个编号
   - 扫描是否可能替代旧 ADR
3. 如果存在替代候选,只作为提示,不自动修改旧 ADR。必须先让用户确认明确目标。
4. 使用下面模板创建新文件。

## 文件约定

- 目录:`docs/adr/`
- 文件名:`NNNN-<slug>.md`
- 编号:4 位数字,从现有最大编号 +1
- slug:小写、短横线、描述决策,例如 `use-postgresql`、`event-driven-notifications`

## 模板

```markdown
---
status: 已接受
date: YYYY-MM-DD
---

# <简短标题:说明做了什么决策>

## 背景与问题

说明为什么需要这个决策,以及让选择变得不简单的约束、风险或需求。

## 决策驱动因素

- <关键约束或需求>
- <另一个驱动因素,如有>

## 考虑过的方案

- <方案 A>
- <方案 B>
- <方案 C>

## 决策结果

最终选择:"<方案 X>",因为 <结合决策驱动因素给出简短理由>。

### 正面影响

- <这个选择带来的改进或能力>

### 负面影响

- <接受的成本。本节必须有内容。>

## 各方案优缺点

### <方案 A>

- 优点:<原因>
- 缺点:<原因>

### <方案 B>

- 优点:<原因>
- 缺点:<原因>
```

## 替代规则

旧 ADR 只有在新决策明确替代它时才更新为:

```yaml
status: 被 ADR-NNNN 替代
```

判断候选时看:

- 标题、slug 或治理范围高度重叠
- 新决策明确反转旧决策
- 新方案替换旧方案,而不是补充或局部扩展

模糊时输出 `被替代 ADR:无`,不要擅自更新旧文件。

## 写作规则

- 一个 ADR 只记录一个决策
- 只写真实考虑过的备选,不补虚构选项
- `负面影响` 必须有内容;没有代价的 ADR 像销售文案
- 语言保持事实性,不写宣传口吻
- 信息缺失时明确写 gap,不假装已经知道

## 输出契约

创建后输出:

```text
ADR 路径:
标题:
状态:
被替代 ADR:无 / ADR-NNNN
已知缺口:
验证:
```