在 agent 生成代码中标记重要决策并路由人工审查：用于规…

当 agent 参与规划、实现、修复代码，或需要按请求审查 diff/PR 时，用 DECISION 标记和决策日志把重要决策暴露给人类审查。

适用场景

解决思路

1. 在规划、实现、修复期间主动执行 documenting-decisions：将人类注意力路由到 agent 生成代码中真正重要的决策，并在代码注释中放置 DECISION 标记。
2. 当出现新抽象、新依赖、新数据模型、新组件边界——任何塑造长期结构的变更——时，在代码注释中放置 `ARCH` 标记。
3. 当通过选择一种解释解决了任务中的歧义时，在代码注释中放置 `SCOPE` 标记。
4. 当更改了公共 API、配置 schema、CLI flag、env var 或 wire format 时，在代码注释中放置 `IFACE` 标记。
5. 当触及 auth、crypto、权限、网络暴露或输入验证时，在代码注释中放置 `SEC` 标记。
6. 当创建了 migration、数据删除、部署触发或外部副作用时，在代码注释中放置 `IRREV` 标记。
7. 当没有现有仓库模式可遵循、你是从训练数据推断时，在代码注释中放置 `NOVEL` 标记。
8. 不要标记常规变更（跟随现有模式、样板代码、重构）。
9. 放置标记时，按本技能 `references/decision-markers.md` 定义格式；如有需要，查看 `references/marker-examples.md`。
10. 任务完成后，从变更文件中的标记生成 decision log，并添加到 PR description；使用结构：`## Decisions requiring review`，下面列 `- **TAG** `file:line` — explanation`；再写 `## Routine (skip review)`，下面写 `[One-line summary]`。
11. 如果 `ARCH` 或 `IRREV` 标记满足 `writing-adrs` 标准（难以逆转、没有上下文会令人惊讶、是真实权衡的结果），则按 `writing-adrs` 技能也写 ADR。
12. 如果工作由 ticket 驱动，在关闭 ticket 前更新它：纳入偏差、会话中途范围、上述决策（或其 ADR/glossary 引用）。
13. 遵循 `to-tickets` 可复现性不变量：重放的 issue 流应构建最终状态，而不是初稿。
14. 当用户请求审查 diff 时，进入 diff classification mode：将每个 hunk 分类为六个标签之一或 `ROUTINE`，并以 `File: path — TAG` 加行范围呈现。
15. 使用 `references/canary-signals.md` 中的 CI 脚本进行自动 checkpoint 检测（这是仓库设置，不是运行时）。
16. 使用 `references/marker-examples.md` 查看多语言示例标记。
17. 其他 `references/` 文件仅在 `AGENTS.md` 明确提及或用户请求时才使用。

适用边界 · 注意事项

• 不要用于常规变更：跟随现有模式、样板代码、重构不应加 checkpoint 标记。
• 不要在用户未请求时进入 diff classification mode 审查 diff/PR。
• 其他 `references/` 文件在 `AGENTS.md` 未明确提及且用户未请求时不要使用。