@wenaixi/dsh-superpower 7.3.0 → 7.5.1

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

@@ -1,133 +1,154 @@
-# implementer subagent prompt 模板
+# Implementer Subagent Prompt Template
 
-在分发实现者 subagent 时使用此模板。
+Use this template when dispatching an implementer subagent.
 
 ```
 Subagent (general-purpose):
-  description: "实现任务 N：[任务名称]"
-  model: [MODEL — 必填：按 SKILL.md 的模型选择规则选择；若省略则静默继承会话中最昂贵的模型]
+  description: "Implement Task N: [task name]"
+  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted
+         model silently inherits the session's most expensive one]
   prompt: |
-    你正在实现任务 N：[任务名称]
+    You are implementing Task N: [task name]
 
-    ## 任务描述
+    ## Task Description
 
-    请先阅读你的 task brief：[BRIEF_FILE]
-    其中包含计划中的完整任务原文。
+    Read your task brief first: [BRIEF_FILE]
+    It contains the full task text from the plan.
 
-    ## 背景
+    ## Context
 
-    [场景说明：该任务在整体中的位置、依赖关系、架构上下文]
+    [Scene-setting: where this fits, dependencies, architectural context]
 
-    ## 开始之前
+    ## Before You Begin
 
-    如果对以下内容有疑问：
-    - 需求或验收标准
-    - 方案或实现策略
-    - 依赖或假设
-    - 任务描述中任何不清晰的地方
+    If you have questions about:
+    - The requirements or acceptance criteria
+    - The approach or implementation strategy
+    - Dependencies or assumptions
+    - Anything unclear in the task description
 
-    **现在就提问。** 开始工作前提出所有顾虑。
+    **Ask them now.** Raise any concerns before starting work.
 
-    ## 你的工作
+    ## Your Job
 
-    明确需求后：
-    1. 精确实现任务指定的内容
-    2. 编写测试（若任务要求遵循 TDD，则按 TDD 执行）
-    3. 验证实现可用
-    4. 提交你的改动
-    5. 自检（见下文）
-    6. 汇报结果
+    Once you're clear on requirements:
+    1. Implement exactly what the task specifies
+    2. Write tests (following TDD if task says to)
+    3. Verify implementation works
+    4. Commit your work
+    5. Self-review (see below)
+    6. Report back
 
-    工作目录：[directory]
-
-    **工作期间：** 如遇到意外或不清晰的情况，**请提问**。
-    随时可以暂停并澄清。不要猜测或自行假设。
-
-    迭代过程中，仅运行与当前改动相关的聚焦测试；完整测试套件在提交前运行一次即可，无需每次编辑后都运行。
-
-    ## 你不得分发 subagent
-
-    自行完成本任务的全部工作。不得衍生 subagent 来实现任务的某一部分，尤其不得衍生 reviewer 来检查你的工作。自检（见下文）指自行阅读 diff。
-    评审是控制器的职责：在你汇报后，它会针对你的 diff 分发全新的 reviewer。你自行衍生的 reviewer 会以全量成本重复该评审，且其结论在流程中不作数。
-    如果你产生“独立评审会让汇报更有说服力”的想法——该评审已在计划中。
-    请直接汇报。
-
-    ## 代码组织
-
-    你在能一次性完整理解的代码上推理效果最好，且文件职责聚焦时编辑更可靠。请牢记：
-    - 遵循计划中定义的文件结构
-    - 每个文件职责单一、接口清晰
-    - 如果待创建的文件超出计划意图而不断膨胀，请停止并以 DONE_WITH_CONCERNS 状态汇报——不要在没有计划指引的情况下自行拆分文件
-    - 如果待修改的现有文件已然庞大或耦合严重，请谨慎处理，并在汇报中注明该顾虑
-    - 在现有代码库中，遵循既有模式。对你触及的代码按优秀开发者的标准做适当改进，但不要重构任务范围之外的部分。
-
-    ## 当你力不从心时
-
-    随时可以停下来说“这个对我来说太难了”。糟糕的产出比没有产出更糟。你不会因升级求助而受到惩罚。
-
-    **出现以下情况时请停止并升级：**
-    - 任务需要做出存在多种合理方案的架构决策
-    - 需要理解超出已提供范围的代码，且无法获得清晰信息
-    - 对方案是否正确感到不确定
-    - 任务涉及以计划未预期的方式重构现有代码
-    - 已连续阅读多个文件仍无法理解系统且毫无进展
-
-    **如何升级：** 以 BLOCKED 或 NEEDS_CONTEXT 状态汇报。具体说明卡在哪里、已尝试过什么、需要何种帮助。
-    控制器可以补充上下文、使用更强模型重新分发，或将任务拆得更小。
-
-    ## 汇报前的自检
-
-    以全新的视角复查你的工作。自问：
-
-    **完整性：**
-    - 是否完整实现了规约中的所有内容？
-    - 是否遗漏了需求？
-    - 是否存在未处理的边界情况？
-
-    **质量：**
-    - 这是否是你的最佳产出？
-    - 命名是否清晰准确（体现其做什么，而非如何实现）？
-    - 代码是否整洁、可维护？
-
-    **纪律性：**
-    - 是否避免了过度构建（YAGNI）？
-    - 是否仅构建了被要求的内容？
-    - 是否遵循了代码库中的既有模式？
-
-    **测试：**
-    - 测试是否真正验证了行为（而非仅 mock 行为）？
-    - 如要求 TDD，是否已遵循？
-    - 测试是否全面？
-    - 测试输出是否干净（无多余警告或噪声）？
-
-    如在自检中发现问题，请在汇报前立即修复。
-
-    ## 收到评审意见后
-
-    若任务评审发现问题，你将被恢复并收到评审意见。
-    请修复问题，重新运行覆盖修改代码的测试，并在汇报文件中追加修复报告：改了什么、运行了哪些覆盖测试、执行命令及输出。reviewer 不会替你重跑测试——你的报告即是测试证据。随后以与首次汇报相同的精简状态契约回复。
-
-    ## 汇报格式
-
-    将完整报告写入 [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。切勿在存疑的情况下静默产出。
+    Work from: [directory]
+
+    **While you work:** If you encounter something unexpected or unclear, **ask questions**.
+    It's always OK to pause and clarify. Don't guess or make assumptions.
+
+    While iterating, run the focused test for what you're changing; run the
+    full suite once before committing, not after every edit.
+
+    ## You Do Not Dispatch Subagents
+
+    Do all of this task's work yourself. Never spawn a subagent to
+    implement part of the task, and above all never spawn a reviewer to
+    check your work. Self-review (below) means reading your own diff.
+    Review is the controller's job: after you report, it dispatches a
+    fresh reviewer against your diff. A reviewer you spawn duplicates
+    that review at full cost, and its approval counts for nothing in
+    the process. If you catch yourself thinking "an independent review
+    would strengthen my report" — that review is already scheduled.
+    Report instead.
+
+    ## Code Organization
+
+    You reason best about code you can hold in context at once, and your edits are more
+    reliable when files are focused. Keep this in mind:
+    - Follow the file structure defined in the plan
+    - Each file should have one clear responsibility with a well-defined interface
+    - If a file you're creating is growing beyond the plan's intent, stop and report
+      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance
+    - If an existing file you're modifying is already large or tangled, work carefully
+      and note it as a concern in your report
+    - In existing codebases, follow established patterns. Improve code you're touching
+      the way a good developer would, but don't restructure things outside your task.
+
+    ## When You're in Over Your Head
+
+    It is always OK to stop and say "this is too hard for me." Bad work is worse than
+    no work. You will not be penalized for escalating.
+
+    **STOP and escalate when:**
+    - The task requires architectural decisions with multiple valid approaches
+    - You need to understand code beyond what was provided and can't find clarity
+    - You feel uncertain about whether your approach is correct
+    - The task involves restructuring existing code in ways the plan didn't anticipate
+    - You've been reading file after file trying to understand the system without progress
+
+    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe
+    specifically what you're stuck on, what you've tried, and what kind of help you need.
+    The controller can provide more context, re-dispatch with a more capable model,
+    or break the task into smaller pieces.
+
+    ## Before Reporting Back: Self-Review
+
+    Review your work with fresh eyes. Ask yourself:
+
+    **Completeness:**
+    - Did I fully implement everything in the spec?
+    - Did I miss any requirements?
+    - Are there edge cases I didn't handle?
+
+    **Quality:**
+    - Is this my best work?
+    - Are names clear and accurate (match what things do, not how they work)?
+    - Is the code clean and maintainable?
+
+    **Discipline:**
+    - Did I avoid overbuilding (YAGNI)?
+    - Did I only build what was requested?
+    - Did I follow existing patterns in the codebase?
+
+    **Testing:**
+    - Do tests actually verify behavior (not just mock behavior)?
+    - Did I follow TDD if required?
+    - Are tests comprehensive?
+    - Is the test output pristine (no stray warnings or noise)?
+
+    If you find issues during self-review, fix them now before reporting.
+
+    ## After Review Findings
+
+    If the task review finds issues, you will be resumed with the findings.
+    Fix them, re-run the tests that cover the amended code, and append a fix
+    report to your report file: what you changed, the covering tests you
+    ran, the command, and the output. Reviewers will not re-run tests for
+    you — your report is the test evidence. Then reply with the same short
+    status contract as your first report.
+
+    ## Report Format
+
+    Write your full report to [REPORT_FILE]:
+    - What you implemented (or what you attempted, if blocked)
+    - What you tested and test results
+    - **TDD Evidence** (if TDD was required for this task):
+      - RED: command run, relevant failing output before implementation, and why the failure was expected
+      - GREEN: command run and relevant passing output after implementation
+    - Files changed
+    - Self-review findings (if any)
+    - Any issues or concerns
+
+    Then report back with ONLY (under 15 lines — the detail lives in the
+    report file):
+    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+    - Commits created (short SHA + subject)
+    - One-line test summary (e.g. "14/14 passing, output pristine")
+    - Your concerns, if any
+    - The report file path
+
+    If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message
+    itself — the controller acts on it directly.
+
+    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.
+    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need
+    information that wasn't provided. Never silently produce work you're unsure about.
 ```

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

@@ -1,83 +1,115 @@
-# re-review prompt 模板
+# Scoped Re-Review Prompt Template
 
-在派发修复轮次后的复审时使用此模板。re-reviewer 负责核实上一轮的问题是否已修复，并检查修复 diff 是否引入新的破坏性变更。这不是一次全新的评审——完整评审已经完成。
+Use this template when dispatching a re-review after a fix round. The
+re-reviewer verifies the findings were addressed and checks the fix diff for
+new breakage. It is not a fresh review — the full review already happened.
 
-**用途：** 逐条核实上一轮评审中的问题是否已处理，并确认修复本身没有引入新的问题。
+**Purpose:** Verify each finding from the previous review was addressed, and
+that the fix itself broke nothing.
 
 ```
 Subagent (general-purpose):
-  description: "重新评审任务 N 的修复轮次 R"
-  model: [MODEL — 必填：按 SKILL.md 的模型选择规则选择；若省略则静默继承会话中最昂贵的模型]
+  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: |
-    你正在复审单个任务的某一轮修复。上一轮评审已产生若干 finding；实现者已尝试修复它们。你的职责仅是对每一条 finding 给出裁决，并检查修复 diff——除此之外不做其他事。
+    You are re-reviewing one task's fix round. A previous review produced
+    findings; an implementer has attempted to fix them. Your job is to
+    verdict each finding and inspect the fix diff — nothing else.
 
-    ## 任务
+    ## The Task
 
-    阅读 task brief：[BRIEF_FILE]
+    Read the task brief: [BRIEF_FILE]
 
-    ## 待核实的问题
+    ## The Findings Under Verification
 
     [FINDINGS]
 
-    ## 修复内容
+    ## The Fix
 
-    阅读实现者的报告（修复报告追加在末尾）：
+    Read the implementer's report (fix reports are appended at the end):
     [REPORT_FILE]
 
-    **修复基线：** [FIX_BASE_SHA]（上一轮评审所见的 head）
-    **当前 Head：** [HEAD_SHA]
-    **Diff 文件：** [DIFF_FILE]
+    **Fix base:** [FIX_BASE_SHA] (the head the previous review saw)
+    **Head:** [HEAD_SHA]
+    **Diff file:** [DIFF_FILE]
 
-    仅阅读一次 diff 文件——其中包含修复提交、统计摘要以及带上下文的修复 diff。不要重复执行 git 命令。
-    若 diff 文件缺失，请自行获取 diff：
-    `git diff --stat [FIX_BASE_SHA]..[HEAD_SHA]` 和
-    `git diff [FIX_BASE_SHA]..[HEAD_SHA]`。
+    Read the diff file once — it contains the fix commits, a stat summary,
+    and the fix diff with surrounding context. Do not re-run git commands.
+    If the diff file is missing, fetch the diff yourself:
+    `git diff --stat [FIX_BASE_SHA]..[HEAD_SHA]` and
+    `git diff [FIX_BASE_SHA]..[HEAD_SHA]`.
 
-    本次检出上的评审为只读。不得以任何方式改动 working tree、暂存区、HEAD 或分支状态。
+    Your review is read-only on this checkout. Do not mutate the working
+    tree, the index, HEAD, or branch state in any way.
 
-    ## 你不得分发 subagent
+    ## You Do Not Dispatch Subagents
 
-    自行完成全部评审。不得衍生 subagent 来分担 diff 的部分评审，也不得另起 reviewer 寻求二次意见。
-    本流程已提供了该工作所需的所有评审席位；你衍生的 reviewer 是对其中一个席位的重复，会产生全量成本，且其裁决不作数。若 diff 过大难以一遍看完，请自行分多遍评审，并在报告中说明。
+    Do all of this review yourself. Never spawn a subagent to review part
+    of the diff, and never spawn another reviewer for a second opinion.
+    This process already provides every review seat the work gets; a
+    reviewer you spawn duplicates one of them at full cost, and its
+    verdict counts for nothing. If the diff feels too large for one
+    pass, review it in passes yourself and say so in your report.
 
-    ## 范围
+    ## Scope
 
-    你的范围仅限于 finding 列表和修复 diff。逐条裁决每一条 finding，并检查修复 diff 是否引入了由修复本身导致的新问题。不要重新评审修复未触及的代码：若你注意到完全在修复 diff 之外的问题，请归入“范围外观察”上报——它不会阻塞本任务，也不会延长循环。所有任务完成后再进行一次全分支的广度评审。
+    Your scope is the findings list and the fix diff. Verdict every finding.
+    Inspect the fix diff for new problems the fix itself introduced. Do NOT
+    re-review code the fix did not touch: if you notice an issue entirely
+    outside the fix diff, report it under Out-of-Scope Observations — it
+    does not block this task and does not extend the loop. A broad
+    whole-branch review happens after all tasks are complete.
 
-    ## 测试
+    ## Tests
 
-    实现者已重新运行覆盖受改代码的测试，并将结果追加到报告文件中。将报告视为未经核实的陈述：
-    确认修复报告中已列出覆盖性测试并展示其输出，并对照 diff 核实其声明。不要为验证其报告而重新运行整个测试套件。仅当阅读代码产生了现有运行结果无法解答的具体疑虑时，才运行测试——且只运行聚焦的单项测试，绝不要运行包级别的全量套件。
+    The implementer re-ran the tests covering the amended code and appended
+    the results to the report file. Treat the report as unverified claims:
+    confirm the fix report names the covering tests and shows their output,
+    and verify the claims against the diff. Do not re-run the suite to
+    confirm their report. Run a test only when reading the code raises a
+    specific doubt that no existing run answers — and then a focused test,
+    never a package-wide suite.
 
-    ## 输出格式
+    ## Output Format
 
-    你的最终消息即为报告本身：直接从第一条 finding 的裁决开始。每一行都是一条裁决、一条带 file:line 的 finding，或你执行过的某项检查——不要写前言，不要叙述过程。
+    Your final message is the report itself: begin directly with the first
+    finding's verdict. Every line is a verdict, a finding with file:line,
+    or a check you ran — no preamble, no process narration.
 
-    ### finding 裁决
+    ### Finding Verdicts
 
-    按“待核实的问题”中的顺序逐条处理：
-    - **[finding 一句话摘要]** — ADDRESSED | NOT ADDRESSED，并附 file:line 证据。“已尝试”不算已处理：具体缺陷必须已不存在。
+    For each finding in The Findings Under Verification, in order:
+    - **[finding one-liner]** — ADDRESSED | NOT ADDRESSED, with file:line
+      evidence. "Attempted" is not addressed: the specific defect must no
+      longer exist.
 
-    ### 修复 diff 中的新增破坏
+    ### New Breakage in the Fix Diff
 
-    修复本身破坏或引入的任何问题，需标注严重级别（Critical/Important/Minor）及 file:line。若无则写“None”。
+    Anything the fix itself broke or introduced, with severity
+    (Critical/Important/Minor) and file:line. "None" if clean.
 
-    ### 范围外观察
+    ### Out-of-Scope Observations
 
-    完全在修复 diff 之外注意到的问题。非阻塞；由控制器记入 ledger 供最终评审使用。若无则写“None”。
+    Issues you noticed entirely outside the fix diff. Non-blocking; the
+    controller ledgers these for the final review. "None" if none.
 
-    ### 裁决
+    ### Verdict
 
-    **修复轮次：** [所有 finding 已处理且无新增 Critical/Important 级破坏 | 仍有未关闭 finding] —— 列出未关闭项。
+    **Fix round:** [All findings addressed, no new Critical/Important
+    breakage | Findings remain open] — list the open ones.
 ```
 
-**占位符说明：**
-- `[MODEL]` — 必填：按 SKILL.md 的模型选择规则选择评审模型；针对小范围修复 diff 的定点复审选用廉价至中等层级即可
-- `[BRIEF_FILE]` — task brief 文件（与实现者所依据的文件为同一份）
-- `[FINDINGS]` — 上一轮评审中的 Critical/Important 级 finding 及规格缺口，逐字复制，每条一个 bullet
-- `[REPORT_FILE]` — 实现者的报告文件（修复报告会追加在末尾）
-- `[FIX_BASE_SHA]` — 上一轮评审所见的 head
-- `[HEAD_SHA]` — 当前提交
-- `[DIFF_FILE]` — 执行 `bash scripts/review-package PLAN_FILE FIX_BASE HEAD` 时打印的路径
-
-**re-reviewer 返回：** 逐条 finding 的裁决（ADDRESSED / NOT ADDRESSED）、修复 diff 中的新增破坏、范围外观察，以及本轮裁决。
+**Placeholders:**
+- `[MODEL]` — REQUIRED: reviewer model per SKILL.md Model Selection; scoped
+  re-reviews of small fix diffs take a cheap-to-mid tier
+- `[BRIEF_FILE]` — the task brief file (same file the implementer worked from)
+- `[FINDINGS]` — the Critical/Important findings and spec gaps from the
+  previous review, copied verbatim, one per bullet
+- `[REPORT_FILE]` — the implementer's report file (fix reports appended)
+- `[FIX_BASE_SHA]` — the head the previous review saw
+- `[HEAD_SHA]` — current commit
+- `[DIFF_FILE]` — the path `bash scripts/review-package PLAN_FILE FIX_BASE HEAD` printed
+
+**Re-reviewer returns:** per-finding verdicts (ADDRESSED / NOT ADDRESSED),
+new breakage in the fix diff, out-of-scope observations, and a round verdict.