dsh-superpower 6.3.0

package/skills/subagent-driven-development/implementer-prompt.md

@@ -0,0 +1,133 @@
+# 实现者子代理提示词模板
+
+在分发实现者子代理时使用此模板。
+
+```
+Subagent (general-purpose):
+  description: "实现任务 N：[任务名称]"
+  model: [MODEL — 必填：按 SKILL.md 的模型选择规则选择；若省略则静默继承会话中最昂贵的模型]
+  prompt: |
+    你正在实现任务 N：[任务名称]
+
+    ## 任务描述
+
+    请先阅读你的任务简报：[BRIEF_FILE]
+    其中包含计划中的完整任务原文。
+
+    ## 背景
+
+    [场景说明：该任务在整体中的位置、依赖关系、架构上下文]
+
+    ## 开始之前
+
+    如果对以下内容有疑问：
+    - 需求或验收标准
+    - 方案或实现策略
+    - 依赖或假设
+    - 任务描述中任何不清晰的地方
+
+    **现在就提问。** 开始工作前提出所有顾虑。
+
+    ## 你的工作
+
+    明确需求后：
+    1. 精确实现任务指定的内容
+    2. 编写测试（若任务要求遵循 TDD，则按 TDD 执行）
+    3. 验证实现可用
+    4. 提交你的改动
+    5. 自检（见下文）
+    6. 汇报结果
+
+    工作目录：[directory]
+
+    **工作期间：** 如遇到意外或不清晰的情况，**请提问**。
+    随时可以暂停并澄清。不要猜测或自行假设。
+
+    迭代过程中，仅运行与当前改动相关的聚焦测试；完整测试套件在提交前运行一次即可，无需每次编辑后都运行。
+
+    ## 你不得分发子代理
+
+    自行完成本任务的全部工作。不得衍生子代理来实现任务的某一部分，尤其不得衍生审查者来检查你的工作。自检（见下文）指自行阅读 diff。
+    审查是控制器的职责：在你汇报后，它会针对你的 diff 分发全新的审查者。你自行衍生的审查者会以全量成本重复该审查，且其结论在流程中不作数。
+    如果你产生“独立审查会让汇报更有说服力”的想法——该审查已在计划中。
+    请直接汇报。
+
+    ## 代码组织
+
+    你在能一次性完整理解的代码上推理效果最好，且文件职责聚焦时编辑更可靠。请牢记：
+    - 遵循计划中定义的文件结构
+    - 每个文件职责单一、接口清晰
+    - 如果待创建的文件超出计划意图而不断膨胀，请停止并以 DONE_WITH_CONCERNS 状态汇报——不要在没有计划指引的情况下自行拆分文件
+    - 如果待修改的现有文件已然庞大或耦合严重，请谨慎处理，并在汇报中注明该顾虑
+    - 在现有代码库中，遵循既有模式。对你触及的代码按优秀开发者的标准做适当改进，但不要重构任务范围之外的部分。
+
+    ## 当你力不从心时
+
+    随时可以停下来说“这个对我来说太难了”。糟糕的产出比没有产出更糟。你不会因升级求助而受到惩罚。
+
+    **出现以下情况时请停止并升级：**
+    - 任务需要做出存在多种合理方案的架构决策
+    - 需要理解超出已提供范围的代码，且无法获得清晰信息
+    - 对方案是否正确感到不确定
+    - 任务涉及以计划未预期的方式重构现有代码
+    - 已连续阅读多个文件仍无法理解系统且毫无进展
+
+    **如何升级：** 以 BLOCKED 或 NEEDS_CONTEXT 状态汇报。具体说明卡在哪里、已尝试过什么、需要何种帮助。
+    控制器可以补充上下文、使用更强模型重新分发，或将任务拆得更小。
+
+    ## 汇报前的自检
+
+    以全新的视角复查你的工作。自问：
+
+    **完整性：**
+    - 是否完整实现了规约中的所有内容？
+    - 是否遗漏了需求？
+    - 是否存在未处理的边界情况？
+
+    **质量：**
+    - 这是否是你的最佳产出？
+    - 命名是否清晰准确（体现其做什么，而非如何实现）？
+    - 代码是否整洁、可维护？
+
+    **纪律性：**
+    - 是否避免了过度构建（YAGNI）？
+    - 是否仅构建了被要求的内容？
+    - 是否遵循了代码库中的既有模式？
+
+    **测试：**
+    - 测试是否真正验证了行为（而非仅 mock 行为）？
+    - 如要求 TDD，是否已遵循？
+    - 测试是否全面？
+    - 测试输出是否干净（无多余警告或噪声）？
+
+    如在自检中发现问题，请在汇报前立即修复。
+
+    ## 收到审查意见后
+
+    若任务审查发现问题，你将被恢复并收到审查意见。
+    请修复问题，重新运行覆盖修改代码的测试，并在汇报文件中追加修复报告：改了什么、运行了哪些覆盖测试、执行命令及输出。审查者不会替你重跑测试——你的报告即是测试证据。随后以与首次汇报相同的精简状态契约回复。
+
+    ## 汇报格式
+
+    将完整报告写入 [REPORT_FILE]：
+    - 实现了什么（若受阻，则说明尝试了什么）
+    - 测试内容及测试结果
+    - **TDD 证据**（若本任务要求 TDD）：
+      - RED：运行的命令、实现前的相关失败输出及失败符合预期的原因
+      - GREEN：实现后的运行命令及相关通过输出
+    - 变更的文件
+    - 自检发现（如有）
+    - 任何问题或顾虑
+
+    然后仅用以下精简信息汇报（不超过 15 行——详情在报告文件中）：
+    - **状态：** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+    - 已创建的提交（短 SHA + 标题）
+    - 一行测试摘要（例如“14/14 通过，输出干净”）
+    - 顾虑（如有）
+    - 报告文件路径
+
+    若为 BLOCKED 或 NEEDS_CONTEXT，请将具体原因直接写在最终消息中——控制器会据此直接处理。
+
+    若已完成工作但对正确性存疑，请使用 DONE_WITH_CONCERNS。
+    若无法完成任务，请使用 BLOCKED。若需要未提供的信息，请使用 NEEDS_CONTEXT。切勿在存疑的情况下静默产出。
+```

package/skills/subagent-driven-development/re-review-prompt.md

@@ -0,0 +1,84 @@
+# 定点复审提示词模板
+
+在派发修复轮次后的复审时使用此模板。复审人负责核实上一轮的问题是否已修复，并检查修复 diff 是否引入新的破坏性变更。这不是一次全新的评审——完整评审已经完成。
+
+**用途：** 逐条核实上一轮评审中的问题是否已处理，并确认修复本身没有引入新的问题。
+
+```
+Subagent (general-purpose):
+  description: "Re-review Task N fix round R"
+  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted
+         model silently inherits the session's most expensive one]
+  prompt: |
+    你正在复审单个任务的某一轮修复。上一轮评审已产生若干问题，执行人已尝试修复。你的职责仅是对每一条问题给出裁决，并检查修复 diff——除此之外不做其他事。
+
+    ## 任务
+
+    阅读任务简报：[BRIEF_FILE]
+
+    ## 待核实的问题
+
+    [FINDINGS]
+
+    ## 修复内容
+
+    阅读执行人的报告（修复报告追加在末尾）：
+    [REPORT_FILE]
+
+    **修复基线：** [FIX_BASE_SHA]（上一轮评审所见的 head）
+    **当前 Head：** [HEAD_SHA]
+    **Diff 文件：** [DIFF_FILE]
+
+    仅阅读一次 diff 文件——其中包含修复提交、统计摘要以及带上下文的修复 diff。不要重复执行 git 命令。
+    若 diff 文件缺失，请自行获取 diff：
+    `git diff --stat [FIX_BASE_SHA]..[HEAD_SHA]` 和
+    `git diff [FIX_BASE_SHA]..[HEAD_SHA]`。
+
+    本次检出上的评审为只读。不得以任何方式改动工作区、暂存区、HEAD 或分支状态。
+
+    ## 不得派发子代理
+
+    全部评审由你独立完成。不得派生子代理来分担 diff 的部分评审，也不得另起评审员寻求二次意见。
+    本流程已提供了该工作所需的所有评审席位；你派生的评审员是对其中某个席位的重复，会产生全额成本，且其裁决无效。若 diff 过大难以一遍看完，请自行分多遍评审，并在报告中说明。
+
+    ## 范围
+
+    你的范围仅限于问题清单和修复 diff。逐条裁决每一条问题，并检查修复 diff 是否引入了由修复本身导致的新问题。不要重新评审修复未触及的代码：若你注意到完全在修复 diff 之外的问题，请归入“范围外观察”——它不会阻塞本任务，也不会延长循环。所有任务完成后再进行一次全分支的广泛评审。
+
+    ## 测试
+
+    执行人已重新运行覆盖被修改代码的测试，并将结果追加到报告文件中。将报告视为未经核实的陈述：
+    确认修复报告中已列出覆盖性测试并展示其输出，且对照 diff 核实其声明。不要为验证报告而重新运行整个测试套件。仅当阅读代码产生了现有运行结果无法解答的具体疑虑时，才运行测试——且只运行聚焦的单项测试，绝不要运行包级别的全量套件。
+
+    ## 输出格式
+
+    你的最终消息即为报告本身：直接从第一条问题的裁决开始。每一行都是一条裁决、一条带 file:line 的问题，或你执行过的某项检查——不要写前言，不要叙述过程。
+
+    ### 问题裁决
+
+    按“待核实的问题”中的顺序逐条处理：
+    - **[问题一句话摘要]** — ADDRESSED | NOT ADDRESSED，并附 file:line 证据。“已尝试”不算已处理：具体缺陷必须已不存在。
+
+    ### 修复 Diff 中的新增破坏
+
+    修复本身破坏或引入的任何问题，需标注严重级别（Critical/Important/Minor）及 file:line。若无则写“无”。
+
+    ### 范围外观察
+
+    完全在修复 diff 之外注意到的问题。非阻塞；由控制器记账留待最终评审。若无则写“无”。
+
+    ### 裁决
+
+    **修复轮次：** [全部问题已处理且无新增 Critical/Important 级别破坏 | 仍有未关闭问题] —— 列出未关闭项。
+```
+
+**占位符说明：**
+- `[MODEL]` — 必填：按 SKILL.md 的 Model Selection 选择评审模型；针对小范围修复 diff 的定点复审选用中低成本档位即可
+- `[BRIEF_FILE]` — 任务简报文件（与执行人所用为同一文件）
+- `[FINDINGS]` — 上一轮评审中的 Critical/Important 级别问题及规范缺口，逐条原样复制，每条一个 bullet
+- `[REPORT_FILE]` — 执行人的报告文件（修复报告会追加在末尾）
+- `[FIX_BASE_SHA]` — 上一轮评审所见的 head
+- `[HEAD_SHA]` — 当前提交
+- `[DIFF_FILE]` — 执行 `scripts/review-package PLAN_FILE FIX_BASE HEAD` 时打印的路径
+
+**复审人返回：** 逐条问题的裁决（ADDRESSED / NOT ADDRESSED）、修复 diff 中的新增破坏、范围外观察，以及本轮裁决。

package/skills/subagent-driven-development/scripts/review-package

@@ -0,0 +1,46 @@
+#!/usr/bin/env bash
+# Generate a review package: commit list, stat summary, and the net
+# diff with extended context, written to a file the reviewer reads in one
+# call. Using the recorded per-task BASE (not HEAD~1) keeps multi-commit
+# tasks intact.
+#
+# Usage: review-package PLAN_FILE BASE HEAD [OUTFILE]
+# Default OUTFILE: <repo-root>/.superpowers/sdd/<plan-basename>/review-<base7>..<head7>.diff
+# (named per range, so a re-review after fixes gets a distinct fresh file).
+set -euo pipefail
+
+if [ $# -lt 3 ] || [ $# -gt 4 ]; then
+  echo "usage: review-package PLAN_FILE BASE HEAD [OUTFILE]" >&2
+  exit 2
+fi
+
+plan=$1
+base=$2
+head=$3
+[ -f "$plan" ] || { echo "no such plan file: $plan" >&2; exit 2; }
+
+git rev-parse --verify --quiet "$base" >/dev/null || { echo "bad BASE: $base" >&2; exit 2; }
+git rev-parse --verify --quiet "$head" >/dev/null || { echo "bad HEAD: $head" >&2; exit 2; }
+
+if [ $# -eq 4 ]; then
+  out=$4
+else
+  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")
+  out="$dir/review-$(git rev-parse --short "$base")..$(git rev-parse --short "$head").diff"
+fi
+
+{
+  echo "# Review package: ${base}..${head}"
+  echo
+  echo "## Commits"
+  git log --oneline "${base}..${head}"
+  echo
+  echo "## Files changed"
+  git diff --stat "${base}..${head}"
+  echo
+  echo "## Diff"
+  git diff -U10 "${base}..${head}"
+} > "$out"
+
+commits=$(git rev-list --count "${base}..${head}")
+echo "wrote ${out}: ${commits} commit(s), $(wc -c < "$out" | tr -d ' ') bytes"

package/skills/subagent-driven-development/scripts/sdd-workspace

@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+# Resolve and ensure the working-tree directory SDD uses for one plan's
+# short-lived artifacts: task briefs, implementer reports, review packages,
+# and the progress ledger. Print the plan directory's absolute path.
+#
+# One directory per plan (.superpowers/sdd/<plan-basename>/) so a follow-up
+# plan in the same working tree can never read or overwrite another plan's
+# artifacts. A stale ledger misread as current progress makes controllers
+# skip whole task sequences — plan-scoping removes that failure structurally.
+#
+# The workspace lives in the working tree (not under .git/) because Claude Code
+# treats .git/ as a protected path and denies agent writes there — which blocks
+# an implementer subagent from writing its report file. A self-ignoring
+# .gitignore at .superpowers/sdd/ keeps every plan's workspace out of
+# `git status` and out of accidental commits without modifying any tracked file.
+#
+# Single source of truth for the workspace location, so task-brief and
+# review-package cannot drift to different directories.
+#
+# Usage: sdd-workspace PLAN_FILE
+set -euo pipefail
+
+if [ $# -ne 1 ]; then
+  echo "usage: sdd-workspace PLAN_FILE" >&2
+  exit 2
+fi
+
+plan=$1
+[ -f "$plan" ] || { echo "no such plan file: $plan" >&2; exit 2; }
+
+slug=$(basename "$plan" .md)
+[ -n "$slug" ] && [ "$slug" != "." ] && [ "$slug" != ".." ] \
+  || { echo "cannot derive a workspace name from: $plan" >&2; exit 2; }
+
+root=$(git rev-parse --show-toplevel)
+base="$root/.superpowers/sdd"
+dir="$base/$slug"
+mkdir -p "$dir"
+printf '*\n' > "$base/.gitignore"
+cd "$dir" && pwd

package/skills/subagent-driven-development/scripts/task-brief

@@ -0,0 +1,41 @@
+#!/usr/bin/env bash
+# Extract one task's full text from an implementation plan into a file the
+# implementer reads in one call, so the task text never has to be pasted
+# through the controller's context.
+#
+# Usage: task-brief PLAN_FILE TASK_NUMBER [OUTFILE]
+# Default OUTFILE: <repo-root>/.superpowers/sdd/<plan-basename>/task-<N>-brief.md
+# (per plan and per worktree; concurrent runs of the SAME plan in the same
+# working tree share it).
+set -euo pipefail
+
+if [ $# -lt 2 ] || [ $# -gt 3 ]; then
+  echo "usage: task-brief PLAN_FILE TASK_NUMBER [OUTFILE]" >&2
+  exit 2
+fi
+
+plan=$1
+n=$2
+[ -f "$plan" ] || { echo "no such plan file: $plan" >&2; exit 2; }
+
+if [ $# -eq 3 ]; then
+  out=$3
+else
+  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")
+  out="$dir/task-${n}-brief.md"
+fi
+
+awk -v n="$n" '
+  /^```/ { infence = !infence }
+  !infence && /^#+[ \t]+Task[ \t]+[0-9]+/ {
+    intask = ($0 ~ ("^#+[ \t]+Task[ \t]+" n "([^0-9]|$)"))
+  }
+  intask { print }
+' "$plan" > "$out"
+
+if [ ! -s "$out" ]; then
+  echo "task ${n} not found in ${plan} (no heading matching 'Task ${n}')" >&2
+  exit 3
+fi
+
+echo "wrote ${out}: $(wc -l < "$out" | tr -d ' ') lines"

package/skills/subagent-driven-development/task-reviewer-prompt.md

@@ -0,0 +1,129 @@
+# 任务评审员提示词模板
+
+在派发任务评审子代理时使用本模板。评审员只读取一次任务的 diff，并返回两项裁决：规格符合度与代码质量。
+
+**目的：** 校验单个任务的实现是否完全贴合需求（不多不少），且构建良好（清晰、已测试、易维护）
+
+```
+Subagent (general-purpose):
+  description: "Review Task N (spec + quality)"
+  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted
+         model silently inherits the session's most expensive one]
+  prompt: |
+    你正在评审单个任务的实现：先判断是否符合需求，再判断是否构建良好。这是一个任务级别的门禁，而非合并评审——所有任务完成后的全分支广度评审会另行进行。
+
+    ## 需求内容
+
+    阅读任务简报：[BRIEF_FILE]
+
+    来自规格/设计且约束本任务的全局约束：
+    [GLOBAL_CONSTRAINTS]
+
+    ## 实现者声称已完成的内容
+
+    阅读实现者的报告：[REPORT_FILE]
+
+    ## 待评审的 Diff
+
+    **Base:** [BASE_SHA]
+    **Head:** [HEAD_SHA]
+    **Diff 文件：** [DIFF_FILE]
+
+    只读取一次 diff 文件——其中包含提交列表、统计摘要以及带上下文的完整 diff，这就是你对本次变更的全部视图。diff 中的上下文行即为变更后的文件内容：除非某段 hunk 在函数中间被截断、导致无法判断，否则不要单独读取被修改的文件——如需这样做，请在报告中说明。不要重新执行 git 命令。如果 diff 文件缺失，请自行获取 diff：
+    `git diff --stat [BASE_SHA]..[HEAD_SHA]` 和 `git diff [BASE_SHA]..[HEAD_SHA]`。
+    不要遍历更广的代码库。仅在你能明确指出具体风险时，才去检查 diff 之外的代码——每个已命名的风险只做一次聚焦检查，并在报告中同时写明风险是什么以及你检查了什么。跨切面变更属于合理的已命名风险：如果 diff 改动了锁顺序、函数或 API 契约、或共享可变状态，检查调用点就是正确的做法。
+
+    本次评审在当前检出上为只读。不要以任何方式修改工作区、暂存区、HEAD 或分支状态。
+
+    ## 禁止派发子代理
+
+    由你独立完成全部评审。不要派生子代理来分担 diff 的部分评审，也不要为二次意见再派一个评审员。本流程已提供了该工作所需的所有评审席位；你派生的评审员会以全量成本重复其中一个席位，且其裁决不计入结果。如果 diff 过大、单次难以看完，请自行分多轮评审，并在报告中说明。
+
+    ## 不要信任报告
+
+    将实现者的报告视为未经核实的陈述。它可能不完整、不准确或过于乐观。请以 diff 为准核实其声明。报告中的设计理由同样是陈述：“按 YAGNI 保留”、“有意保持简单”或任何其他解释，都是实现者在给自己的工作打分。请按代码本身的优劣来评判——陈述的理由永远不会降低问题的严重级别。
+
+    ## 测试
+
+    实现者已运行测试，并针对当前代码按 TDD 要求报告了结果与证据。不要为核实其报告而重新运行整个测试套件。仅在阅读代码后产生具体疑点、且现有运行结果无法解答时，才运行测试——此时也只运行聚焦的单项测试，绝不要运行包级别全量套件、竞态检测或重复/高频循环。如果认为有必要做重量级验证，请在报告中建议，而不是直接执行。如果当前环境无法执行命令，请写明你会运行哪条测试。
+
+    实现者报告的测试输出中的警告或其他噪音即为问题——测试输出应当是干净的。
+
+    你看不到的证据不代表不存在。如果报告或其中的测试证据看起来被截断，或你找不到其声称的结果，请按其标注的路径重新读取该文件——如果确实缺失或格式错乱，请作为面向控制器的缺口上报。重新运行套件来补全你没读到的内容不叫验证；证据不可读不等于证据无效。
+
+    ## 第一部分：规格符合度
+
+    将 diff 与“需求内容”逐项对比：
+
+    - **缺失：** 遗漏、跳过或声称已实现但实际未实现的需求
+    - **多余：** 未被要求的功能、过度设计、不必要的“锦上添花”
+    - **误解：** 功能方向正确但实现方式错误，或解决了错误的问题
+
+    如果简报中列出了多个文件且每个文件各有改动（批量派发），请逐文件对照 diff 检查：每个列出的文件都必须有对应的 hunk。简报中列出但 diff 始终未触及的文件，即为“缺失”问题，无论批次中其余部分看起来多么干净。
+
+    如果某项需求仅凭本 diff 无法验证（它位于未变更的代码中或跨多个任务），请将其记为 ⚠️ 项，而不是扩大检索范围。
+
+    ## 第二部分：代码质量
+
+    **代码质量：**
+    - 关注点是否清晰分离？
+    - 错误处理是否得当？
+    - 是否做到 DRY 且无过早抽象？
+    - 边界情况是否已处理？
+
+    **测试：**
+    - 新增与变更的测试是否验证了真实行为，而非仅验证 mock？
+    - 任务的边界情况是否已覆盖？
+
+    **结构：**
+    - 每个文件是否职责单一、接口清晰？
+    - 单元是否已拆分到可独立理解与测试的程度？
+    - 实现是否遵循了计划中的文件结构？
+    - 本次变更是否产生了已经很大的新文件，或显著增大了现有文件？（不要对变更前已有的文件体积做评价——只关注本次变更带来的增量。）
+
+    报告应当指向证据：每个问题以及所有本可用一句“是”带过的检查，都需给出 file:line 引用。一份精炼且带行号引用的报告，能让控制器获得所需的一切信息。
+
+    你的最终消息即为报告本身：直接以规格符合度裁决开头。每一行都应是裁决、带 file:line 的问题、或你已执行的检查——不要写前言、过程叙述或收尾总结。
+
+    ## 评级校准
+
+    按实际严重程度对问题分级。并非所有问题都是严重。
+    重要表示该任务在修复前不可信：错误或脆弱的行为、遗漏的需求、或足以阻断合并的可维护性损伤——例如逻辑块的逐字重复、被吞掉的错误、断言空洞的测试。“覆盖可以更广”和打磨类建议属于轻微。
+    如果计划或简报明确要求了按本标准应判为缺陷的内容（例如断言空洞的测试、逻辑块的逐字重复），这依然算问题——请按重要级别上报，并标注为计划强制要求。计划的作者身份不为其自身打分；最终由人来定夺。
+    在列出问题前，先肯定做得好的地方——准确的表扬有助于实现者信任后续的反馈。
+
+    ## 输出格式
+
+    ### 规格符合度
+
+    - ✅ 符合规格 | ❌ 发现问题：[缺失/多余/误解的内容，并附 file:line 引用]
+    - ⚠️ 无法仅凭 diff 验证：[仅凭 diff 无法验证的需求，以及控制器应如何检查——需与上述 ✅/❌ 裁决一并报告，针对已可验证的部分给出结论]
+
+    ### 优点
+    [做得好的地方？请具体说明。]
+
+    ### 问题
+
+    #### 严重（必须修复）
+    #### 重要（建议修复）
+    #### 轻微（可选优化）
+
+    每个问题需包含：file:line、问题是什么、为什么重要、如何修复（若不明显）。
+
+    ### 评估
+
+    **任务质量：** [通过 | 需修复]
+
+    **理由：** [1-2 句技术性评估]
+```
+
+**占位符说明：**
+- `[MODEL]` — 必填：评审员模型，按 SKILL.md 的 Model Selection 选择
+- `[BRIEF_FILE]` — 必填：任务简报文件（执行 `scripts/task-brief PLAN N` 可打印路径；与实现者所依据的文件为同一份）
+- `[GLOBAL_CONSTRAINTS]` — 原样抄录计划中 Global Constraints 小节或规格中的约束性需求：精确的取值、格式以及组件之间的既定关系（不含流程类规则——那些已包含在本模板中）
+- `[REPORT_FILE]` — 必填：实现者写入详细报告的文件
+- `[BASE_SHA]` — 任务开始前的提交
+- `[HEAD_SHA]` — 当前提交
+- `[DIFF_FILE]` — 必填：控制器写入评审包的路径（执行 `scripts/review-package PLAN_FILE BASE HEAD` 会打印其写入的唯一路径；该包不会进入控制器的上下文）
+
+**评审员返回：** 规格符合度裁决（✅/❌/⚠️）、优点、问题（严重/重要/轻微）、任务质量裁决

package/skills/systematic-debugging/CREATION-LOG.md

@@ -0,0 +1,119 @@
+# 创建日志：系统化调试技能
+
+提取、结构化并加固关键技能的参考示例。
+
+## 来源材料
+
+从 `~/.claude/CLAUDE.md` 提取的调试框架：
+- 四阶段系统化流程（调查 → 模式分析 → 假设 → 实现）
+- 核心原则：始终定位根因，绝不只修复表象
+- 规则设计用于抵御时间压力与自我合理化
+
+## 提取决策
+
+**包含内容：**
+- 包含全部规则的完整四阶段框架
+- 反捷径约束（"NEVER fix symptom"、"STOP and re-analyze"）
+- 抗压力表述（"even if faster"、"even if I seem in a hurry"）
+- 每个阶段的具体执行步骤
+
+**不包含内容：**
+- 项目特定上下文
+- 同一规则的重复变体表述
+- 叙述性解释（已压缩为原则）
+
+## 结构遵循 skill-creation/SKILL.md
+
+1. **丰富的 when_to_use** - 包含症状与反模式
+2. **类型：technique** - 带明确步骤的具体流程
+3. **关键词** - "root cause"、"symptom"、"workaround"、"debugging"、"investigation"
+4. **流程图** - 针对“修复失败”场景的决策点 → 重新分析 vs 追加修复
+5. **分阶段拆解** - 可快速扫描的清单格式
+6. **反模式章节** - 明确不应做什么（对本技能至关重要）
+
+## 加固要素
+
+框架设计用于抵御压力下的合理化：
+
+### 措辞选择
+- "ALWAYS" / "NEVER"（而非 "should" / "try to"）
+- "even if faster" / "even if I seem in a hurry"
+- "STOP and re-analyze"（显式暂停）
+- "Don't skip past"（命中真实的跳步行为）
+
+### 结构防御
+- **阶段 1 强制执行** - 无法跳过直接进入实现
+- **单一假设规则** - 强制思考，避免霰弹式修复
+- **显式的失败处理** - 针对“首次修复未生效”设定必做动作
+- **反模式章节** - 直观展示捷径的具体形态
+
+### 冗余设计
+- 根因原则在概述 + when_to_use + 阶段 1 + 实现规则中重复强调
+- "NEVER fix symptom" 在不同上下文中出现 4 次
+- 每个阶段都包含显式的“不要跳过”指引
+
+## 测试方案
+
+按照 skills/meta/testing-skills-with-subagents 创建了 4 项验证测试：
+
+### 测试 1：学术场景（无压力）
+- 简单缺陷，无时间压力
+- **结果：** 完全合规，完成全部调查
+
+### 测试 2：时间压力 + 显而易见的快速修复
+- 用户“很赶”，表象修复看似简单
+- **结果：** 抵制捷径，执行完整流程，定位到真实根因
+
+### 测试 3：复杂系统 + 不确定性
+- 多层联动故障，能否找到根因尚不明确
+- **结果：** 系统化调查，逐层追踪，定位源头
+
+### 测试 4：首次修复失败
+- 假设未生效，存在追加修复的诱惑
+- **结果：** 暂停、重新分析、形成新假设（未采用霰弹式修复）
+
+**全部测试通过。** 未发现合理化行为。
+
+## 迭代过程
+
+### 初始版本
+- 完整的四阶段框架
+- 反模式章节
+- 针对“修复失败”决策的流程图
+
+### 增强 1：TDD 关联
+- 增加到 skills/testing/test-driven-development 的链接
+- 补充说明 TDD 的“最简实现” ≠ 调试的“根因定位”
+- 避免方法论混淆
+
+## 最终成果
+
+具备以下能力的加固技能：
+- ✅ 明确要求开展根因调查
+- ✅ 抵御时间压力下的合理化
+- ✅ 为每个阶段提供具体步骤
+- ✅ 显式展示反模式
+- ✅ 在多种压力场景下完成测试
+- ✅ 澄清与 TDD 的关系
+- ✅ 可直接投入使用
+
+## 关键洞察
+
+**最重要的加固点：** 反模式章节展示了在当下看似合理的捷径。当 Claude 产生“我就加这一个快速修复”的念头时，看到该模式被明确列为错误，会产生认知阻力。
+
+## 使用示例
+
+遇到缺陷时：
+1. 加载技能：skills/debugging/systematic-debugging
+2. 阅读概述（10 秒）- 重申原则
+3. 按阶段 1 清单执行 - 强制完成调查
+4. 若产生跳步冲动 - 查看反模式，立即停止
+5. 完成全部阶段 - 定位根因
+
+**时间投入：** 5-10 分钟
+**节省时间：** 数小时的表象修补
+
+---
+
+*创建于：2025-10-03*
+*用途：技能提取与加固的参考示例*