使用ADR进行开发 是做什么的？
强制第一步：冲突检查
在询问领域、创建代理、调查代码或进行更改之前，请运行捆绑的只读脚本：
python3 <absolute-skill-directory>/scripts/check_conflicting_skills.py --project <repository-path>
将占位符解析为实际路径，并根据需要引用路径。使用重复的 --available-skill 参数传递会话可用技能目录中的每个名称，包括仅云端的和插件限定的名称。使用 --root 添加非标准的技能目录；显式添加相关嵌套目录符号链接的目标。该脚本会发现在没有加载其指令或更改安装的情况下本地的技能文件和目录条目。
- 将
grill-me和spec-first视为冲突技能，包括大小写、空格、下划线和连字符变体，例如Grill Me或spec_first。 - 退出码 0 表示在检查范围内未发现冲突。退出码 1 表示发现了冲突，不是脚本失败。退出码 2 表示发现不完整：报告错误和覆盖限制，尽可能解决它们，然后重新运行。当覆盖不完整时，切勿声称检查了所有技能。
- 对于任何匹配项，在此工作流程中禁用它们的使用，并在继续之前以用户的语言警告用户：命名检测到的技能，并解释它们仅在当前工作流程中被禁用。不要暗示全局卸载或帐户设置更改。这些工作流程排除不需要额外的批准。
- 不要调用被排除的技能、遵循其指令或将工作委托给它们。将排除应用于协调器、架构师和实现器；在每次代理交接时传递排除列表。使用此工作流程自身的澄清和批准步骤。
- 脚本检测冲突；协调代理强制执行排除。如果会话目录揭示了某个技能（即使其文件不可访问），也将其排除。如果脚本无法运行，报告该限制并应用已知排除，而不声称成功扫描。
- 在恢复会话或可用技能发生变化后重新运行。切勿删除、重命名或全局禁用已安装的技能作为此检查的一部分。
进入和角色
- 在开始工作流程之前，询问架构师应关注的领域。接受业务或技术领域。如果已显式提供领域，则无需再次询问。
- 为所选领域创建一个在整个会话中独立的架构师代理。提供这些规则、领域、仓库路径和已知上下文。让架构师询问用户要解决哪个问题；主代理可以传递问题和答案。如果问题已经提供，则仅询问缺失的信息。
- 让主代理协调对话、文档和上下文交接。让架构师调查、设计、维护ADR并独立验证结果。让一个独立的实现代理实现已批准的决策并准备证据。不要将架构师和实现者的角色合并。
- 使用环境原生的独立代理能力：Codex中的子代理和Claude Code中的可用代理/任务能力。不要发明API，也不要将单个代理切换角色呈现为独立验证。如果无法使用独立代理，则解释限制并让用户选择合适的环境。调查可以继续，但在此工作流程下的实现不得开始。
- 上下文丢失后，从文档和代码恢复状态。如果必须创建新的架构师，不要声称原始代理仍然存在；恢复其领域和职责。
调查与决策
- 让架构师阅读项目指令、代码、相关的ADR和证据，并澄清问题和约束。在调查代码和澄清问题之前，不要创建ADR。如果尚不存在代码，记录该事实并调查可用材料。
- 识别与当前决策的冲突。首先向用户展示冲突并请求决策；仅在得到响应后准备新的ADR。准备替换的权限不等于批准实现它。
- 在
docs/adr/中使用模板编写ADR。包括简短的问题陈述、提议的解决方案、理由和具有稳定ID的可验证验收标准。将初始状态设置为accepted-for-discussion。 - 将独立的决策分离到单独的ADR中，并显式记录依赖关系。不要引入依赖或替换循环。
- 呈现特定的ADR或一组枚举的ADR，以供用户明确批准实现。不要从沉默、构建某物的一般性请求或调查许可中推断批准。
- 记录用户的响应、日期和批准的文档版本。仅在获得明确批准后才设置
accepted-for-work。允许明确批准一组枚举的ADR。
实现
- 仅在其依赖的所有ADR完成后才开始实现一个ADR，即使整个集合已被批准。
- 向实现者提供ADR、标准、依赖关系和约束。要求在已批准决策的范围内进行实现。
- 如果实现不可能，或者决策或标准需要更改，则停止受影响的工作并将问题返回给架构师。独立的已批准工作可以继续。
- 批准后，切勿更改解决方案描述或验收标准。在新的ADR中记录更改，并获得单独的批准。
- 让实现者在
docs/evidence/中准备证据：每个标准的结果、命令和重现说明，以及已验证的提交或确切的代码版本。不要用未来的提交替换已测试的版本。对于未提交的更改，包括保存的差异以及检查过的文件的标识符或哈希值。
独立验证与完成
- 让架构师亲自运行检查，并将实际结果与每个验收标准进行比较。实现者的报告和代码检查不能替代执行。
- 将命令、环境、结果、日志链接和已验证版本保存在证据中。诚实标记未运行、被阻止或失败的检查。不要完成具有未验证或未满足标准的ADR。
- 如果实现未能通过验证但ADR仍然有效，首先向用户呈现结果和具体的更正范围并请求许可。在得到响应之前，不要委托或执行修复。获得许可后，让实现者修复问题，架构师再次验证。再次验证失败需要为下一个更正周期重新获得许可。
- 如果失败需要新的架构决策，则返回到调查和新ADR流程。
- 只允许架构师在成功独立验证每个标准后设置
completed。需要链接到证据文档。完成ADR不需要额外的用户批准。
状态与历史保存
使用恰好四个规范的 status 值。下面的俄语标签标识了它们的原始含义；保留现有的项目历史，而不是静默地重写遗留文档。
| 状态 | 原始标签 | 条件 |
|---|---|---|
accepted-for-discussion | принято к обсуждению | 已调查的提案，等待讨论或批准 |
accepted-for-work | принято к работе | 用户明确批准了特定的ADR |
completed | завершен | 架构师独立验证了所有标准；证据已链接 |
rejected | отклонено | 存在新的已批准ADR和拒绝理由/证据 |
- 切勿删除ADR或证据文档或重用其ID。在批准之前，允许在记录重大更改的同时完善草稿。
- 批准后，保持解决方案主体和标准不变。允许更新当前状态和链接，并附加历史条目。保留较早的条目、证据和验证结果。不要用通过的结果覆盖失败的检查。
- 在用户明确批准其替代品进行工作时（包括旧ADR已完成时），立即拒绝旧ADR。立即将旧ADR链接到其替代品和单独的拒绝理由文档。这证明了旧决策被拒绝的原因；并不证明新的实现有效。
- 保留先前的完成状态、日期、版本和证据。显式记录替代品可能尚未实现。拒绝文档本身不会删除工作代码。
- 没有新决策时，不要拒绝ADR。如果用户尚未选择替代品，则保留当前状态并附加讨论条目。不要仅仅为了启用状态转换而发明替代品。
- 如果依赖项被拒绝或替换，则暂停受影响的工作，并让架构师评估影响。不要静默地重新链接已批准的决策。
文档图谱
- 在创建文档之前阅读模板，并在使用新环境时阅读可移植性指南。
- 将ADR存储为
docs/adr/ADR-0001-short-slug.md，将证据存储为docs/evidence/EVID-0001-short-slug.md。选择下一个未使用的编号，同时考虑现有历史记录；不要对旧文档进行重新编号。 - 使用显式的相对Markdown链接和关系类型：
replaces/replaced_by，depends_on/required_by，extends/extended_by，以及evidence/proves。维护反向链接，并确定证据是证明了实现还是拒绝原因。 - 将ADR和证据视为图谱的文档；不需要单独的图数据库。在交接时，检查链接目标、反向链接、无依赖循环以及状态条件。
- 在每个步骤结束时，报告ADR状态、结果、文档链接，以及如果正在等待用户则报告所需的具体决策。不要将仅仅已批准或已实现但未验证的工作描述为已完成。