heithmurray/agent-skills

bcp-finish

真实工作的完成步骤。一个模型构建了它；另一个不同的模型攻击它；操作者做出裁决。基于构建者-挑战者协议 v1.7（https://github.com/heithmurray/builder-challenger-protocol，CC BY 4.0，Heith Murray）。

何时使用

• 使用它 在请求对任何非快速变更的工作进行完成批准之前。不要等到被问起。
• 跳过它 对于快速工作：明显、微小且易于撤销的变更。聚焦验证就足够了。
• 每次运行只针对一个主题：你即将提交的变更。

角色

• 构建者（Builder）： 你，执行实际工作的代理。你需要修复或回答每一个异议。
• 挑战者（Challenger）： 一个不同的模型，以只读模式运行。它负责发现问题；它从不编辑文件或编写交付文本。
• 操作者（Operator）： 工作的所有者，人类。只有操作者可以批准、接受风险、延长回合限制、发布真理覆盖或 REFRAME，或裁定范围。你在构建者和挑战者之间进行中继，并且可以仅针对格式违规发布标准的 RESET — [instruction]。

谁挑战谁

• 挑战者始终是与构建者不同的模型家族，以无头只读模式启动。配对和确切命令在 references/tools.md 中。
• 使用每个工具配置的默认模型；不要自行选择。
• 每次调用都是一个全新的会话，没有共享的历史记录。每次都要提供完整的回合输入（参见交接部分）。
• 每次调用最多允许 10 分钟。每个回合通常需要 1 到 5 分钟。

交接（挑战者会收到什么）

每个回合，编写一个包含以下部分的提示，按顺序：

1. references/challenger-prompt.md 的完整内容（角色、规则和格式）。
2. ROUND [n] — BUILDER OUTPUT — v1.[n-1]。
3. 主题： 一句话说明此变更必须实现的目标，如果可能，使用操作者原话，加上验收标准。
4. 查找位置： 仓库路径、基准提交和目标提交、查看差异的命令（例如 git diff <base>..<head>），以及相关的文件。
5. 构建者的证据： 你运行的验证及其结果。
6. 从第 2 回合开始：你的构建者回应（遵循构建者回应格式）以及挑战者上一次的异议清单，原文照录。

除此之外没有任何其他内容。没有评论，没有清单之外的先前回合。

挑战者可以读取文件并运行只读命令来证明其观点。证据层级很重要：运行代码或数学计算优于引用来源，而引用来源又优于观点。

循环

回合限制为 5 次，除非操作者在第 1 回合之前设置其他限制。当达到限制时仍未获得 APPROVED，则停止并向操作者询问。操作者可以延长一次，并附上理由：EXTEND — [当前回合] to [新限制]. Reason: [仍待处理的具体工作]。没有第二次延长；再次达到限制即视为死锁。

1. 第 1 回合： 发送交接内容。将挑战者的回复原文照录保存为第 1 回合。

2. 裁决为 REVISE 或 FAIL： 按照构建者回应格式进行回应：

   • 对裁决的回应。
   • 已接受的异议（按 ID）：你更改了什么。对于每一项："异议 [ID] 是第 [X] 层级。我的修订更改了 [Y]。比例适当因为 [Z]。"
   • 已拒绝的异议（按 ID）：理由，并提供同等或更高层级的证据。
   • 薄弱异议挑战。
   • 假设回应。
   • 已做出的修订。
   • 剩余的未决问题。

   进行修订并将其提交到分支。然后发送下一回合的交接内容。

3. 会改变范围、行为或设计的异议 不是你可以默默修复的。停止并作为决策事项将其与挑战者的原文一起提交给操作者。

   • 你自己编写的规范或计划不能决定范围。不要通过指向它来拒绝异议。只有操作者的话或操作者批准的规范才算数。如果范围是拒绝的唯一理由，则报告为“需要操作者范围裁定”。

4. 裁决为 PASS 仅在完成的签署检查清单中未解决项为零且最终裁决为 APPROVED 时才算数。否则将其视为 REVISE。

5. 达到回合限制而未获得 APPROVED： 停止并将未决清单提交给操作者。如果操作者延长（仅一次），则继续。否则，或在达到延长限制时，即视为死锁：要求挑战者提供一段话的最终立场声明，编写你自己的声明，并将两者都提交给操作者。

6. SELF-FAIL： 如果方法本身有问题，请说明，并包含三个必需部分：(a) 哪里有问题，(b) 为什么需要挑战才能暴露它，(c) 什么能使不同的方法有效。将其提交给操作者。

切勿编辑、删减或软化挑战者的回复。切勿声称异议已解决；只有挑战者的清单可以将其标记为已解决。

记录保存位置

• 如果工作有变更文件夹或任务记录，则将各回合保存为 BCP-LEDGER.md：按顺序包含每个挑战者的回复和每个构建者的回应。
• 否则将它们保存在仓库外部的临时文件夹中，并在你的报告中包含最终清单。
• 不要为此创建新的顶层文件夹。

向操作者报告（完成批准）

• 构建者和挑战者使用的模型，以及回合数。
• 最终版本和挑战者的最终裁决。
• 最终异议清单，原文照录。
• 挑战者的让步及其未提及风险的自查结果，原文照录。
• 你的验证证据。
• 你对请求中任何模糊之处所做的所有解释（例如“第 6–29 天不收费”），以便操作者可以确认或纠正。
• 任何需要操作者决策的事项：死锁、SELF-FAIL、范围裁定、改变范围的异议、需接受的风险。
• 然后询问批准或拒绝。推送、合并和发布等待操作者的批准。

如果挑战者无法运行

1. 重试一次。如果模型错误提到不支持的模型，报告它；不要偷偷切换模型。
2. 如果其他工具仍然不可用，则使用你自己的工具的无头只读命令作为挑战者运行相同的循环（参见 references/tools.md）。这是一个全新的会话，没有共享上下文。
3. 在报告中将整个结果标记为 SELF-CHALLENGE，并说明为什么第二个模型不可用。自挑战会共享构建者的盲点，因此操作者应给予其较低权重。
4. 切勿悄悄跳过此步骤。