@wenaixi/dsh-superpower 6.3.1 → 7.0.0

package/skills/executing-plans/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: executing-plans
+description: "Superpower Skill（最高优先级）：当你在本会话中亲自作为实现者执行实施计划时使用——human partner 选择了内联执行，或环境不提供 subagent 工具。"
+---
+
+# 执行计划
+
+在本会话中由你亲手逐任务执行计划：不为每个任务配实现者 subagent，也不为每个任务配 reviewer。最后对整个分支做一次全新上下文的评审。
+
+**为什么内联：** subagent 驱动开发要为每个任务各付一份全新实现者与一份全新 reviewer，两者都要从零重读代码库。内联执行只付一份上下文（你的），外加结束时的一位 reviewer。它放弃的，是每个任务一份全新上下文、以及每个任务的第二双眼睛。本技能用别的手段保住这两样东西买来的价值：brief 就是规格，ledger 就是你的记忆，TDD 是每个任务的门禁，最终 reviewer 就是那第二双眼睛。
+
+**核心原则：** 思考已经由计划完成。严格照它执行，用你亲眼看着先失败、再通过的测试证明每一步，并留下能扛住你自己遗忘的记录。
+
+**叙述：** 工具调用之间最多说一句短话——记录由 ledger 和工具结果承载。
+
+**连续执行：** 任务之间不要停下来跟 human partner 确认。他们选择内联是为了少花钱，而不是为了在每个任务之后回答“要不要继续？”。把计划里的任务一口气全部执行完。
+
+**裁决，而非停滞。** 冲突、含糊、计划缺陷——都由你裁决。规格是有约束力的权威，计划是它给出的论证，二者都答不上的部分由你的判断了结。每条决定都记入 ledger：`Ruling: <你决定了什么> — <为什么> — <错了要付出什么代价>`，然后继续。偏离计划却没有 ledger 里的一条裁决，等于偷偷做了决定。
+
+只有四件事会让你停下，也仅此四件：不可逆或破坏性操作；安全敏感的动作；按惯例应先打招呼的 workspace 外副作用（合并、推送到共享分支、发布）；以及烂到每条前路都只能靠猜的计划。遇到这些，停下并询问。
+
+## 何时使用
+
+- 你手上有来自 writing-plans 的计划，且 human partner 在交接时选择了内联执行。
+- 你的运行环境没有 subagent 工具（见 `../using-superpowers/references/` 中的各平台参考）。绝不要捏造一次分发；就在本地跑这份计划。
+- 任务大体相互独立——与 subagent-driven-development 相同的前置条件。
+
+一份完全写明的计划，让内联执行退化为“转写加测试”：它在中档会话模型上跑得很好，而最强模型真正值回票价的地方是最终评审，本技能会单独派发那一次评审。human partner 选择内联时，请这样告诉他们。
+
+当 human partner 要求每个任务都有评审关卡，或计划长到后半段任务会在被压缩的上下文里执行时，优先用 subagent-driven-development。长计划上的内联执行依然可行——ledger 正是它可恢复的原因——但最后几个任务得到的是你最少的注意力。
+
+## 流程
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="每个任务";
+        "task-start：brief + BASE；阅读 brief" [shape=box];
+        "按顺序执行步骤：TDD，运行每一次验证，阅读每一份输出" [shape=box];
+        "步骤输出与计划的 Expected 一致？" [shape=diamond];
+        "计划错了？裁决并记 ledger。代码错了？systematic-debugging" [shape=box];
+        "按计划中的提交步骤提交" [shape=box];
+        "完成契约是否满足？" [shape=diamond];
+        "task-done：运行测试，把结果记入 ledger；把 todo 标为完成" [shape=box];
+    }
+
+    "准备：worktree、workspace + ledger、阅读计划 + 规格、预检扫描" [shape=box];
+    "还有任务吗？" [shape=diamond];
+    "最终全分支评审（有 subagent 就用全新 reviewer）" [shape=box];
+    "重新分级，然后：Critical/Important → 一次修复轮，每个修复 RED→GREEN + 全绿套件；Minor → ledger" [shape=box];
+    "最终评审干净：删除本计划的 workspace" [shape=box];
+    "使用 finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
+
+    "准备：worktree、workspace + ledger、阅读计划 + 规格、预检扫描" -> "task-start：brief + BASE；阅读 brief";
+    "task-start：brief + BASE；阅读 brief" -> "按顺序执行步骤：TDD，运行每一次验证，阅读每一份输出";
+    "按顺序执行步骤：TDD，运行每一次验证，阅读每一份输出" -> "步骤输出与计划的 Expected 一致？";
+    "步骤输出与计划的 Expected 一致？" -> "计划错了？裁决并记 ledger。代码错了？systematic-debugging" [label="否"];
+    "计划错了？裁决并记 ledger。代码错了？systematic-debugging" -> "按顺序执行步骤：TDD，运行每一次验证，阅读每一份输出";
+    "步骤输出与计划的 Expected 一致？" -> "按计划中的提交步骤提交" [label="是，最后一步"];
+    "按计划中的提交步骤提交" -> "完成契约是否满足？";
+    "完成契约是否满足？" -> "按顺序执行步骤：TDD，运行每一次验证，阅读每一份输出" [label="否——把这个任务做完"];
+    "完成契约是否满足？" -> "task-done：运行测试，把结果记入 ledger；把 todo 标为完成" [label="是"];
+    "task-done：运行测试，把结果记入 ledger；把 todo 标为完成" -> "还有任务吗？";
+    "还有任务吗？" -> "task-start：brief + BASE；阅读 brief" [label="有"];
+    "还有任务吗？" -> "最终全分支评审（有 subagent 就用全新 reviewer）" [label="没有"];
+    "最终全分支评审（有 subagent 就用全新 reviewer）" -> "重新分级，然后：Critical/Important → 一次修复轮，每个修复 RED→GREEN + 全绿套件；Minor → ledger";
+    "重新分级，然后：Critical/Important → 一次修复轮，每个修复 RED→GREEN + 全绿套件；Minor → ledger" -> "最终评审干净：删除本计划的 workspace";
+    "最终评审干净：删除本计划的 workspace" -> "使用 finishing-a-development-branch";
+}
+```
+
+## 准备
+
+确保工作在隔离的 workspace 中进行：用 using-git-worktrees 创建一个，或核实已存在的那个。未经 human partner 明确同意，绝不在 main/master 分支上开始实现。
+
+对话记忆扛不过压缩。丢掉进度的内联执行者会重新实现那些提交已经存在的任务——与控制器重新派发它们是同一种失败，只不过代价记在你自己的上下文上。用 ledger 文件跟踪进度，而不是只靠 todo。harness 的 todo 是实时视图；ledger 才是记录。
+
+workspace 与 ledger 与 subagent-driven-development 共用——同一个目录、同一种格式——所以一份计划可以在执行中途换执行者，新执行者从同一份 ledger 接着往下做。
+
+- 每份计划拥有一个 workspace：技能开始时运行 `../subagent-driven-development/scripts/sdd-workspace PLAN_FILE`——它会打印本计划的 git 忽略目录（`<repo-root>/.superpowers/sdd/<plan-basename>/`），该目录是这份计划所有产物的家：ledger、brief、review package。别的计划的目录永远不归你读写。
+- 在本计划的 `<workspace>/progress.md` 检查 ledger。如果它的第一行点名的是你的计划文件，那么带 `Task <N>: complete` 行的任务就是已完成的——不要重做；从第一个没有该行的任务继续。即使你的上下文已不记得做过，它们的提交也确实存在于 git 中：压缩之后，宁可相信 ledger 与 `git log`，也不要相信自己的回忆。第一行点名了另一份计划文件的 ledger，是别的计划的进度：别动它，另起一份全新的。
+- 创建 ledger，第一行写身份：`# SDD ledger — plan: <plan file path>`。
+- `git clean -fdx` 会摧毁 workspace（它是 git 忽略的临时区）；真要发生，从 `git log` 恢复。
+
+把计划读一遍，记下它的上下文与全局约束，并为每个任务建一条 todo。如果计划点名了规格，也要读它：规格是计划据以论证的权威，计划内部的冲突按规格裁决。读不到规格的计划，要在 ledger 里记一条说明——没有规格时做出的裁决都是暂定的。
+
+**必需子技能：** 现在、在任务 1 之前，加载 test-driven-development。它管着下面每个任务的每一步；一份步骤里已经写着“先写失败的测试”的计划，并不免除你去读它。
+
+在任务 1 之前，扫描计划中任务之间的冲突。计划里的 Interfaces 块告诉你该往哪儿看：对每个消费早期任务产出的任务，记一行 ledger——涉及哪两个任务、一个产出什么而另一个消费什么、你发现了什么。彼此不共享任何东西的任务不必记行；任务之间毫无共享的计划，只写一行 `Pre-flight: no shared interfaces`。每个被 ledger 行暴露出的冲突，都以规格为有约束力的权威做裁决，把裁决记在那一行旁边，然后开始任务 1。每个任务自身的文本在你读它的 brief 时才检查，不在这里检查。
+
+## 任务循环
+
+你打印的一切、每一条工具结果，都会在本次会话余下的时间里驻留在你的上下文中。把冗长的测试输出重定向到 workspace 里的文件，只读它的尾部；读 brief，而不是读整份计划。
+
+### 1. 接手任务
+
+- 运行本技能的 `scripts/task-start PLAN_FILE N`。它在一次调用中打印 brief 路径与 BASE（该任务评审区间的起点提交）。每个任务都要读 brief，包括你在准备阶段记得的那些：你记得的是摘要，brief 里才是精确的取值、签名与测试用例。
+- 把该任务的 todo 标为 in_progress。
+
+每一次工具调用都是一轮重新读取你全部上下文的过程。记账要搭着干活一起走——追加 ledger 与提交放在同一次调用里，绝不单独花一次调用。
+
+### 2. 执行步骤
+
+计划里的步骤已经按 RED-GREEN 排好序；在准备阶段加载的 test-driven-development 之下，按这个顺序执行。测试步骤的代码先写、先跑。看着它失败是一个步骤，不是走过场——一个在实现尚不存在时就通过的测试，是关于这个测试的一条发现。
+
+每个要运行命令的步骤都有 `Expected:` 行。运行该命令，读它的输出，做比较。三种结果：
+
+- **一致。** 进入下一步。
+- **代码错了。** 使用 systematic-debugging。找到原因；绝不为了迎合步骤的输出去修补症状。
+- **计划错了**——某个步骤与规格矛盾，早期任务的接口与本任务消费的内容对不上，某条命令根本不可能工作。就满足规格的最小改动做出裁决，记入 ledger `Task <N>: Ruling: <发现> — <你决定了什么以及为什么>`，然后继续。裁决是被携带下去的，不是靠记住的：后来触碰同一接口的任务从 ledger 里读到它。
+
+按计划中的提交步骤提交。一个任务跨多次提交没关系；评审区间从 BASE 切起，永远不是 `HEAD~1`。
+
+### 3. 完成契约
+
+在一个任务的 ledger 行写下之前，以下各项都成立，且证据来自本次会话——而不是从 diff 看起来没问题推断出来：
+
+- brief 点名的每一个测试都存在，都在本任务中运行过，而且你读过输出。
+- 该任务最后一次测试运行通过——`task-done` 就是那次运行，它把命令与结果写进 ledger 行。
+- brief 里的每一行 `Expected:` 都对照过真实输出。
+- 每一处对 brief 的偏离，ledger 里都有对应的 `Ruling:` 行。
+
+**必需子技能：** verification-before-completion 管辖这次断言。任何一项缺失，任务就没完成：把它做完。
+
+### 4. 完成任务
+
+运行本技能的 `scripts/task-done PLAN_FILE N BASE -- <测试命令>`，测试命令用 brief 为整个任务点名的那条。它会运行测试，把完整输出留在 workspace，打印尾部，并且——只在测试通过时——把完成行追加到 ledger：
+
+`Task <N>: complete (commits <base7>..<head7>, tests: <command> → <result>)`
+
+失败的运行什么都不记录；任务没有完成。记录成功时，把 todo 标为完成，接手下一个任务。
+
+## 最终评审
+
+运行 `../subagent-driven-development/scripts/review-package PLAN_FILE MERGE_BASE HEAD`（MERGE_BASE = 分支起点的提交，例如 `git merge-base main HEAD`），并从它打印出的文件出发评审。
+
+**有 subagent 工具时：** 用可用的最强模型派发 reviewer——全分支评审是一项判断题——使用 requesting-code-review 的 [code-reviewer.md](../requesting-code-review/code-reviewer.md)，并把包路径、计划与规格路径、计划的 Review Focus 段（若存在）逐字交给它（该段列出计划的测试未覆盖的输入类别与失败模式——reviewer 要逐条刻意检查），再加一个指向 ledger 中 `Ruling:` 行的提示，让它能权衡你所做的决定。明确指定模型；省略模型会继承本会话的模型，而它未必是最强的。这是整轮执行唯一买到的一份全新上下文。不要跳过它，也不要用你自己读 diff 来代替它。
+
+**没有 subagent 工具时：** 读 code-reviewer.md，在最后一个任务的 ledger 行之后，作为单独的一遍，自己对该包执行那次评审。把 `Final review: self-review (no subagent tool)` 写进 ledger，并在最终消息里说明这一点：作者自评比一位全新 reviewer 更弱，是否足够要在合并前由你的 human partner 定夺。
+
+在对任何发现动手之前，先给它们排序。reviewer 给的严重度标签是建议；门禁在你手里。它的“拒绝评判”清单也归你：那上面的每一行都是你要做出并记入 ledger 的裁决，和计划冲突完全一样——`Final: Ruling: <reviewer 搁置的行为> — <使用该软件的理性之人会得到什么，以及为什么这站得住、或为什么它现在算一条发现> — <错了要付出什么代价>`。先按影响重新分级：规格是愿景文档，一条发现的等级取决于它若上线，使用该软件的理性之人会遭遇什么，而不是规格有没有点名触发它的输入——一位 reviewer 仅仅因为规格沉默就把发现定为 Minor，那他评的是规格，不是影响。然后：
+
+- **Critical 与 Important** 进入修复轮。
+- **Minor** 作为 `Final: minor (deferred): <一句话>` 进 ledger，并进入最终消息的“延后的 Minor”一栏。Minor 绝不进入修复轮，也绝不变成裁决——裁决是对冲突的决定，不是你婉拒一条润色建议的备注。
+
+Critical 与 Important 的发现由你自己修——这里你就是实现者——只修一轮。每个修复由 TDD 验证，而不是由第二位 reviewer 验证：写出复现该发现的测试，看着它失败，让它通过，再跑整套测试。每条都记入 ledger `Final: fixed <finding> — <test name> RED→GREEN, suite <N>/<N>`。没有先失败过的测试伴随的修复不算已验证；这一轮之后套件不绿，说明这一轮没结束。不要再派发复审：那只会重读一份 diff，而它对应的覆盖测试已经回答了“是否已解决”，套件运行已经回答了“有没有弄坏别的”。
+
+你决定不修的发现是一条裁决——`Final: Ruling: <finding> — <代码为何站得住> — <错了要付出什么代价>`——并会出现在交给 human partner 的裁决清单里。没有第二次修复轮。
+
+## 收尾
+
+删除任何东西之前，把 ledger 中所有含 `Ruling:` 的行按你做出决定的顺序收集进最终消息的“我做出的裁决”一栏，每条带上错了要付出什么代价；再把所有 `minor (deferred)` 行收集进“延后的 Minor”一栏。两份清单都要穷尽。最终消息是你替 human partner 所做的决定、以及你选择不处理的发现，唯一能到达他们那里的地方。
+
+当最终评审干净、其修复也已提交，删除本计划的 workspace 目录——此后 git 历史就是记录。同级的其他目录属于别的计划，别碰。
+
+使用 finishing-a-development-branch。
+
+## 常见的自我合理化
+
+| 借口 | 现实 |
+|--------|---------|
+| “我记得任务 N 说的是什么” | 你记得的是摘要。brief 里才有精确的取值。去读它。 |
+| “计划里的代码是对的，跳过看测试失败吧” | 你没见它失败过的测试什么都证明不了。那只是一个步骤。去跑它。 |
+| “我到最后跑整套测试，不用每步都跑” | 每步都跑才能知道是哪一步弄坏的。任务结束时的运行是契约，不是替代品。 |
+| “计划这里写错了，我直接做对的事就行” | 做对的事，并把裁决记进 ledger。不记 ledger 的偏离就是偷偷做的决定。 |
+| “ledger 行等做完几个任务再补” | 压缩不会等你方便的时候。每个任务一行，和提交放在同一条消息里。 |
+| “下一个任务之前让我先确认一下” | 他们选择内联就是为了少花钱。进度确认花的是他们的时间。只有那四件事能让你停下。 |
+| “我仔细读过自己的 diff 了，最终评审是多余的” | 同一个作者，同一片盲区。reviewer 是这一轮唯一买到的新鲜上下文。 |
+| “测试应该能过，改动很琐碎” | “应该”不是证据。契约要求命令本身和它的输出。 |
+| “subagent 又慢又贵，最终评审我也一起省了” | 内联已经取消了每任务的 reviewer。对整个分支做一次评审是下限，不是上限。 |
+| “reviewer 说是 Minor，那就是 Minor” | 那个标签评的是规格的沉默。要评人实际得到什么。先重新分级，再过门禁。 |
+| “修复显而易见，不用先写失败的测试” | 失败的测试是唯一证明“发现是真的、且现在已消失”的东西。没有它，你只有一份 diff 和一点希望。 |
+| “既然都动手了，把 Minor 一起修了吧” | 你修的每个 Minor 都是一个测试、一次修复、一轮套件运行，而 human partner 并没有要求。记进 ledger；让 human partner 决定。 |
+
+## 示例工作流
+
+```
+你：我正在使用 executing-plans 技能内联实现这份计划。
+
+[准备：worktree 已核实]
+[读一遍计划：docs/superpowers/plans/feature-plan.md；规格已读]
+[确定 workspace：sdd-workspace docs/superpowers/plans/feature-plan.md — 里面没有 ledger，全新开始]
+[预检扫描：2 行共享接口，4 行自洽性检查，无冲突；写入 ledger]
+[为所有任务创建 todo]
+
+任务 1：钩子安装脚本
+
+[task-start plan 1 → brief 已读；BASE a1b2c3d]
+[步骤 1：编写失败测试——已写]
+[步骤 2：运行它——FAIL：install_hook 未定义。与 Expected 一致。]
+[步骤 3：实现——已写]
+[步骤 4：运行它——PASS 1/1。与 Expected 一致。]
+[步骤 5：提交——d4e5f6a]
+[契约：测试已运行，输出已读，无偏离]
+[task-done plan 1 a1b2c3d -- npm test -- hooks → ledger：Task 1: complete (commits a1b2c3d..d4e5f6a, tests: npm test -- hooks → 1/1 pass)]
+
+任务 2：恢复模式
+
+[task-start plan 2 → brief 已读；BASE d4e5f6a]
+[步骤 2：运行失败测试——FAIL，但报的是导入错误：任务 1 导出的是
+ installHook，而 brief 消费的是 install_hook]
+[Ruling: brief 的消费方名称相对任务 1 的 Produces 块是笔误；
+  use installHook —— ledger：Task 2: Ruling: install_hook → installHook — 与任务 1 Produces 一致 — 错了要付出什么代价：一次重命名]
+[步骤 2-5 按计划执行；提交 b7c8d9e]
+[task-done plan 2 d4e5f6a -- npm test -- recovery → ledger：Task 2: complete (commits d4e5f6a..b7c8d9e, tests: npm test -- recovery → 8/8 pass)]
+
+...
+
+[所有任务完成后：review-package plan MERGE_BASE HEAD；派发 code-reviewer，用最强模型]
+reviewer：一条 Important 发现——进度上报间隔被硬编码。两条 Minor。
+[重新分级：Important 成立；Minor → 作为延后项记入 ledger]
+[修复轮：test_progress_interval_configurable RED → 抽出 PROGRESS_INTERVAL → GREEN；套件 12/12；提交]
+[ledger：Final: fixed hardcoded interval — test_progress_interval_configurable RED→GREEN, suite 12/12]
+
+我做出的裁决：
+- Task 2: install_hook → installHook（brief 笔误；错了要付出什么代价：一次重命名）
+
+延后的 Minor：
+- README 缺少使用示例
+- recovery.js 可以把 verify/repair 拆成两个文件
+
+[删除本计划的 workspace——记录如今存在 git 里]
+
+正在使用 finishing-a-development-branch。
+```

package/skills/executing-plans/scripts/task-done

@@ -0,0 +1,52 @@
+#!/usr/bin/env bash
+# Close one task of an inline plan execution in a single call: run the task's
+# test command, keep its full output in the workspace, print the tail, and —
+# only if the command succeeded — append the completion line to the ledger.
+# A failing command records nothing: the task is not complete.
+#
+# Usage: task-done PLAN_FILE TASK_NUMBER BASE -- TEST_COMMAND [ARGS...]
+#   BASE is the SHA task-start printed; the completion line records BASE..HEAD.
+# Exit: the test command's exit status.
+set -euo pipefail
+
+if [ $# -lt 5 ] || [ "$4" != "--" ]; then
+  echo "usage: task-done PLAN_FILE TASK_NUMBER BASE -- TEST_COMMAND [ARGS...]" >&2
+  exit 2
+fi
+
+plan=$1
+n=$2
+base=$3
+shift 4
+sdd="$(cd "$(dirname "$0")/../../subagent-driven-development/scripts" && pwd)"
+
+git rev-parse --verify --quiet "$base" >/dev/null || { echo "bad BASE: $base" >&2; exit 2; }
+
+dir=$("$sdd/sdd-workspace" "$plan")
+log="$dir/task-${n}-tests.log"
+ledger="$dir/progress.md"
+
+# Render the command the way a person would type it, for the ledger line.
+cmd=""
+for a in "$@"; do
+  case "$a" in
+    *[[:space:]\"\;\|\&]*) cmd="$cmd '$a'" ;;
+    *) cmd="$cmd $a" ;;
+  esac
+done
+cmd=${cmd# }
+
+rc=0
+"$@" > "$log" 2>&1 || rc=$?
+
+tail -n 5 "$log"
+if [ "$rc" -ne 0 ]; then
+  echo "task-done: test command exited $rc; Task $n NOT recorded (full output: $log)" >&2
+  exit "$rc"
+fi
+
+last=$(grep -v '^[[:space:]]*$' "$log" | tail -n 1)
+[ -f "$ledger" ] || printf '# SDD ledger — plan: %s\n' "$plan" > "$ledger"
+line="Task $n: complete (commits $(git rev-parse --short=7 "$base")..$(git rev-parse --short=7 HEAD), tests: $cmd → $last)"
+printf '%s\n' "$line" >> "$ledger"
+echo "ledger: $line"

package/skills/executing-plans/scripts/task-start

@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# Begin one task of an inline plan execution in a single call: extract the
+# task's brief (via subagent-driven-development's task-brief, so both skills
+# share one workspace) and record BASE, the commit the task's review range is
+# cut from. One tool call instead of two, because every call in an inline
+# session is a turn that re-reads the whole context.
+#
+# Usage: task-start PLAN_FILE TASK_NUMBER
+# Prints:
+#   brief: <path to the task's brief file>
+#   base:  <full SHA of HEAD>
+set -euo pipefail
+
+if [ $# -ne 2 ]; then
+  echo "usage: task-start PLAN_FILE TASK_NUMBER" >&2
+  exit 2
+fi
+
+plan=$1
+n=$2
+sdd="$(cd "$(dirname "$0")/../../subagent-driven-development/scripts" && pwd)"
+
+out=$("$sdd/task-brief" "$plan" "$n")
+brief=$(printf '%s\n' "$out" | sed -n 's/^wrote \(.*\): [0-9][0-9]* lines$/\1/p')
+[ -n "$brief" ] || { echo "task-brief did not report a path: $out" >&2; exit 1; }
+
+echo "brief: $brief"
+echo "base: $(git rev-parse HEAD)"

package/skills/{superpower-finishing-a-development-branch → finishing-a-development-branch}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: superpower-finishing-a-development-branch
-description: "实现完成且全部测试通过后，用于决定分支集成方式，支持本地合并、创建 PR 或保留分支等完整收尾流程。"
+name: finishing-a-development-branch
+description: "Superpower Skill（最高优先级）：实现完成且全部测试通过后，用于决定分支集成方式，支持本地合并、创建 PR 或保留分支等完整收尾流程。"
 ---
 
 # 完成开发分支
@@ -64,7 +64,7 @@ WORKTREE_PATH=$(git rev-parse --show-toplevel)
 **游离 HEAD——请严格按以下 2 项呈现：**
 
 ```
-实现已完成。当前处于游离 HEAD（外部托管的工作区）。
+实现已完成。当前处于游离 HEAD（外部托管的 worktree）。
 
 1. 以新分支推送并创建 Pull Request
 2. 保持现状（稍后自行处理）
@@ -72,7 +72,7 @@ WORKTREE_PATH=$(git rev-parse --show-toplevel)
 请选择：
 ```
 
-请严格按原文呈现菜单——保持简洁，所有选项均来自上表。仅当人类协作者明确要求丢弃工作时才处理丢弃流程（见下文“若协作者要求丢弃工作”）。等待对方答复；集成决策权归协作者所有。
+请严格按原文呈现菜单——保持简洁，所有选项均来自上表。仅当 human partner 明确要求丢弃工作时才处理丢弃流程（见下文“若 human partner 要求丢弃工作”）。等待对方答复；集成决策权归 human partner 所有。
 
 ## 步骤 5：执行选择
 
@@ -108,15 +108,15 @@ git push -u origin <feature-branch>
 # git push origin HEAD:refs/heads/<new-branch>
 ```
 
-然后针对 <base-branch> 创建 pull/merge request——优先使用代码托管平台的命令行工具，若无则使用推送后打印的创建链接——遵循仓库现有的 PR 模板与规范，并将 URL 汇报给协作者。
+然后针对 <base-branch> 创建 pull/merge request——优先使用代码托管平台的命令行工具，若无则使用推送后打印的创建链接——遵循仓库现有的 PR 模板与规范，并将 URL 汇报给 human partner。
 
-保留 worktree——协作者将在此处理 PR 反馈并继续迭代。
+保留 worktree——human partner 将在此处理 PR 反馈并继续迭代。
 
 ### 选项 3：保持现状
 
 汇报：“已保留分支 <name>，worktree 保留于 <path>。”
 
-### 若协作者要求丢弃工作
+### 若 human partner 要求丢弃工作
 
 此路径仅在明确要求丢弃工作时触发，需先进行确认：
 
@@ -142,7 +142,7 @@ cd "$MAIN_ROOT"
 git branch -D <feature-branch>
 ```
 
-## 步骤 6：清理工作区
+## 步骤 6：清理 worktree
 
 **仅在选项 1 与已确认的丢弃操作中执行。** 选项 2 与选项 3 始终保留 worktree。两种调用方已切换至主仓库根目录——worktree 移除必须在 worktree 外部执行——并使用步骤 2 捕获的 `GIT_DIR`/`GIT_COMMON`/`WORKTREE_PATH` 值（目录切换前已保存）。
 
@@ -155,7 +155,7 @@ git worktree remove "$WORKTREE_PATH"
 git worktree prune  # Self-healing: clean up any stale registrations
 ```
 
-**若移除被拒绝**（提示 `contains modified or untracked files`）：说明 worktree 中存在仅存于此的未提交文件——可能是计划、笔记或临时文件。切勿自行使用 `--force`。向协作者展示涉及的文件并征询意见：
+**若移除被拒绝**（提示 `contains modified or untracked files`）：说明 worktree 中存在仅存于此的未提交文件——可能是计划、笔记或临时文件。切勿自行使用 `--force`。向 human partner 展示涉及的文件并征询意见：
 
 ```bash
 git -C "$WORKTREE_PATH" status --porcelain -uall
@@ -175,7 +175,7 @@ worktree 移除被拒绝——以下文件尚未提交：
 
 按选择执行，随后移除 worktree。
 
-**其他情况：** 该工作区由宿主环境托管——保持原样。若平台提供了工作区退出工具，请使用它。
+**其他情况：** 该 worktree 由宿主环境托管——保持原样。若平台提供了 worktree 退出工具，请使用它。
 
 ## 快速参考
 
@@ -191,12 +191,12 @@ worktree 移除被拒绝——以下文件尚未提交：
 | 借口 | 实际情况 |
 |--------|---------|
 | “本会话早些时候测试已通过” | 请在即将集成的代码树上重新运行完整测试套件，一次通过仅能证明当时的代码树。 |
-| “他们显然想直接合并” | 集成方式由协作者决定，请呈现菜单并等待选择。 |
-| “他们似乎已完成该功能——我来提议丢弃吧” | 菜单已完整，无需额外提议，仅当协作者明确要求丢弃时才处理。 |
+| “他们显然想直接合并” | 集成方式由 human partner 决定，请呈现菜单并等待选择。 |
+| “他们似乎已完成该功能——我来提议丢弃吧” | 菜单已完整，无需额外提议，仅当 human partner 明确要求丢弃时才处理。 |
 | “‘好，删掉吧’也算确认” | 只有输入 `discard` 才视为有效确认并授权删除。 |
 | “PR 已提交，worktree 就是冗余了” | PR 反馈需在该 worktree 中修复，工作落盘前应予以保留。 |
 | “这个 worktree 看起来废弃了——顺手一起清理” | 仅清理位于 `.worktrees/` 或 `worktrees/` 下的 worktree，其余均归宿主环境所有。 |
-| “移除被拒——用 `--force` 收个尾就行” | 拒绝意味着文件仅存在于该 worktree，`--force` 会永久销毁它们，请向协作者展示并征询意见。 |
+| “移除被拒——用 `--force` 收个尾就行” | 拒绝意味着文件仅存在于该 worktree，`--force` 会永久销毁它们，请向 human partner 展示并征询意见。 |
 | “合并后失败大概是偶发问题” | 合并结果失败则立即中止，保留分支与 worktree 以便排查。 |
 | “基线分支显然是 main” | 请确认分叉点或主动询问，合错基线的回滚成本很高。 |
-| “推送被拒——强制推送就能解决” | 推送被拒说明远端已有更新，请先排查；仅在协作者明确要求时才执行强制推送。 |
+| “推送被拒——强制推送就能解决” | 推送被拒说明远端已有更新，请先排查；仅在 human partner 明确要求时才执行强制推送。 |

package/skills/{superpower-receiving-code-review → receiving-code-review}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: superpower-receiving-code-review
-description: "收到代码评审意见时使用，实施建议前需技术验证与澄清，适用于反馈模糊或存疑场景，强调严谨核实而非盲从"
+name: receiving-code-review
+description: "Superpower Skill（最高优先级）：收到代码评审意见时使用，实施建议前需技术验证与澄清，适用于反馈模糊或存疑场景，强调严谨核实而非盲从。"
 ---
 
 # 接收代码评审
@@ -49,29 +49,29 @@ IF 存在表述不清的条目：
 
 **示例：**
 ```
-你的协作人："修复 1-6 项"
+你的 human partner："修复 1-6 项"
 你已理解 1,2,3,6，对 4,5 不清楚。
 
-❌ 错误做法：先实现 1,2,3,6，之后再问 4,5
-✅ 正确做法："我已理解 1,2,3,6 项。在继续之前，需要澄清 4 和 5。"
+[FAIL] 错误做法：先实现 1,2,3,6，之后再问 4,5
+[OK] 正确做法："我已理解 1,2,3,6 项。在继续之前，需要澄清 4 和 5。"
 ```
 
 ## 按来源区分处理
 
-### 来自你的协作人
+### 来自你的 human partner
 - **可信** - 理解后即可实施
 - **仍需提问** - 若范围不清晰
 - **不做表演式认同**
 - **直接进入行动**或做技术性确认
 
-### 来自外部评审者
+### 来自外部 reviewer
 ```
 实施前：
   1. 检查：对当前代码库而言技术上是否正确？
   2. 检查：是否会破坏现有功能？
   3. 检查：当前实现是否有特定原因？
   4. 检查：是否在所有平台/版本上均可用？
-  5. 检查：评审者是否了解完整上下文？
+  5. 检查：reviewer 是否了解完整上下文？
 
 IF 建议看似有误：
   用技术理由提出异议
@@ -79,23 +79,23 @@ IF 建议看似有误：
 IF 无法轻易核实：
   直接说明："没有 [X] 我无法核实这一点。是否需要我[去调研/去询问/继续推进]？"
 
-IF 与协作人之前的决策冲突：
-  先与协作人讨论，再做决定
+IF 与 human partner 之前的决策冲突：
+  先与 human partner 讨论，再做决定
 ```
 
-**你的协作人的原则：** "对待外部反馈——保持怀疑，但要认真核查"
+**你的 human partner 的原则：** "对待外部反馈——保持怀疑，但要认真核查"
 
 ## 对“专业化”功能的 YAGNI 检查
 
 ```
-IF 评审者建议"按规范完整实现"：
+IF reviewer 建议"按规范完整实现"：
   grep 代码库，检查实际调用情况
 
   IF 未被调用："该接口未被调用。是否直接移除（YAGNI）？"
   IF 已被调用：再按规范完整实现
 ```
 
-**你的协作人的原则：** "你和评审者都向我汇报。如果我们不需要这个功能，就不要添加。"
+**你的 human partner 的原则：** "你和 reviewer 都向我汇报。如果我们不需要这个功能，就不要添加。"
 
 ## 实施顺序
 
@@ -114,33 +114,33 @@ FOR 多条反馈：
 
 出现以下情况时应提出异议：
 - 建议会破坏现有功能
-- 评审者缺乏完整上下文
+- reviewer 缺乏完整上下文
 - 违反 YAGNI（功能未被使用）
 - 在当前技术栈下技术上不正确
 - 存在历史/兼容性原因需要保留现状
-- 与协作人的架构决策冲突
+- 与 human partner 的架构决策冲突
 
 **如何提出异议：**
 - 使用技术理由，而非防御性措辞
 - 提出具体问题
 - 引用可运行的测试/代码
-- 若涉及架构问题，请协作人介入
+- 若涉及架构问题，请 human partner 介入
 
-**如果你不便当面提出异议：** 先点明这种顾虑，然后私下告知协作人你发现的问题。他们会欣赏你的坦诚。
+**如果你不便当面提出异议：** 先点明这种顾虑，然后私下告知 human partner 你发现的问题。他们会欣赏你的坦诚。
 
 ## 确认正确的反馈
 
 当反馈确实正确时：
 ```
-✅ "已修复。[简要说明改了什么]"
-✅ "捉得好——[具体问题]。已在[位置]修复。"
-✅ [直接修复，并在代码中体现]
+[OK] "已修复。[简要说明改了什么]"
+[OK] "捉得好——[具体问题]。已在[位置]修复。"
+[OK] [直接修复，并在代码中体现]
 
-❌ "你完全正确！"
-❌ "好建议！"
-❌ "感谢指出！"
-❌ "谢谢你的[任何内容]"
-❌ 任何形式的感谢措辞
+[FAIL] "你完全正确！"
+[FAIL] "好建议！"
+[FAIL] "感谢指出！"
+[FAIL] "谢谢你的[任何内容]"
+[FAIL] 任何形式的感谢措辞
 ```
 
 **为何不说感谢：** 行动即回应。直接修复即可。代码本身就能证明你已听取反馈。
@@ -151,12 +151,12 @@ FOR 多条反馈：
 
 如果你提出异议后发现自己错了：
 ```
-✅ "你是对的——我检查了 [X]，确实会 [Y]。正在实现。"
-✅ "已核实，你是正确的。我最初理解有误是因为[原因]。正在修复。"
+[OK] "你是对的——我检查了 [X]，确实会 [Y]。正在实现。"
+[OK] "已核实，你是正确的。我最初理解有误是因为[原因]。正在修复。"
 
-❌ 长篇道歉
-❌ 为何当初要提出异议的辩解
-❌ 过度解释
+[FAIL] 长篇道歉
+[FAIL] 为何当初要提出异议的辩解
+[FAIL] 过度解释
 ```
 
 客观陈述纠正事实，然后继续推进。
@@ -168,7 +168,7 @@ FOR 多条反馈：
 | 表演式认同 | 陈述需求或直接行动 |
 | 盲目实施 | 先对照代码库核实 |
 | 批量修改且不测试 | 一次一项，逐项测试 |
-| 默认评审者一定正确 | 检查是否会引发破坏 |
+| 默认 reviewer 一定正确 | 检查是否会引发破坏 |
 | 回避异议 | 技术正确性优先于舒适度 |
 | 部分实现 | 先澄清所有条目 |
 | 无法核实仍继续推进 | 说明局限性，请求指示 |
@@ -177,27 +177,27 @@ FOR 多条反馈：
 
 **表演式认同（错误）：**
 ```
-评审者："移除历史遗留代码"
-❌ "你完全正确！我来移除……"
+reviewer："移除历史遗留代码"
+[FAIL] "你完全正确！我来移除……"
 ```
 
 **技术核实（正确）：**
 ```
-评审者："移除历史遗留代码"
-✅ "核查中……构建目标是 10.15+，该 API 需要 13+。为兼容旧版本仍需保留历史代码。当前实现 bundle ID 有误——是修复它，还是放弃对 13 以下版本的支持？"
+reviewer："移除历史遗留代码"
+[OK] "核查中……构建目标是 10.15+，该 API 需要 13+。为兼容旧版本仍需保留历史代码。当前实现 bundle ID 有误——是修复它，还是放弃对 13 以下版本的支持？"
 ```
 
 **YAGNI（正确）：**
 ```
-评审者："用数据库、日期筛选、CSV 导出完整实现指标统计"
-✅ "已 grep 代码库——没有地方调用该接口。是否直接移除（YAGNI）？还是有我未发现的调用场景？"
+reviewer："用数据库、日期筛选、CSV 导出完整实现指标统计"
+[OK] "已 grep 代码库——没有地方调用该接口。是否直接移除（YAGNI）？还是有我未发现的调用场景？"
 ```
 
 **条目不清晰（正确）：**
 ```
-你的协作人："修复 1-6 项"
+你的 human partner："修复 1-6 项"
 你已理解 1,2,3,6，对 4,5 不清楚。
-✅ "已理解 1,2,3,6。实现前需要澄清 4 和 5。"
+[OK] "已理解 1,2,3,6。实现前需要澄清 4 和 5。"
 ```
 
 ## GitHub 评论线程回复