adr-management-patternslisted
Install: claude install-skill findscripter/everything-skills
## 何时使用
适用于「重大且不易回退」的架构决策需要留痕、可追溯时，例如：
- 新框架/语言/运行时的采纳
- 数据库、缓存、消息中间件等基础设施选型
- API 设计模式、集成模式、安全架构的确立
- 记录设计权衡，或为新成员/审计回溯历史决策
- 建立团队级决策流程
**不该用（负边界）**：
- 仅记录细小实现细节、命名、配置项调整
- 小版本升级、Bug 修复、例行维护
- 根本不存在需要拍板的架构决策
- 不要把 ADR 当作环境特定验证、测试或专家评审的替代品；缺少必要输入、权限或成功标准时先停下来确认
判断口诀（写 vs 跳过）：
| 写 ADR | 跳过 ADR |
|--------|----------|
| 采纳新框架 | 次要版本升级 |
| 数据库技术选型 | Bug 修复 |
| API 设计模式 | 实现细节 |
| 安全架构 | 例行维护 |
| 集成模式 | 配置变更 |
## 步骤
1. **捕获上下文**：写清为什么现在要做这个决策——业务约束、技术约束、决策驱动因素（Decision Drivers）。
2. **列出备选方案**：每个方案给出诚实的优点/缺点，不藏短板。
3. **记录决策与理由**：明确「选了什么、为什么、放弃了什么」，并写出正面/负面/风险三类后果及缓解措施。
4. **关联与维护状态**：链接相关 ADR，随时间更新状态（Proposed → Accepted → Deprecated → Superseded，或 Rejected），新决策取代旧决策时写新 ADR 而非改旧的。
ADR 生命周期：
```
Proposed → Accepted → Deprecated → Superseded
↓
Rejected
```
## 指令
- 一条 ADR 一个决策；编号用四位数 `NNNN`，文件名 `NNNN-title-with-dashes.md`。
- 控制在 1–2 页，可执行、可落地；ADR 没有后续行动等于浪费。
- 已 Accepted 的 ADR 不要原地修改，用新 ADR Supersede。
- 在 `docs/adr/` 集中存放，并维护 `README.md` 索引表与 `template.md` 模板。
推荐目录结构：
```
docs/
└── adr/
├── README.md # 索引与规范
├── template.md # 团队 ADR 模板
├── 0001-use-postgresql.md
├── 0002-caching-strategy.md
├── 0003-mongodb-user-profiles.md # [DEPRECATED]
└── 0020-deprecate-mongodb.md # 取代 0003
```
用 `adr-tools` 自动化：
```bash
# 安装
brew install adr-tools
# 初始化 ADR 目录
adr init docs/adr
# 新建 ADR
adr new "Use PostgreSQL as Primary Database"
# 以取代关系新建（取代 ADR-0003）
adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQ