develop-change

开发变更

开始时宣布：“正在使用 develop-change 技能来分派计划。”

前提条件

• 你位于一个工作树中（worktree-discipline）。
• 对于非简单变更，已有一份计划（plan-change）。
• 你负责分派。任务子 Agent 加载 develop-tdd，审查者加载 review-conformance，修复者加载 develop-tdd 或 develop-refactor，绝不能加载此技能。

步骤

分派：分派计划中的每项任务

你负责统筹整个循环：子 Agent 在 develop-tdd 下为一项计划任务执行循环，你则维护计划、记录和决策。

• 分派计划中的每项任务，即使计划只有一项任务也不例外。不要征求用户是否同意分派；这是常规流程。

• 最多同时分派五项，且只能涉及互不重叠的文件。 只有当任务的 Files touched: 集合互不相交时，才并行分派（plan-change）。其他情况一律串行执行。

• 提示词中只提供指向计划任务的路径。 使用你所用的工具支持的任何方式来分派子 Agent（Task 或 Agent 工具、/agent 命令）：

  Execute task 3 of docs/plans/2026-08-30-<topic>.md under the develop-tdd
  skill. Create your task worktree with
  `sh .guardrails/scripts/task-worktree.sh start t3` from the change worktree
  you are in; it is .worktrees/<change-branch>-t3, on branch
  <change-branch>-t3 off <change-branch>. Commit your work on that branch and
  leave it there — do not merge it. Once your task worktree exists,
  do not commit on <change-branch> and do not keep working in the change
  worktree. For each of the task's paths, follow
  the guidelines file `guidelines-file.sh TEST` printed for it:
  <file>: <paths>   (one line per file it printed)
  Return the dispatch report.
  

  在提示词中注明任务工作树路径。 子 Agent 被限制在变更工作树的子目录中，在违反限制之前无法发现该限制（worktree-discipline 步骤 1）。它会在变更工作树中启动，并在那里运行 task-worktree.sh start；任务工作树创建后，提示词中的限制开始生效：不得在变更分支上提交，也不得继续在变更工作树中工作。

  不要重述任务。计划中已经包含路径、代码和预期输出。

• 由你亲自合并每个任务分支。 子 Agent 在自己的任务分支上提交，不负责合并。其报告通过后，在变更工作树中运行：

  sh .guardrails/scripts/task-worktree.sh merge <tag>
  

  该命令会将任务分支合并到变更分支，然后删除任务工作树和任务分支。基础分支不会被修改。

分派报告

子 Agent 只返回 develop-tdd 规定的报告格式，不得包含其他内容：没有差异、日志或叙述。

• 如果 worktree: 行指定的路径与提示词中给出的路径不同，则该任务执行有误。不要合并。让子 Agent 回到指定工作树重做，或者运行 sh .guardrails/scripts/task-worktree.sh discard <tag>，然后重新分派任务。discard 只会作用于嵌套路径，并会拒绝处理在其他位置检出的任务分支。
• red -> green: 行是每项测试在实现尚不存在时失败的唯一记录。每项新测试都必须有一行。verify-before-merge 检查 4 会读取这些记录。
• 每收到一份报告，就将其中的这些行和所有 inherited: 行写入计划中对应任务旁边，并将任务标记为已完成。 merge-change 步骤 5 会将它们从计划复制到验证记录中。步骤 5 之后分派的修复（6a 或 6c 失败的修复、基线变更轮次的审查）应直接将这些行写入验证记录。

偏离轨道及其他停止情形

只有当答案属于用户时才停止。 同一处反复失败也符合条件：

• 同一任务的红 -> 绿循环失败两次；
• 同一任务两次收到审查意见；或
• 合规审查再次报告某项发现，而针对它派发的修复已合并。

合规审查轮次中出现新发现，说明循环正常工作，并非重复：只有反复出现的发现才算重复，且必须是同一位置的同一条准则条款。位置指先前发现指出的文件和行号；同一条款在另一处出现，属于新发现，而非重复。只有高于低级别的发现才计入；如果某轮没有任何高于低级别的发现，那就是最后一轮，无论其中是否有重复发现。对照计划中已记录的发现；每一轮的审查者都是新来的，不了解已有发现。

然后停止，说明卡住的事项和已尝试的做法，并让用户做出选择：提高投入级别，或以不同方式拆分任务；对于重复的合规发现，则由用户决定接受该发现，或裁定该准则条款不适用。任务难度大不是停止的理由。

未达到上述门槛时，继续循环并重新派发，但要在新提示词中改变方法。以相同方式重述相同任务后重新派发，只会产生相同的失败。

另外三种停止情形是刻意设置的，须由用户决定：

• worktree-discipline 第 4 步（基线为红）；
• verify-before-merge 检查 5（接受已记录的覆盖缺口）；以及
• develop-refactor 返回需要进行设计更改的架构发现，由 design-architecture 接手：备选方案由用户决定。

除此之外，继续循环。

只有在决策需要时才阅读代码： 派发报告提到意外情况、两个任务看起来出现分歧，或需要裁定某项发现时。

合规审查

最后一个任务分支合并后，为本次变更差异选取准则文件：

sh .guardrails/scripts/guidelines-file.sh TEST \
    $(git diff --name-only main...<change-branch>)
sh .guardrails/scripts/guidelines-file.sh CODE \
    $(git diff --name-only main...<change-branch>)
sh .guardrails/scripts/guidelines-file.sh ARCHITECTURE \
    $(git diff --name-only main...<change-branch>)

如果任何命令的退出码为 2 或缺少文件，则停止并重新安装防护脚本和模板（ratchet 的升级）。对每个命令有输出的文件，同时派发一个子 Agent，使用 review-conformance 技能：每个子 Agent 只读取一个文件，且不做任何更改，因此不会互相冲突。

Review main...<change-branch> under the review-conformance skill against
<file>, for these paths: <paths>. Read the change worktree at <path>; do not
create a task worktree, edit, or commit. Return the report review-conformance
states.

审查者不做任何更改，也不会获得任务工作树。 提示词要同时说明变更工作树路径和禁止事项；缺少这些信息时，子 Agent 会照着其他派发任务的做法创建任务工作树。

所有审查都报告后，派发修复任务：每个有发现的审查派发一个子 Agent，在嵌套任务工作树中执行，与其他任务相同；对于 CODE 或 ARCHITECTURE 文件的发现，使用 develop-refactor；对于 TEST 文件的发现，使用 develop-tdd；然后通过 task-worktree.sh merge 合并每项修复。develop-refactor 返回需要进行设计更改的架构发现时，交由 design-architecture 处理（偏离轨道）。仅在文件互不重叠时并行派发。修复某项发现的 Agent 不得审查该项发现。

Fix the findings below, from the review of main...<change-branch> against
<file>, under the develop-refactor skill (develop-tdd for a TEST file).
Create your task worktree with
`sh .guardrails/scripts/task-worktree.sh start <tag>` from the change worktree
you are in; it is .worktrees/<change-branch>-<tag>. Commit there and leave it
there — do not merge it.
<the findings, verbatim>
Return the report the skill states.

然后再次运行审查；第一轮没有任何高于低级别的发现时，该轮就是最后一轮。轮数没有上限；一旦有发现重复出现，循环就停止（偏离轨道）。每项发现出现时，都要将其及处理结果写入计划，就像 red -> green: 行那样；merge-change 第 5 步会将它们复制到记录的 ## Guideline reviews 中。这些审查在此处、merge-change 之前运行，而不是在它的第 4 步运行：只要出现任何发现，整个流程就会从第 1 步重新开始。

警示信号

想法	实际情况
“只有一个任务，也没有并发，我自己来做”	派发出去。代码和测试输出不会占用你的上下文。
“子 Agent 可以合并自己的分支”	Git 会拒绝更新已由你的工作树检出的变更分支；而在任务工作树中运行 git merge <change-branch> 会朝错误方向合并，并以 0 退出。你要运行 task-worktree.sh merge。
“结果行显示绿色，所以每项测试都曾经失败过”	只有 red -> green: 行才表示这一点。
“用相同的提示词重新派发”	先改变处理方式。
“在 merge-change 第 4 步修复名称”	这会重新运行合并流程。在此处运行一致性审查。
“审查者发现了问题，也可以顺手修复”	审查者不会做任何更改。修复需要单独派发，下一轮再审查修复结果。
“一位审查者可以检查所有文件”	每次审查一个文件。一位审查者只检查一个文件，遗漏会更少。

完成条件

• 每项计划任务都已完成，且其 red -> green: 行已写入计划。
• TEST、CODE 和 ARCHITECTURE 的每项一致性审查都已在 最新一轮中运行， 没有高于低级的问题，且每项发现的问题都已修复或处置。
• 接下来运行 check-traceability，然后运行 merge-change，其第 6a 步的门槛是 verify-before-merge。在该门槛通过之前，绝不要声称变更已完成。

参考资料

• references/rationale.md — 如果此处的规则似乎不适用于你的情况， 或在提议修改规则之前，请阅读。