resolve-follow-ups

处理后续事项

将一组范围明确的已记录后续事项转化为经过独立验证的拉取请求。保留所有无法通过复现和权限门槛的事项。

此技能需要 project-knowledge。开始任何工作前，请确认已安装。如果缺少该技能，请停止并使用其安装命令报告：npx skills@latest add toy-crane/skills --skill project-knowledge；如果项目固定使用某个包管理器运行器，则使用该运行器。

选择执行模式

• 未指定具体后续事项路径的调用视为一次扫描。从仓库待办列表中选择工作者，并返回一份合并报告。
• 同时提供一个后续事项路径、基础 SHA、尝试标识、所有者令牌、分支和工作树的调用视为一个工作者。只处理该事项，并返回一个终态结果。
• 将 Schedule 或 Routine 的频率安排留在此技能之外。一次调用就是一次扫描，绝不是为每个后续事项分别安排一次定期任务。

扫描待办事项

解析此技能所在目录，然后使用该目录中的 scripts/resolve-follow-ups.sh。该脚本是确定排序、最新基础版本标识、工作树创建、尝试抑制和清理的边界。

1. 运行 list --repo <root>，获取远程默认分支，并按发现顺序获取所有有效候选项以及所有 invalid-follow-up。报告无效文件，不要补全缺失的证据。不要枚举可能已过时的协调器检出版本。
2. 对每个候选项，按顺序运行 identity --repo <root> --follow-up <path>。继续处理，直到启动三个符合条件的工作者，或有序待办列表处理完毕。 eligible 只是一个快照，不是预留。启动工作者前，平台适配器必须先赢得该尝试的原子 claim 或 prepare 结果；skipped-unchanged ... claimed <owner> [<worktree> <branch>] 表示另一次扫描已经拥有内容未变的后续事项。即使默认分支因无关改动而前进，这种有效所有权和已记录的拉取请求仍然有效；默认分支前进后，终态的非拉取请求结果可重试。
3. 对于 skipped-unchanged：
   • 如果结果带有 claimed 和所有者，不要再次派发；另一个工作者已经拥有完全相同的内容和基础版本标识。如果适配器确认该所有进程已结束且没有终态结果，则清理其报告的确切绑定工作树，然后运行 recover --repo <root> --attempt-key <key> --owner <owner>。绝不要仅仅因为认领时间较久，就恢复仍在运行或状态不确定的工作者。
   • 在后续事项内容或远程默认分支 SHA 发生变化之前，保留之前的 not-reproduced、needs-shaping 或 blocked 结果。终态标识输出会保留 owner <owner> [<worktree> <branch>]；如果工作者结束后该工作树仍然存在，请在开始基础版本变更后的重试之前，使用这些确切坐标运行 cleanup。基础版本前进不会掩盖尚未处理的终态工作树。
   • 如果结果带有 pull-request 和 URL，请检查该拉取请求。保持跳过状态，直到其关闭。未合并关闭后，针对该确切基础版本标识运行 clear，然后再重试。已合并的拉取请求应在更新后的默认分支上移除该后续事项；如果不一致，应报告不一致，而不是创建重复的拉取请求。如果路径曾被删除后又重新创建，即使 Markdown 与旧事项相同，也要将其视为一个全新的后续事项生命周期。
4. 并发运行工作者前，先确认候选项的范围是否相互独立。对范围不确定或彼此重叠的事项分别处理，同时为每个事项保留独立的工作树和拉取请求。
5. 一个工作者失败，不会取消其他相互独立的工作者。一次扫描中实际运行的工作者绝不能超过三个。

为每个条目启动一个独立 Worker

仅向每个 Worker 提供其后续跟进路径、已验证的基准 SHA、尝试标识、所有者令牌、分支、工作树，以及下方的 Worker 契约。绑定检出、记录结果和清理时都必须提供所有者令牌，以免一个 Worker 覆盖或移除另一个 Worker 的尝试。调度器还会在整个仓库范围内预留每个规范工作树路径；预留失败时，绝不能通过复用其他尝试的检出绕过限制。

Claude 常规流程

当当前安装在创建时设有 WorktreeCreate 策略或等效检查，能在获取失败时停止并确保基准 SHA 与标识一致时，使用 isolation: worktree 子 Agent。要求子 Agent 在编辑前将其 HEAD 与该 SHA 进行比较。

分发前，运行 claim --repo <root> --follow-up <path> --base-sha <sha>。仅在结果为 claimed <attempt-key> <owner> 时分发。Worker 的第一步操作必须是在原生检出中运行 bind --repo <root> --attempt-key <attempt-key> --owner <owner> --worktree <worktree> --branch <branch>。绑定失败时，Worker 必须在编辑前停止。协调器记录终止结果后，由 Claude 负责移除原生工作树。

如果原生创建无法作出上述保证，则运行 prepare 创建并验证工作树，然后从该目录启动顶层无头 Claude Worker。不要仅仅为了重复原生子 Agent 已能保证的隔离而嵌套启动 Claude CLI 进程。

Codex 计划任务

计划任务仅作为协调器；其后台工作树并不能隔离条目 Worker。对于每个符合条件的条目：

1. 选择唯一的工作树路径和分支，并在名称中加入后续跟进标记和简短的尝试标识后缀。
2. 运行 prepare --repo <root> --follow-up <path> --worktree <path> --branch <branch>。仅当结果为 prepared <worktree> <branch> <base-sha> <attempt-key> <owner> 时继续；并发扫描也可能返回 skipped-unchanged，此时不会创建检出。调度器会在创建前持久化规范工作树目标，因此中断的 prepare 会使用相同的领取所有者、工作树和计划分支进行报告，便于精确清理，而不会变成匿名检出。
3. 使用 codex exec -C <worktree> --sandbox workspace-write <prompt> 启动顶层非交互式 Codex Worker。仅配置验证、推送和创建拉取请求所需的网络与审批能力。

不要使用继承协调器工作目录的写入型子 Agent 来替代逐条隔离。

执行 Worker 契约

验证边界

• 在进行任何编辑前，确认 Worker 的 HEAD 与提供的基准 SHA 一致。
• 阅读唯一的后续跟进文件，并验证全部五个字段：症状、观察到的证据、疑似原因、已尝试的事项和建议的后续步骤。
• Worker 的差异内容仅限于所选条目。如果无法验证基准、检出、权限或环境，则以 blocked 状态停止。

通过复现门槛

• 在修改产品源代码之前，通过记录的命令、路由、测试或环境复现症状。
• 保留具体的基线证据，例如失败的断言、退出状态、可观察到的输出或运行时状态。
• 如果在限定运行时间内无法复现症状，则连同已尝试的操作和下一步所需的有效证据一起返回 not-reproduced。不要进行推测性的源代码修改或创建解决问题的拉取请求。

如果复现发现了另一个超出范围的缺陷，请保留选定项，并向协调器返回新症状、观察到的证据、疑似原因、已尝试的操作以及建议的下一步。不要将唯一记录留在一次性工作器中。协调器会通过 project-knowledge 在自己的检出目录中序列化这些记录，向其提供上述五个字段，并保留它报告的 docs/follow-ups/<symptom>.md 路径。清理工作器之前，请提交该记录并发布一个专门的、可供审核的后续记录 PR；不要将其混入选定项的解决方案 PR。协调器本地的更改或结束消息中的副本都不是持久的交接方式。

确认修复权限

• 根据当前测试、规范、决策契约、受支持的运行时行为或明确无歧义的兼容性契约，推导预期行为。
• 仅在预期结果已确定且可通过确定性方式检查时继续。
• 如果此项需要产品决策、公开契约变更或重大权衡，请不提交补丁并返回 needs-shaping。说明尚未解决的选项，以便后续的 shape-idea 会话予以确定。

基于证据修复

• 进行最小且完整的修复；如果存在稳定的公共接口，则通过该接口添加或保留回归检查。
• 每次有实质意义的候选更改后，都重新运行复现。只有新证据支持继续尝试时才继续；没有新证据却反复失败时，应以 blocked 结束。
• 运行有针对性的确定性检查，以及该仓库支持的相关运行时验证。静态检查无法解决运行时症状。
• 只有原始故障通过且相关回归检查仍然全部通过时，才将此项视为已解决。

发布结果

• 在包含已验证修复的同一系列提交中删除已解决的后续事项。Git 历史即为其存档。
• 仅推送工作器分支，并创建一个可供审核的拉取请求。请包含修复前后的复现证据、运行的检查以及仍存在的不确定性。
• 不要合并其他后续事项，也不要合并该拉取请求。
• 返回包含其 URL 的 pull-request。如果发布或验证失败，请保留后续事项并返回 blocked，而不要声称问题已解决。

工作器响应末尾必须包含一个简洁的信息块，其中包含 outcome、follow-up、base-sha、attempt-key、owner、存在时的 pull-request、决定性的复现或阻塞证据，以及为协调器新发现的任何后续记录。协调器会使用此信息块记录确切的尝试；仅有说明文字不构成最终结果。

记录并清理每项结果

Worker 返回后：

• 对于拉取请求，运行 mark --repo <root> --follow-up <path> --base-sha <sha> --owner <owner> --outcome pull-request --detail <URL>，以便后续扫描 不会重复处理。
• 对于非 PR 结果，运行相同的 mark 命令，并指定 --outcome not-reproduced、--outcome needs-shaping 或 --outcome blocked，并使用 --detail 填写简洁且有决定性的证据，或下一项有用的条件。其他 worker 不能替换第一个终态结果。记录的标识仅是可丢弃的本地自动化状态，不是受跟踪 后续事项中的状态字段。
• 对于结果干净且从未偏离其基准的非 PR worker，运行 cleanup，并使用 cleanup --repo <root> --worktree <worktree> --attempt-key <attempt-key> --owner <owner>。对于 PR worker，仅当其确切的 HEAD 已显示在远程分支上后， 才运行相同的清理命令。脚本只会移除绑定到该确切声明的工作树，并保留本地分支， 以免清理与新的检出操作发生竞态并删除其引用。移除前会重新验证整个仓库范围内的 坐标预留，通过隔离的 Git 元数据安全地反初始化干净的子模块，不更改共享仓库设置， 并保留 Git 最终拒绝删除脏工作树的机制。对于脏工作树、已更改但尚未发布的工作树、 不匹配的目标、外部目标或仓库根目录，命令都会拒绝操作。
• 如果所属进程在运行 mark 之前结束，先检查其绑定分支是否已发布，以及是否存在 拉取请求。若发现拉取请求，使用 mark 记录；若分支已发布但尚无拉取请求，则完成 发布或明确阻止该发布，而不是丢弃其标识。只有在没有发生任何发布时，才在记录的 绑定工作树或准备中的工作树仍存在的情况下先使用 cleanup，然后使用确切的 attempt key 和 owner 运行 recover。如果准备过程在保存目标后、创建其路径前停止， 则跳过清理，直接恢复缺失的目标；恢复操作会在释放所有权前移除确切的陈旧 Git 工作树注册。恢复操作会拒绝处理仍活动的工作树、已发布的分支和终态结果。只有当 准备中的目标检出状态干净且仍与基准分离，或者可以通过 head compare-and-swap 删除其确切的准备专用分支时，才会移除该目标。

使用 pull-request、not-reproduced、needs-shaping、blocked、 invalid-follow-up 和 skipped-unchanged，提交一份简洁的扫描报告。为每个拉取请求 添加链接，并说明其他每种结果的证据或下一项条件。切勿将保留的后续事项标记为已修复。