@wenaixi/dsh-superpower 7.3.0 → 7.5.1

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

@@ -1,128 +1,207 @@
-# task reviewer prompt 模板
+# Task Reviewer Prompt Template
 
-在派发任务评审 subagent 时使用本模板。reviewer 只读取一次任务的 diff，并返回两项裁决：规格符合度与代码质量。
+Use this template when dispatching a task reviewer subagent. The reviewer
+reads the task's diff once and returns two verdicts: spec compliance and
+code quality.
 
-**目的：** 校验单个任务的实现是否完全贴合需求（不多不少），且构建良好（清晰、已测试、易维护）
+**Purpose:** Verify one task's implementation matches its requirements (nothing
+more, nothing less) and is well-built (clean, tested, maintainable)
 
 ```
 Subagent (general-purpose):
-  description: "评审任务 N（规格 + 质量）"
-  model: [MODEL — 必填：按 SKILL.md 的模型选择规则选择；若省略则静默继承会话中最昂贵的模型]
+  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: |
-    你正在评审单个任务的实现：先判断是否符合需求，再判断是否构建良好。这是一个任务级别的门禁，而非合并评审——所有任务完成后的全分支广度评审会另行进行。
+    You are reviewing one task's implementation: first whether it matches its
+    requirements, then whether it is well-built. This is a task-scoped gate,
+    not a merge review — a broad whole-branch review happens separately after
+    all tasks are complete.
 
-    ## 需求内容
+    ## What Was Requested
 
-    阅读 task brief：[BRIEF_FILE]
+    Read the task brief: [BRIEF_FILE]
 
-    来自规格/设计且约束本任务的全局约束：
+    Global constraints from the spec/design that bind this task:
     [GLOBAL_CONSTRAINTS]
 
-    ## 实现者声称已完成的内容
+    ## What the Implementer Claims They Built
 
-    阅读实现者的报告：[REPORT_FILE]
+    Read the implementer's report: [REPORT_FILE]
 
-    ## 待评审的 diff
+    ## Diff Under Review
 
     **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 契约、或共享可变状态，检查调用点就是正确的做法。
-
-    本次评审在当前检出上为只读。不要以任何方式修改 working tree、暂存区、HEAD 或分支状态。
-
-    ## 禁止分发 subagent
-
-    由你独立完成全部评审。不要衍生 subagent 来分担 diff 的部分评审，也不要为二次意见再派一个 reviewer。本流程已提供了该工作所需的所有评审席位；你衍生的 reviewer 会以全量成本重复其中一个席位，且其裁决不计入结果。如果 diff 过大、单次难以看完，请自行分多遍评审，并在报告中说明。
-
-    ## 不要信任报告
-
-    将实现者的报告视为未经核实的陈述。它可能不完整、不准确或过于乐观。请以 diff 为准核实其声明。报告中的设计理由同样是陈述：“按 YAGNI 保留”、“有意保持简单”或任何其他解释，都是实现者在给自己的工作打分。请按代码本身的优劣来评判——陈述的理由永远不会降低 finding 的严重级别。
-
-    ## 测试
-
-    实现者已运行测试，并针对当前代码按 TDD 要求报告了结果与证据。不要为核实其报告而重新运行整个测试套件。仅在阅读代码后产生具体疑点、且现有运行结果无法解答时，才运行测试——此时也只运行聚焦的单项测试，绝不要运行包级别全量套件、竞态检测或重复/高频循环。如果认为有必要做重量级验证，请在报告中建议，而不是直接执行。如果当前环境无法执行命令，请写明你会运行哪条测试。
-
-    实现者报告的测试输出中的警告或其他噪音即为 finding——测试输出应当是干净的。
-
-    你看不到的证据不代表不存在。如果报告或其中的测试证据看起来被截断，或你找不到其声称的结果，请按其标注的路径重新读取该文件——如果确实缺失或格式错乱，请作为面向控制器的缺口上报。重新运行套件来补全你没读到的内容不叫验证；证据不可读不等于证据无效。
-
-    ## 第一部分：规格符合度
-
-    将 diff 与“需求内容”逐项对比：
-
-    - **缺失：** 遗漏、跳过或声称已实现但实际未实现的需求
-    - **多余：** 未被要求的功能、过度设计、不必要的“锦上添花”
-    - **误解：** 功能方向正确但实现方式错误，或解决了错误的问题
-
-    如果 brief 中列出了多个文件且每个文件各有改动（批量派发），请逐文件对照 diff 检查：每个列出的文件都必须有对应的 hunk。brief 中列出但 diff 始终未触及的文件，即为“缺失”finding，无论批次中其余部分看起来多么干净。
-
-    如果某项需求仅凭本 diff 无法验证（它位于未变更的代码中或跨多个任务），请将其记为 [WARN] 项，而不是扩大检索范围。
-
-    ## 第二部分：代码质量
-
-    **代码质量：**
-    - 关注点是否清晰分离？
-    - 错误处理是否得当？
-    - 是否做到 DRY 且无过早抽象？
-    - 边界情况是否已处理？
-
-    **测试：**
-    - 新增与变更的测试是否验证了真实行为，而非仅验证 mock？
-    - 任务的边界情况是否已覆盖？
-
-    **结构：**
-    - 每个文件是否职责单一、接口清晰？
-    - 单元是否已拆分到可独立理解与测试的程度？
-    - 实现是否遵循了计划中的文件结构？
-    - 本次变更是否产生了已经很大的新文件，或显著增大了现有文件？（不要对变更前已有的文件体积做评价——只关注本次变更带来的增量。）
-
-    报告应当指向证据：每条 finding 以及所有本可用一句“是”带过的检查，都需给出 file:line 引用。一份精炼且带行号引用的报告，能让控制器获得所需的一切信息。
-
-    你的最终消息即为报告本身：直接以规格符合度裁决开头。每一行都应是裁决、带 file:line 的 finding、或你已执行的检查——不要写前言、过程叙述或收尾总结。
-
-    ## 评级校准
-
-    按实际严重程度对 finding 分级。并非所有问题都是 Critical。
-    Important 表示该任务在修复前不可信：错误或脆弱的行为、遗漏的需求、或足以阻断合并的可维护性损伤——例如逻辑块的逐字重复、被吞掉的错误、断言空洞的测试。“覆盖可以更广”和打磨类建议属于 Minor。
-    如果计划或 brief 明确要求了按本标准应判为缺陷的内容（例如断言空洞的测试、逻辑块的逐字重复），这依然算 finding——请按 Important 级别上报，并标注为 plan-mandated。计划的作者身份不为其自身打分；最终由人来定夺。
-    在列出问题前，先肯定做得好的地方——准确的表扬有助于实现者信任后续的反馈。
-
-    ## 输出格式
-
-    ### 规格符合度
-
-    - [OK] 符合规格 | [FAIL] 发现问题：[缺失/多余/误解的内容，并附 file:line 引用]
-    - [WARN] 无法仅凭 diff 验证：[仅凭 diff 无法验证的需求，以及控制器应如何检查——需与上述 [OK]/[FAIL] 裁决一并报告，针对已可验证的部分给出结论]
-
-    ### 优点
-    [做得好的地方？请具体说明。]
-
-    ### 问题
-
-    #### Critical（必须修复）
-    #### Important（建议修复）
-    #### Minor（可选优化）
-
-    每个问题需包含：file:line、问题是什么、为什么重要、如何修复（若不明显）。
-
-    ### 评估
-
-    **任务质量：** [Approved | Needs fixes]
-
-    **理由：** [1-2 句技术性评估]
+    **Diff file:** [DIFF_FILE]
+
+    Read the diff file once — it contains the commit list, a stat summary,
+    and the full diff with surrounding context, and it is your view of the
+    change. The diff's context lines ARE the changed files: do not Read a
+    changed file separately unless a hunk you must judge is cut off
+    mid-function — and say so in your report. Do not re-run git commands.
+    If the diff file is missing, fetch the diff yourself:
+    `git diff --stat [BASE_SHA]..[HEAD_SHA]` and `git diff [BASE_SHA]..[HEAD_SHA]`.
+    Do not crawl the broader codebase. Inspect code outside the diff only
+    to evaluate a concrete risk you can name — one focused check per named
+    risk, and name both the risk and what you checked in your report.
+    Cross-cutting changes are legitimate named risks: if the diff changes
+    lock ordering, a function or API contract, or shared mutable state,
+    checking the call sites is the right method.
+
+    Your review is read-only on this checkout. Do not mutate the working
+    tree, the index, HEAD, or branch state in any way.
+
+    ## You Do Not Dispatch Subagents
+
+    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.
+
+    ## Do Not Trust the Report
+
+    Treat the implementer's report as unverified claims about the code. It
+    may be incomplete, inaccurate, or optimistic. Verify the claims against
+    the diff. Design rationales in the report are claims too: "left it per
+    YAGNI," "kept it simple deliberately," or any other justification is the
+    implementer grading their own work. Judge the code on its merits — a
+    stated rationale never downgrades a finding's severity.
+
+    ## Tests
+
+    The implementer already ran the tests and reported results with TDD
+    evidence for exactly this code. 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, race detector run, or repeated/high-count loop. If
+    heavy validation seems warranted, recommend it in your report instead of
+    running it. If you cannot run commands in this environment, name the
+    test you would run.
+
+    Warnings or other noise in the implementer's reported test output are
+    findings — test output should be pristine.
+
+    Evidence you cannot see is not evidence that doesn't exist. If the
+    report or its test evidence looks truncated, or you cannot locate the
+    results it claims, re-read the file at its stated path — and if it is
+    genuinely missing or garbled, report that as a gap for the controller.
+    Re-running the suite to regenerate what you failed to read is not
+    verification; illegibility of the evidence is not invalidation of it.
+
+    ## Part 1: Spec Compliance
+
+    Compare the diff against What Was Requested:
+
+    - **Missing:** requirements they skipped, missed, or claimed without
+      implementing
+    - **Extra:** features that weren't requested, over-engineering, unneeded
+      "nice to haves"
+    - **Misunderstood:** right feature built the wrong way, wrong problem
+      solved
+
+    If the brief lists several files each with its own change (a batched
+    dispatch), check the diff against that list file by file: every listed
+    file must have its corresponding hunk. A listed file the diff never
+    touches is a Missing finding, no matter how clean the rest of the
+    batch looks.
+
+    If a requirement cannot be verified from this diff alone (it lives in
+    unchanged code or spans tasks), report it as a [WARN] item instead of
+    broadening your search.
+
+    ## Part 2: Code Quality
+
+    **Code quality:**
+    - Clean separation of concerns?
+    - Proper error handling?
+    - DRY without premature abstraction?
+    - Edge cases handled?
+
+    **Tests:**
+    - Do the new and changed tests verify real behavior, not mocks?
+    - Are the task's edge cases covered?
+
+    **Structure:**
+    - Does each file have one clear responsibility with a well-defined interface?
+    - Are units decomposed so they can be understood and tested independently?
+    - Is the implementation following the file structure from the plan?
+    - Did this change create new files that are already large, or
+      significantly grow existing files? (Don't flag pre-existing file
+      sizes — focus on what this change contributed.)
+
+    Your report should point at evidence: file:line references for every
+    finding and for any check you would otherwise answer with a bare
+    "yes." A tight report that cites lines gives the controller everything
+    it needs.
+
+    Your final message is the report itself: begin directly with the
+    spec-compliance verdict. Every line is a verdict, a finding with
+    file:line, or a check you ran — no preamble, no process narration,
+    no closing summary.
+
+    ## Calibration
+
+    Categorize issues by actual severity. Not everything is Critical.
+    Important means this task cannot be trusted until it is fixed: incorrect
+    or fragile behavior, a missed requirement, or maintainability damage you
+    would block a merge over — verbatim duplication of a logic block,
+    swallowed errors, tests that assert nothing. "Coverage could be broader"
+    and polish suggestions are Minor.
+    If the plan or brief explicitly mandates something this rubric calls a
+    defect (a test that asserts nothing, verbatim duplication of a logic
+    block), that IS a finding — report it as Important, labeled
+    plan-mandated. The plan's authorship does not grade its own work; the
+    human decides.
+    Acknowledge what was done well before listing issues — accurate praise
+    helps the implementer trust the rest of the feedback.
+
+    ## Output Format
+
+    ### Spec Compliance
+
+    - [OK] Spec compliant | [FAIL] Issues found: [what's missing/extra/misunderstood,
+      with file:line references]
+    - [WARN] Cannot verify from diff: [requirements you could not verify from the
+      diff alone, and what the controller should check — report alongside the
+      [OK]/[FAIL] verdict for everything you could verify]
+
+    ### Strengths
+    [What's well done? Be specific.]
+
+    ### Issues
+
+    #### Critical (Must Fix)
+    #### Important (Should Fix)
+    #### Minor (Nice to Have)
+
+    For each issue: file:line, what's wrong, why it matters, how to fix
+    (if not obvious).
+
+    ### Assessment
+
+    **Task quality:** [Approved | Needs fixes]
+
+    **Reasoning:** [1-2 sentence technical assessment]
 ```
 
-**占位符说明：**
-- `[MODEL]` — 必填：reviewer 模型，按 SKILL.md 的模型选择规则选择
-- `[BRIEF_FILE]` — 必填：task brief 文件（执行 `bash scripts/task-brief PLAN N` 可打印路径；与实现者所依据的文件为同一份）
-- `[GLOBAL_CONSTRAINTS]` — 原样抄录计划中 Global Constraints 小节或规格中的约束性需求：精确的取值、格式以及组件之间的既定关系（不含流程类规则——那些已包含在本模板中）
-- `[REPORT_FILE]` — 必填：实现者写入详细报告的文件
-- `[BASE_SHA]` — 任务开始前的提交
-- `[HEAD_SHA]` — 当前提交
-- `[DIFF_FILE]` — 必填：控制器写入review package的路径（执行 `bash scripts/review-package PLAN_FILE BASE HEAD` 会打印其写入的唯一路径；该包不会进入控制器的上下文）
-
-**reviewer 返回：** 规格符合度裁决（[OK]/[FAIL]/[WARN]）、优点、问题（Critical/Important/Minor）、任务质量裁决
+**Placeholders:**
+- `[MODEL]` — REQUIRED: reviewer model per SKILL.md Model Selection
+- `[BRIEF_FILE]` — REQUIRED: the task brief file (`bash scripts/task-brief PLAN N`
+  prints the path; same file the implementer worked from)
+- `[GLOBAL_CONSTRAINTS]` — the binding requirements copied verbatim from
+  the plan's Global Constraints section or the spec: exact values, formats,
+  and stated relationships between components (not process rules — those
+  are already in this template)
+- `[REPORT_FILE]` — REQUIRED: the file the implementer wrote its detailed
+  report to
+- `[BASE_SHA]` — commit before this task
+- `[HEAD_SHA]` — current commit
+- `[DIFF_FILE]` — REQUIRED: the path the controller wrote the review
+  package to (`bash scripts/review-package PLAN_FILE BASE HEAD` prints the unique
+  path it wrote; the package never enters the controller's context)
+
+**Reviewer returns:** Spec Compliance verdict ([OK]/[FAIL]/[WARN]), Strengths, Issues
+(Critical/Important/Minor), Task quality verdict

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

@@ -1,119 +1,119 @@
-# 创建日志：系统化调试技能
+# Creation Log: Systematic Debugging Skill
 
-提取、结构化并加固关键技能的参考示例。
+Reference example of extracting, structuring, and bulletproofing a critical skill.
 
-## 来源材料
+## Source Material
 
-从早期版本的 `CLAUDE.md` 用户指令中提取的调试框架：
-- 四阶段系统化流程（调查 → 模式分析 → 假设 → 实现）
-- 核心原则：始终定位根因，绝不只修复表象
-- 规则设计用于抵御时间压力与自我合理化
+Extracted debugging framework from an early-version `CLAUDE.md` user instructions file:
+- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
+- Core mandate: ALWAYS find root cause, NEVER fix symptoms
+- Rules designed to resist time pressure and rationalization
 
-## 提取决策
+## Extraction Decisions
 
-**包含内容：**
-- 包含全部规则的完整四阶段框架
-- 反捷径约束（"NEVER fix symptom"、"STOP and re-analyze"）
-- 抗压力表述（"even if faster"、"even if I seem in a hurry"）
-- 每个阶段的具体执行步骤
+**What to include:**
+- Complete 4-phase framework with all rules
+- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
+- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
+- Concrete steps for each phase
 
-**不包含内容：**
-- 项目特定上下文
-- 同一规则的重复变体表述
-- 叙述性解释（已压缩为原则）
+**What to leave out:**
+- Project-specific context
+- Repetitive variations of same rule
+- Narrative explanations (condensed to principles)
 
-## 结构遵循 skill-creation/SKILL.md
+## Structure Following skill-creation/SKILL.md
 
-1. **丰富的 when_to_use** - 包含症状与反模式
-2. **类型：technique** - 带明确步骤的具体流程
-3. **关键词** - "root cause"、"symptom"、"workaround"、"debugging"、"investigation"
-4. **流程图** - 针对“修复失败”场景的决策点 → 重新分析 vs 追加修复
-5. **分阶段拆解** - 可快速扫描的清单格式
-6. **反模式章节** - 明确不应做什么（对本技能至关重要）
+1. **Rich when_to_use** - Included symptoms and anti-patterns
+2. **Type: technique** - Concrete process with steps
+3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
+4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
+5. **Phase-by-phase breakdown** - Scannable checklist format
+6. **Anti-patterns section** - What NOT to do (critical for this skill)
 
-## 加固要素
+## Bulletproofing Elements
 
-框架设计用于抵御压力下的合理化：
+Framework designed to resist rationalization under pressure:
 
-### 措辞选择
-- "ALWAYS" / "NEVER"（而非 "should" / "try to"）
+### Language Choices
+- "ALWAYS" / "NEVER" (not "should" / "try to")
 - "even if faster" / "even if I seem in a hurry"
-- "STOP and re-analyze"（显式暂停）
-- "Don't skip past"（命中真实的跳步行为）
+- "STOP and re-analyze" (explicit pause)
+- "Don't skip past" (catches the actual behavior)
 
-### 结构防御
-- **阶段 1 强制执行** - 无法跳过直接进入实现
-- **单一假设规则** - 强制思考，避免霰弹式修复
-- **显式的失败处理** - 针对“首次修复未生效”设定必做动作
-- **反模式章节** - 直观展示捷径的具体形态
+### Structural Defenses
+- **Phase 1 required** - Can't skip to implementation
+- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
+- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
+- **Anti-patterns section** - Shows exactly what shortcuts look like
 
-### 冗余设计
-- 根因原则在概述 + when_to_use + 阶段 1 + 实现规则中重复强调
-- "NEVER fix symptom" 在不同上下文中出现 4 次
-- 每个阶段都包含显式的“不要跳过”指引
+### Redundancy
+- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
+- "NEVER fix symptom" appears 4 times in different contexts
+- Each phase has explicit "don't skip" guidance
 
-## 测试方案
+## Testing Approach
 
-按照 skills/meta/testing-skills-with-subagents 创建了 4 项验证测试：
+Created 4 validation tests following skills/meta/testing-skills-with-subagents:
 
-### 测试 1：学术场景（无压力）
-- 简单缺陷，无时间压力
-- **结果：** 完全合规，完成全部调查
+### Test 1: Academic Context (No Pressure)
+- Simple bug, no time pressure
+- **Result:** Perfect compliance, complete investigation
 
-### 测试 2：时间压力 + 显而易见的快速修复
-- 用户“很赶”，表象修复看似简单
-- **结果：** 抵制捷径，执行完整流程，定位到真实根因
+### Test 2: Time Pressure + Obvious Quick Fix
+- User "in a hurry", symptom fix looks easy
+- **Result:** Resisted shortcut, followed full process, found real root cause
 
-### 测试 3：复杂系统 + 不确定性
-- 多层联动故障，能否找到根因尚不明确
-- **结果：** 系统化调查，逐层追踪，定位源头
+### Test 3: Complex System + Uncertainty
+- Multi-layer failure, unclear if can find root cause
+- **Result:** Systematic investigation, traced through all layers, found source
 
-### 测试 4：首次修复失败
-- 假设未生效，存在追加修复的诱惑
-- **结果：** 暂停、重新分析、形成新假设（未采用霰弹式修复）
+### Test 4: Failed First Fix
+- Hypothesis doesn't work, temptation to add more fixes
+- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
 
-**全部测试通过。** 未发现合理化行为。
+**All tests passed.** No rationalizations found.
 
-## 迭代过程
+## Iterations
 
-### 初始版本
-- 完整的四阶段框架
-- 反模式章节
-- 针对“修复失败”决策的流程图
+### Initial Version
+- Complete 4-phase framework
+- Anti-patterns section
+- Flowchart for "fix failed" decision
 
-### 增强 1：TDD 关联
-- 增加到 skills/testing/test-driven-development 的链接
-- 补充说明 TDD 的“最简实现” ≠ 调试的“根因定位”
-- 避免方法论混淆
+### Enhancement 1: TDD Reference
+- Added link to skills/testing/test-driven-development
+- Note explaining TDD's "simplest code" ≠ debugging's "root cause"
+- Prevents confusion between methodologies
 
-## 最终成果
+## Final Outcome
 
-具备以下能力的加固技能：
-- [OK] 明确要求开展根因调查
-- [OK] 抵御时间压力下的合理化
-- [OK] 为每个阶段提供具体步骤
-- [OK] 显式展示反模式
-- [OK] 在多种压力场景下完成测试
-- [OK] 澄清与 TDD 的关系
-- [OK] 可直接投入使用
+Bulletproof skill that:
+- [OK] Clearly mandates root cause investigation
+- [OK] Resists time pressure rationalization
+- [OK] Provides concrete steps for each phase
+- [OK] Shows anti-patterns explicitly
+- [OK] Tested under multiple pressure scenarios
+- [OK] Clarifies relationship to TDD
+- [OK] Ready for use
 
-## 关键洞察
+## Key Insight
 
-**最重要的加固点：** 反模式章节展示了在当下看似合理的捷径。当 agent 产生“我就加这一个快速修复”的念头时，看到该模式被明确列为错误，会产生认知阻力。
+**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
 
-## 使用示例
+## Usage Example
 
-遇到缺陷时：
-1. 加载技能：skills/debugging/systematic-debugging
-2. 阅读概述（10 秒）- 重申原则
-3. 按阶段 1 清单执行 - 强制完成调查
-4. 若产生跳步冲动 - 查看反模式，立即停止
-5. 完成全部阶段 - 定位根因
+When encountering a bug:
+1. Load skill: skills/debugging/systematic-debugging
+2. Read overview (10 sec) - reminded of mandate
+3. Follow Phase 1 checklist - forced investigation
+4. If tempted to skip - see anti-pattern, stop
+5. Complete all phases - root cause found
 
-**时间投入：** 5-10 分钟
-**节省时间：** 数小时的表象修补
+**Time investment:** 5-10 minutes
+**Time saved:** Hours of symptom-whack-a-mole
 
 ---
 
-*创建于：2025-10-03*
-*用途：技能提取与加固的参考示例*
+*Created: 2025-10-03*
+*Purpose: Reference example for skill extraction and bulletproofing*