Sync third-party and MCP marketplace plugins

Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources.
Confidence: high
Scope-risk: narrow
Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history.
Tested: Marketplace validation passed.

plugins/codex/plugins/superpowers-zh/skills/subagent-driven-development/SKILL.md

@@ -14,7 +14,11 @@ description: 在当前会话中执行包含独立任务的实现计划时使用
 **叙述：** 在工具调用之间，最多叙述一行简短内容——
 记录由台账和工具结果承载。
 
-**持续执行：** 不要在任务之间暂停下来向你的人类伙伴确认。不中断地执行计划中的所有任务。仅可因以下情况停止：出现你无法解决的 BLOCKED 状态、存在确实阻碍进展的歧义，或所有任务均已完成。询问“我应该继续吗？”以及提供进度摘要会浪费他们的时间——他们要求你执行计划，所以就执行它。
+**持续执行：** 不要在任务之间暂停下来向你的人类伙伴确认。不中断地执行计划中的所有任务。仅可因下面列出的四类情况停止，或所有任务均已完成。询问“我应该继续吗？”以及提供进度摘要会浪费他们的时间——他们要求你执行计划，所以就执行它。
+
+**裁决，而不是停滞。** 正在执行的计划不应等待人类。冲突、歧义、计划缺陷以及你原本想请求提高上限的情况，都由你作出决定。规格说明是约束性权威，计划是其论证，你的判断解决两者都没有回答的问题。把每项决定记录到账本中，格式为 `Ruling: <你的决定> — <原因> — <判断错误的代价>`，然后继续。错误裁决的代价是人类伙伴可以看见并撤销的返工；让会话停在问题上会耗费他们整天时间却一无所获。
+
+只有四类事情会让你停止：不可逆或破坏性操作；安全敏感操作；规范要求先询问、且影响工作树之外的副作用（合并、推送共享分支、发布）；以及计划糟糕到每条前进路径都只能猜测。遇到这些情况才停止并询问。
 
 ## 何时使用
 
@@ -57,14 +61,14 @@ digraph process {
         "生成审查包，派遣任务审查者（./task-reviewer-prompt.md）" [shape=box];
         "规格 ✅ 且质量通过？" [shape=diamond];
         "发现项与计划文本冲突？" [shape=diamond];
-        "询问人类伙伴以哪个为准" [shape=box];
+        "针对冲突作出裁决并记录到账本" [shape=box];
         "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者" [shape=box];
         "派遣作用域化复审（./re-review-prompt.md）" [shape=box];
         "所有发现项都已解决？" [shape=diamond];
         "R = 5？" [shape=diamond];
         "裁决每个未解决的发现项" [shape=box];
         "存在影响关键要求的发现项？" [shape=diamond];
-        "停止：向人类伙伴报告 BLOCKED" [shape=box];
+        "作出裁决并继续；只有所有路径都只能猜测时才停止" [shape=box];
         "将发现项及裁决暂存到账本中" [shape=box];
         "把完成记录追加到账本，标记待办已完成" [shape=box];
     }
@@ -85,8 +89,8 @@ digraph process {
     "生成审查包，派遣任务审查者（./task-reviewer-prompt.md）" -> "规格 ✅ 且质量通过？";
     "规格 ✅ 且质量通过？" -> "把完成记录追加到账本，标记待办已完成" [label="是"];
     "规格 ✅ 且质量通过？" -> "发现项与计划文本冲突？" [label="否"];
-    "发现项与计划文本冲突？" -> "询问人类伙伴以哪个为准" [label="是"];
-    "询问人类伙伴以哪个为准" -> "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者";
+    "发现项与计划文本冲突？" -> "针对冲突作出裁决并记录到账本" [label="是"];
+    "针对冲突作出裁决并记录到账本" -> "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者";
     "发现项与计划文本冲突？" -> "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者" [label="否"];
     "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者" -> "派遣作用域化复审（./re-review-prompt.md）";
     "派遣作用域化复审（./re-review-prompt.md）" -> "所有发现项都已解决？";
@@ -95,7 +99,7 @@ digraph process {
     "R = 5？" -> "第 R 轮修复（共 5 轮）：R≤3 时恢复实现者；R≥4 时派遣使用更强模型的新实现者" [label="否——进入下一轮"];
     "R = 5？" -> "裁决每个未解决的发现项" [label="是——触发熔断"];
     "裁决每个未解决的发现项" -> "存在影响关键要求的发现项？";
-    "存在影响关键要求的发现项？" -> "停止：向人类伙伴报告 BLOCKED" [label="是"];
+    "存在影响关键要求的发现项？" -> "作出裁决并继续；只有所有路径都只能猜测时才停止" [label="是"];
     "存在影响关键要求的发现项？" -> "将发现项及裁决暂存到账本中" [label="否"];
     "将发现项及裁决暂存到账本中" -> "把完成记录追加到账本，标记待办已完成";
     "把完成记录追加到账本，标记待办已完成" -> "还有任务？";
@@ -138,18 +142,17 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
   发生这种情况，请从 `git log` 恢复。
 
 通读计划一次，记下其上下文和全局约束，并为每项任务创建一个
-待办事项。
+待办事项。如果计划指明了 Spec，也要读取它：规格说明是计划论证所依据的权威，二者必须一起提供给执行者。找不到可读取的 Spec 时，在账本中记一条说明；没有规格说明时作出的裁决属于临时裁决。
 
-在分派任务 1 之前，通读计划一次以检查冲突：
+在分派任务 1 之前，通读计划一次以检查冲突，并在检查时写下检查内容：
 
 - 彼此矛盾或与计划的全局约束相矛盾的任务
 - 计划明确要求、但审查量规视为缺陷的任何事项（一个没有进行任何断言的
   测试、逐字重复一个逻辑块）
 
-在执行开始前，将你发现的所有内容作为一个批量问题提交给你的人类伙伴——
-将每项发现与要求该事项的计划文本并列，并询问以哪一项为准——而不是在
-计划执行途中每发现一项就中断一次。如果检查未发现问题，则不作说明，继续
-执行。对于只有在实现过程中才显现的冲突，复审循环仍是兜底机制。
+检查输出应是一张表，而不是一句结论。对每一对共享文件或接口的任务写一行：两个任务、一个任务产出的内容与另一个任务消费的内容，以及你的发现。对每个任务再写一行：任务自身是否自洽——它指定的测试是否对应指定的代码、创建的文件是否对应后续触及的文件。“检查干净”而没有这些行，不算执行过检查。
+
+把这张表写到账本中。在开始执行前对所有发现作出裁决——将每项发现与要求它的计划文本并列——并把每项裁决记录到账本。若检查干净，则无需说明，直接继续。对检查发现的每个冲突作出裁决：规格说明是约束性权威，计划是其论证；将裁决写在对应行旁边，然后分派任务 1。复审循环仍是实现过程中才出现的冲突的兜底机制。
 
 ## 模型选择
 
@@ -177,8 +180,12 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 
 ## 任务循环
 
+**批量处理同形小任务。** 如果计划列出多个小型、相互独立且属于同一种编辑的任务——相同的一行修复、常量变更，或跨文件重复添加字段——不要为每项任务分派一个子 Agent。编写一份列出所有文件及其变更的批量简报，交给一个子 Agent，并把它的 diff 作为一个整体审查。只有需要各自判断、测试或独立审查面的工作，才按每项任务一次派发。
+
 你粘贴到派遣提示中的所有内容——以及子 Agent 返回的所有输出——在会话余下的整个期间都会常驻于你的上下文中，并在之后的每一轮中被重新读取。请以文件形式交接产物。
 
+**等待已派遣的子 Agent：** 不要用短超时轮询等待接口，也不要一次沉默地进行无界等待。只要还有本地工作，就继续处理台账更新、下一份审查包或阅读报告；子 Agent 的结果会自行到达。真正空闲时，用有界时间段等待（平台允许时等待 5-10 分钟），并在每段等待之间发布一行状态、列出仍存活的子 Agent，并追查已完成却没有报告的子 Agent。有界等待保留长等待的大部分效率，同时能在数分钟内发现卡住或丢失的子 Agent。
+
 ### 1. 派遣实现者
 
 派遣前记录 BASE（`git rev-parse HEAD`）——审查包和修复轮次的 diff 都需要它。
@@ -187,6 +194,7 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
   `scripts/task-brief PLAN_FILE N`——它会将任务的完整文本提取到一个具有唯一名称的文件中，并打印该路径。组织派遣内容时，应让简报始终作为需求的唯一来源。你的派遣内容应包含：(1) 用一行说明此任务在项目中的位置；(2) 简报路径，并以“先阅读此文件——它就是你的需求，其中包含必须原样使用的精确值”引出；(3) 简报不可能知道的、来自先前任务的接口和决策；(4) 你对简报中所注意到的任何歧义的解决方案；(5) 报告文件路径和报告约定。精确值（数字、魔法字符串、签名、测试用例）只能出现在简报中。绝不要让子 Agent 阅读整个计划文件。
 - **报告文件：**以简报为实现者的报告文件命名（简报 `…/task-N-brief.md` → 报告 `…/task-N-report.md`），并将其写入派遣提示。实现者在该文件中写入完整报告，并且只返回状态、提交记录、一行测试摘要和关注事项。
 - 一条派遣提示描述的是一个任务，而不是会话的历史。不要把累积的先前任务摘要（“任务 1-3 后的状态”）粘贴到后续派遣中——某个真实会话的派遣内容达到了 42k 个字符，其中 99% 都是粘贴的历史记录。一个全新的子 Agent 需要的是它的任务、它会涉及的接口以及全局约束。除此之外什么都不需要。
+- 派遣内容携带“不派遣子 Agent”的契约（该契约位于实现者模板中）：实现者绝不派遣子 Agent——既不派助手，也绝不派审查者。审查会在它报告后由你负责派遣。真实会话中，实现者自行派出的每个审查者都重复了控制器已经派出的任务审查，等于每项任务多花一张完整审查席位。
 - 如果先前的任务在本任务涉及的区域中暂存了一项发现，请在派遣内容中附上指向该账本条目的指针。
 - 从派遣结果中记录实现者的 Agent 身份——修复循环第 1-3 轮会恢复此 Agent。
 - 绝不要并行派遣多个实现子 Agent（会产生冲突）。
@@ -207,7 +215,7 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 1. 如果是上下文问题，请提供更多上下文，并使用同一模型重新派遣
 2. 如果任务需要更多推理，请使用能力更强的模型重新派遣
 3. 如果任务过大，请将其拆分成更小的部分
-4. 如果计划本身有误，请上报给人类
+4. 如果计划本身有误，请裁决修正、记录到账本，并携带该裁决重新派遣
 
 **绝不**忽略上报，也绝不强迫同一模型在没有任何改变的情况下重试。如果实现者表示它卡住了，就必须做出改变。
 
@@ -265,7 +273,7 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 
 - 在推进过程中，将次要发现项记录到进度账本中
   （`Task <N>: minor (deferred): <one-liner>`），并让最终的全分支审查查看该列表，以便它判定其中哪些必须在合并前修复。无人阅读的汇总就是悄无声息的丢弃。次要发现项永不进入该循环。
-- 标记为计划强制要求的发现项——或任何与计划文本要求冲突的发现项——都应像任何计划矛盾一样，由人类决定：展示该发现项和计划文本，并询问以哪一个为准。不要因为计划强制要求它就驳回该发现项，也不要在未询问的情况下派发与计划相冲突的修复。
+- 标记为计划强制要求的发现项——或任何与计划文本要求冲突的发现项——由你裁决：将发现项与计划文本权衡，以规格说明为约束性权威作出决定，并在行动前记录到账本。不要因为计划强制要求它就驳回该发现项，也不要在没有记录裁决的情况下派发与计划相冲突的修复。
 其余一切都进入该循环。一轮修复包括一次修复派发，加上一次限定范围的复审。每个任务最多五轮：
 
 **第 1-3 轮——恢复原实现者。** 将未解决的发现项逐字发送给它。它的上下文完好无损：它了解任务、代码以及它自己的选择。如果你的运行框架无法向仍在运行的子 Agent 再发送一条消息，则派发一个新的实现者，并向其提供简报路径、报告文件路径和这些发现项——无论哪种方式，报告文件都是持久记忆。
@@ -284,10 +292,9 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 **熔断器。** 如果第 5 轮复审后仍有未解决的发现项，就停止派遣。由你亲自裁决每个未解决的发现项——你掌握审查者所缺少的计划和跨任务上下文：
 
 - **审查者判断错误，或该问题存在争议：** 暂存它——
-  `Task <N>: parked — <finding> — ruling: <why the code stands>`。最终审查会看到双方理由。
+  `Task <N>: parked — <finding> — Ruling: <why the code stands>`。最终审查会看到双方理由。
 - **问题真实存在，但下游没有任何内容依赖它：** 以同样方式暂存，并在裁决中说明它确实存在但已延期。
-- **问题真实存在且影响关键要求**——后续任务会依赖它，或它揭示了计划缺陷：停止。追加
-  `Task <N>: BLOCKED — <reason>`，并向你的人类伙伴报告该发现项、与之冲突的计划文本以及修复历史。暂存结构性失败会让所有依赖任务继续在它之上构建，也会把一个最终审查同样无法修复的问题留到最后。
+- **问题真实存在且影响关键要求**——后续任务会依赖它，或它揭示了计划缺陷：裁决能解除依赖工作的最小变更，以 `Task <N>: Ruling: <finding> — <what you decided and why>` 记入账本，并把它带入下一项任务的派遣。静默暂存结构性失败会让所有依赖任务继续在它之上构建。只有缺陷让所有前进路径都只能猜测时才停止。
 
 只在达到轮次上限时进行裁决。提前裁决来结束循环，不过是换了名称的预判。每次裁决都必须写入账本——严禁无声丢弃。
 
@@ -304,10 +311,12 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 
 最终的整分支审查也要有一个审查包：运行 `scripts/review-package PLAN_FILE MERGE_BASE HEAD`（MERGE_BASE = 该分支起始于的提交，例如 `git merge-base main HEAD`），并在派发最终审查时包含输出的路径，这样最终审查者只需读取一个文件，而不必使用 git 命令重新推导分支差异。使用最强的可用模型进行派发（参见模型选择），并使用 superpowers:requesting-code-review 的 [code-reviewer.md](../requesting-code-review/code-reviewer.md)。让它查看账本中的 deferred-minor 行和 parked 行，以便对哪些项目必须在合并前修复进行分诊。
 
-如果最终的整分支审查返回发现项，请派发一个且仅一个修复子 Agent，并向其提供完整的发现项列表——不要为每个发现项分别派一个修复者。按发现项分别安排的修复者都要重建上下文并重新运行套件；在一次真实会话中，最终审查的修复波次成本超过了其所有任务的总和。然后，对该修复波次恰好进行一次限定范围的复审（针对修复范围运行 `scripts/review-package PLAN_FILE FIX_BASE HEAD`，[re-review-prompt.md](re-review-prompt.md)）。按照任务循环中的熔断器方式裁决任何残留发现项：附裁定搁置，或在遇到承重性发现项时停止。不存在第二个修复波次——当 finishing-a-development-branch 呈现选项时，残留的承重性发现项会提交给你的人类伙伴。
+如果最终的整分支审查返回发现项，请派发一个且仅一个修复子 Agent，并向其提供完整的发现项列表——不要为每个发现项分别派一个修复者。按发现项分别安排的修复者都要重建上下文并重新运行套件；在一次真实会话中，最终审查的修复波次成本超过了其所有任务的总和。然后，对该修复波次恰好进行一次限定范围的复审（针对修复范围运行 `scripts/review-package PLAN_FILE FIX_BASE HEAD`，[re-review-prompt.md](re-review-prompt.md)）。按照任务循环中的熔断器方式裁决任何残留发现项：附裁定搁置，或裁决承重性发现项并记录你的决定。这里只能因上述四类情况停止。不存在第二个修复波次——当 finishing-a-development-branch 呈现选项时，残留的承重性发现项会提交给你的人类伙伴。
 
 ## 收尾
 
+在删除任何内容之前，收集账本中包含 `Ruling:` 的每一行——起飞前裁决、搁置发现项、熔断器裁决，全部包括——按作出顺序放进最终消息的“我作出的裁决”部分，每条都写明判断错误的代价。清单必须完整：账本有裁决，清单就必须有裁决。这是你替人类伙伴作出的决定传达给他们的唯一位置；他们会阅读并返工你判断错误的部分。随工作区一起消失的裁决，就是秘密作出的决定。
+
 当最终的整分支审查无问题且其修复已合并后，删除此计划的工作区（`rm -rf <workspace>`）——现在 git 历史就是记录。同级目录属于其他计划；不要动它们。
 
 使用 superpowers:finishing-a-development-branch。
@@ -324,6 +333,7 @@ superpowers:using-git-worktrees 创建一个工作区，或验证现有工作区
 | "修复很小，跳过复审吧" | 未经审查的修复正是回归问题混入的方式。每一轮都以限定范围的复审结束。 |
 | "审查会拖慢循环" | 没有审查的循环只不过是未经验证的反复折腾。审查是循环的刹车和方向盘。 |
 | "账本记账是额外开销" | 账本是在压缩后仍能保留下来的东西。没有账本的控制器曾重新派发整个已完成的任务序列。 |
+| "实现者自己派了审查者——免费获得额外保证" | 这是审查同一 diff 的重复席位；任务审查本身就是关卡。实现者派出的审查者是需要指出的缺陷，不是严谨性。 |
 
 ## 示例工作流