SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场develop-change

develop-change

编程与开发

查看项目

更新于 10-17 16:22

技能介绍

用途

develop-change 是 guardrails 项目中的实现编排技能（implementation orchestrator）。它负责把一份已经制定好的计划（plan）中的每个任务分派给子代理执行，合并各任务分支，然后运行一致性审查。它本身不写代码、不审查代码，而是充当调度者：子代理加载 develop-tdd 执行任务，审查者加载 review-conformance，修复者加载 develop-tdd 或 develop-refactor，这些角色都不会加载 develop-change 本身。

主要能力

  • 分派计划中的每个任务，包括只有一个任务的计划；分派是正常路径，不需要向用户请求许可。
  • 并发控制：最多同时五个任务，且仅限 Files touched 集合互不相交的任务；其余串行执行。
  • 任务提示保持精简，只指向计划任务，不重述任务内容。
  • 由调度者自己合并每个任务分支，使用 sh .guardrails/scripts/task-worktree.sh merge <tag>，合并后删除任务 worktree 和任务分支，基础分支始终不被触碰。
  • 收集子代理返回的分派报告，把 red -> green: 行和继承行写入计划并标记任务完成。
  • 在最后一个任务分支合并后，按 TEST、CODE、ARCHITECTURE 三类指南文件分派 review-conformance 审查，再分派修复，循环直到某一轮没有高于 low 的发现。

使用方式

开始时应声明：“Using the develop-change skill to dispatch the plan.”

前置条件：处于 worktree 中（worktree-discipline）；对于非平凡变更，计划已存在（plan-change）。

分派任务时，提示词指向计划任务，并说明用 sh .guardrails/scripts/task-worktree.sh start t3 从当前变更 worktree 创建任务 worktree，路径为 .worktrees/<change-branch>-t3，分支为 <change-branch>-t3，基于 <change-branch>；在该分支提交并保留，不要合并。任务 worktree 存在后，不得在 <change-branch> 上提交，也不得继续在变更 worktree 中工作。对任务的每个路径，遵循 guidelines-file.sh TEST 打印的指南文件。

合并时，当子代理报告为绿色，在变更 worktree 中运行 sh .guardrails/scripts/task-worktree.sh merge <tag>。

审查阶段，用以下命令为变更 diff 选择指南文件：

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 或缺失，停止并重新安装 guardrails 脚本与模板。对任一命令打印的每个文件，分派一个 review-conformance 子代理，全部同时进行；每个审查者只读一个文件、不做任何修改。审查提示需说明审查 main...<change-branch>、指定文件与路径，读取变更 worktree 的路径，不创建任务 worktree、不编辑、不提交。

所有审查报告后，对每个有发现的审查分派修复：在嵌套任务 worktree 中，CODE 或 ARCHITECTURE 文件的发现用 develop-refactor，TEST 文件的发现用 develop-tdd，并用 task-worktree.sh merge 合并。修复发现的代理永远不审查该发现。随后再次运行审查，第一轮没有高于 low 的发现即为最后一轮。

适用场景

适用于 guardrails 项目中已有计划、需要把计划任务分派给子代理并合并、随后进行一致性审查的实现流程。它要求处于 worktree 中，并依赖 plan-change、develop-tdd、review-conformance、develop-refactor、worktree-discipline、verify-before-merge、merge-change、check-traceability 等技能与脚本。

限制与停止条件

  • 调度者不亲自执行任务；即使只有一个任务、没有并发，也应分派。
  • 子代理不能合并自己的分支；由调度者运行 task-worktree.sh merge。
  • 只有 red -> green: 行能证明每个测试在实现前曾失败；每个新测试需要一行。
  • 分派报告中 worktree 行指向提示所述之外的路径，说明任务未正确执行，不应合并，应退回重做或 discard 后重新分派。
  • 仅在答案属于用户时停止：同一任务两次未通过 red -> green 循环、同一任务两次收到审查发现、或某发现修复合并后一致性审查再次报告同一发现（同一指南条款、同一位置）。低于该阈值时继续循环并重新分派，但新提示必须改变方法。
  • 另外三种停止由用户决定：worktree-discipline 第 4 步（红色基线）、verify-before-merge 第 5 项检查（接受有记录的覆盖缺口）、develop-refactor 返回需要设计变更的架构发现（交由 design-architecture）。
  • 仅在决策需要时阅读代码：分派报告出现意外、两个任务看似分歧、或需要裁定某个发现。
  • 完成条件：每个计划任务完成且其 red -> green: 行已写入计划；TEST、CODE、ARCHITECTURE 每类一致性审查的最后一轮没有高于 low 的发现，且每个发现已修复或已处置；随后执行 check-traceability，再执行 merge-change，其第 6a 步门禁为 verify-before-merge，在该门禁通过前不得声称变更完成。

暂未提供

该技能的收费、价格、平台支持范围、具体安装命令（除上述脚本调用外）等事实，资料中暂未提供。