@wenaixi/dsh-superpower 7.4.1 → 7.5.2

package/skills/requesting-code-review/SKILL.md

@@ -1,95 +1,97 @@
 ---
 name: requesting-code-review
-description: "Superpower Skill：在任务完成、重大功能实现或准备合并到主分支时发起，用于校验实现是否符合需求与质量标准，建议定期执行。"
+description: "Superpower Skill: Use when completing tasks, implementing major features, or before merging to verify work meets requirements"
+description_zh: "Superpower Skill：在任务完成、重大功能实现或准备合并到主分支时发起，用于校验实现是否符合需求与质量标准，建议定期执行。"
 ---
 
-# 请求代码评审
 
-派发一个代码评审 subagent，在问题级联扩散前发现它们。reviewer 获得为评估而精确构造的上下文——绝不使用你的会话历史。
+# Requesting Code Review
 
-**核心原则：** 尽早评审，频繁评审。
+Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
 
-## 何时请求评审
+**Core principle:** Review early, review often.
 
-**必做：**
-- subagent 驱动开发中，完成每个任务后
-- 完成重大功能后
-- 合并到主分支前
+## When to Request Review
 
-**可选但很有价值：**
-- 遇到卡点时（换个视角）
-- 重构前（建立基线检查）
-- 修复复杂缺陷后
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
 
-## 如何发起请求
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
 
-**1. 获取 git SHA：**
+## How to Request
+
+**1. Get git SHAs:**
 ```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # 或：git merge-base origin/main HEAD
+BASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base origin/main HEAD
 HEAD_SHA=$(git rev-parse HEAD)
 ```
 
-**2. 派发代码评审 subagent：**
+**2. Dispatch code reviewer subagent:**
 
-派发一个 `general-purpose` subagent，并按 [code-reviewer.md](code-reviewer.md) 中的模板填入信息
+Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
 
-**占位符说明：**
-- `{DESCRIPTION}` - 本次构建内容的简要总结
-- `{PLAN_OR_REQUIREMENTS}` - 预期应实现的功能/需求说明
-- `{BASE_SHA}` - 起始提交
-- `{HEAD_SHA}` - 结束提交
+**Placeholders:**
+- `{DESCRIPTION}` - Brief summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
 
-**3. 处理反馈：**
-- 立即修复 Critical 级别问题
-- 在继续下一步前修复 Important 级别问题
-- 记录 Minor 级别问题，择机处理
-- 若评审意见有误，带上理由进行反驳
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
 
-## 示例
+## Example
 
 ```
-[刚刚完成任务 2：添加校验函数]
+[Just completed Task 2: Add verification function]
 
-你：先请求一次代码评审再继续。
+You: Let me request code review before proceeding.
 
 BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
 HEAD_SHA=$(git rev-parse HEAD)
 
-[派发代码评审 subagent]
+[Dispatch code reviewer subagent]
   DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
   PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
   BASE_SHA: a7981ec
   HEAD_SHA: 3df7661
 
-[subagent 返回]：
+[Subagent returns]:
   Strengths: Clean architecture, real tests
   Issues:
     Important: Missing progress indicators
     Minor: Magic number (100) for reporting interval
   Assessment: Ready to proceed
 
-你：[修复进度提示]
-[继续任务 3]
+You: [Fix progress indicators]
+[Continue to Task 3]
 ```
 
-## 常见借口与现实
+## Common Rationalizations
 
-| 借口 | 现实 |
+| Excuse | Reality |
 |--------|---------|
-| “我自己看一下 diff 就行，没必要再派评审” | 你是协调者——在行内直接看 diff 会消耗你本该用于推进工作的上下文窗口。派发评审 subagent：diff 与评估都在它的上下文中完成，回传给你的只有结论。 |
-| “reviewer 需要我的完整会话历史才能看懂改动” | 只给它为评估而精确构造的上下文，绝不给完整会话历史。这样 reviewer 关注的是工作产物本身，而非你的思考过程。 |
+| "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
+| "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. |
 
-## 红线
+## Red Flags
 
-**切勿：**
-- 因为“很简单”就跳过评审
-- 忽略 Critical 级别问题
-- 带着未修复的 Important 级别问题继续推进
-- 与正确的技术反馈争辩
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
 
-**若评审有误：**
-- 用技术理由反驳
-- 用代码/测试证明其可行
-- 请求进一步澄清
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
 
-模板见：[code-reviewer.md](code-reviewer.md)
+See template at: [code-reviewer.md](code-reviewer.md)

package/skills/requesting-code-review/code-reviewer.md

@@ -1,177 +1,198 @@
-# code reviewer prompt 模板
+# Code Reviewer Prompt Template
 
-在派发代码评审 subagent 时使用此模板。
+Use this template when dispatching a code reviewer subagent.
 
-**用途：** 在已完成的工作引发连锁影响前，对照需求与代码质量标准进行评审。
+**Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
 
 ```
 Subagent (general-purpose):
   description: "Review code changes"
   prompt: |
-    你是一名资深代码评审专家，精通软件架构、设计模式与最佳实践。你的职责是依据计划或需求评审已完成的工作，在问题扩散前发现隐患。
+    You are a Senior Code Reviewer with expertise in software architecture,
+    design patterns, and best practices. Your job is to review completed work
+    against its plan or requirements and identify issues before they cascade.
 
-    ## 已实现内容
+    ## What Was Implemented
 
     [DESCRIPTION]
 
-    ## 需求 / 计划
+    ## Requirements / Plan
 
     [PLAN_OR_REQUIREMENTS]
 
-    ## 待评审的 Git 区间
+    ## Git Range to Review
 
-    **基线：** [BASE_SHA]
-    **目标：** [HEAD_SHA]
+    **Base:** [BASE_SHA]
+    **Head:** [HEAD_SHA]
 
     ```bash
     git diff --stat [BASE_SHA]..[HEAD_SHA]
     git diff [BASE_SHA]..[HEAD_SHA]
     ```
 
-    ## 规格是一份愿景文档
+    ## The spec is a vision document
 
-    规格说明软件必须做什么。它不会逐一列举软件将遇到的所有输入、环境或条件。对于规格未提及的行为，按使用该软件的合理用户会有的预期来判断：合理用户的预期就是需求，规格的沉默不是许可。分级这类发现时依据的是该行为对那位用户的影响，而不是规格是否提到了触发条件。
+    The spec says what the software must do. It does not enumerate every
+    input, environment, or condition the software will meet. For behavior
+    the spec is silent on, judge by what a reasonable person using this
+    software would expect: a reasonable person's expectation is a
+    requirement, and a spec's silence is not permission. Grade such
+    findings by their effect on that person, not by whether the spec
+    mentions the trigger.
 
-    ## 拒绝裁决
+    ## Declined to judge
 
-    在给出结论前，逐条列出你考虑过但判定为超出计划或规格范围的行为，每行一条并附理由。运行会话将对每一行逐条裁决；你搁置的任何内容都不会被静默丢弃。空列表意味着你没有搁置任何内容。
+    Before your verdict, list every behavior you considered and set aside
+    as outside the plan or spec, one line each, with the reason. The
+    executor rules on each line; nothing you set aside is dropped
+    silently. An empty list means you set nothing aside.
 
-    ## 只读评审
+    ## Read-Only Review
 
-    本次评审在当前检出上为只读操作。不得以任何方式修改 working tree、暂存区、HEAD 或分支状态。请使用 `git show`、`git diff`、`git log` 等工具查看历史。如需基于其他版本的可用工作副本，请将其检出到独立的临时目录（例如 `git worktree add /tmp/review-[SHA] [SHA]`），切勿在当前检出上移动 HEAD。
+    Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like `git show`, `git diff`, and `git log` to inspect history. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout.
 
-    ## 禁止派发 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.
 
-    ## 检查项
+    ## What to Check
 
-    **计划一致性：**
-    - 实现是否符合计划 / 需求？
-    - 偏离是合理的改进，还是有问题的偏离？
-    - 是否已实现全部计划功能？
+    **Plan alignment:**
+    - Does the implementation match the plan / requirements?
+    - Are deviations justified improvements, or problematic departures?
+    - Is all planned functionality present?
 
-    **代码质量：**
-    - 职责划分是否清晰？
-    - 错误处理是否得当？
-    - 类型安全是否到位（如适用）？
-    - 是否遵循 DRY 原则且无过早抽象？
-    - 边界情况是否已处理？
+    **Code quality:**
+    - Clean separation of concerns?
+    - Proper error handling?
+    - Type safety where applicable?
+    - DRY without premature abstraction?
+    - Edge cases handled?
 
-    **架构：**
-    - 设计决策是否合理？
-    - 可扩展性与性能是否合理？
-    - 是否存在安全隐患？
-    - 与周边代码集成是否干净？
+    **Architecture:**
+    - Sound design decisions?
+    - Reasonable scalability and performance?
+    - Security concerns?
+    - Integrates cleanly with surrounding code?
 
-    **测试：**
-    - 测试是否验证真实行为而非仅 mock？
-    - 边界情况是否已覆盖？
-    - 关键路径是否有集成测试？
-    - 所有测试是否通过？
+    **Testing:**
+    - Tests verify real behavior, not mocks?
+    - Edge cases covered?
+    - Integration tests where they matter?
+    - All tests passing?
 
-    **生产就绪度：**
-    - 如有表结构变更，是否有迁移策略？
-    - 是否考虑向后兼容？
-    - 文档是否完整？
-    - 是否存在明显缺陷？
+    **Production readiness:**
+    - Migration strategy if schema changed?
+    - Backward compatibility considered?
+    - Documentation complete?
+    - No obvious bugs?
 
-    ## 评审校准
+    ## Calibration
 
-    按实际严重程度对问题分级。并非所有问题都是严重（Critical）级别。列出问题前先肯定做得好的部分——准确的肯定有助于实现者信任后续反馈。
+    Categorize issues by actual severity. Not everything is Critical.
+    Acknowledge what was done well before listing issues — accurate praise
+    helps the implementer trust the rest of the feedback.
 
-    如发现与计划的显著偏离，请明确指出，以便实现者确认偏离是否有意。如发现问题出在计划本身而非实现，也请直言。
+    If you find significant deviations from the plan, flag them specifically
+    so the implementer can confirm whether the deviation was intentional.
+    If you find issues with the plan itself rather than the implementation,
+    say so.
 
-    ## 输出格式
+    ## Output Format
 
-    ### 优点
-    [做得好的地方？请具体说明。]
+    ### Strengths
+    [What's well done? Be specific.]
 
-    ### 问题
+    ### Issues
 
-    #### 严重（必须修复）
-    [缺陷、安全问题、数据丢失风险、功能不可用]
+    #### Critical (Must Fix)
+    [Bugs, security issues, data loss risks, broken functionality]
 
-    #### 重要（建议修复）
-    [架构问题、功能缺失、错误处理不当、测试缺口]
+    #### Important (Should Fix)
+    [Architecture problems, missing features, poor error handling, test gaps]
 
-    #### 轻微（可选优化）
-    [代码风格、优化机会、文档润色]
+    #### Minor (Nice to Have)
+    [Code style, optimization opportunities, documentation polish]
 
-    每个问题需包含：
-    - 文件:行号 引用
-    - 问题描述
-    - 为什么重要
-    - 如何修复（如不明显）
+    For each issue:
+    - File:line reference
+    - What's wrong
+    - Why it matters
+    - How to fix (if not obvious)
 
-    ### 改进建议
-    [针对代码质量、架构或流程的改进建议]
+    ### Recommendations
+    [Improvements for code quality, architecture, or process]
 
-    ### 总体评估
+    ### Assessment
 
-    **是否可合并？** [是 | 否 | 修复后可合并]
+    **Ready to merge?** [Yes | No | With fixes]
 
-    **理由：** [1-2 句技术评估]
+    **Reasoning:** [1-2 sentence technical assessment]
 
-    ## 关键规则
+    ## Critical Rules
 
-    **应做：**
-    - 按实际严重程度分级
-    - 具体到文件:行号，避免空泛
-    - 说明每个问题为什么重要
-    - 肯定优点
-    - 给出明确结论
+    **DO:**
+    - Categorize by actual severity
+    - Be specific (file:line, not vague)
+    - Explain WHY each issue matters
+    - Acknowledge strengths
+    - Give a clear verdict
 
-    **不应做：**
-    - 未实际检查就说“看起来不错”
-    - 将细枝末节标为严重
-    - 对未阅读的代码给出反馈
-    - 含糊其辞（如“改进错误处理”）
-    - 回避明确结论
+    **DON'T:**
+    - Say "looks good" without checking
+    - Mark nitpicks as Critical
+    - Give feedback on code you didn't actually read
+    - Be vague ("improve error handling")
+    - Avoid giving a clear verdict
 ```
 
-**占位符：**
-- `[DESCRIPTION]` — 已构建内容的简要总结
-- `[PLAN_OR_REQUIREMENTS]` — 应实现的内容（计划文件路径、任务描述或需求）
-- `[BASE_SHA]` — 起始提交
-- `[HEAD_SHA]` — 结束提交
+**Placeholders:**
+- `[DESCRIPTION]` — brief summary of what was built
+- `[PLAN_OR_REQUIREMENTS]` — what it should do (plan file path, task text, or requirements)
+- `[BASE_SHA]` — starting commit
+- `[HEAD_SHA]` — ending commit
 
-**reviewer 返回：** 优点、问题（严重 / 重要 / 轻微）、改进建议、总体评估
+**Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
 
-## 输出示例
+## Example Output
 
 ```
-### 优点
-- 数据库结构清晰，迁移合理（db.ts:15-42）
-- 测试覆盖全面（18 个测试，覆盖全部边界情况）
-- 错误处理完善，带有降级方案（summarizer.ts:85-92）
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
 
-### 问题
+### Issues
 
-#### 重要
-1. **CLI 包装器缺少帮助信息**
-   - 文件：index-conversations:1-31
-   - 问题：缺少 --help 标志，用户无法发现 --concurrency 参数
-   - 修复：增加 --help 分支并提供使用示例
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
 
-2. **缺少日期校验**
-   - 文件：search.ts:25-27
-   - 问题：非法日期静默返回空结果
-   - 修复：校验 ISO 格式，校验失败时抛出带示例的错误提示
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
 
-#### 轻微
-1. **进度提示**
-   - 文件：indexer.ts:130
-   - 问题：长时间操作缺少“已完成 X / 共 Y”计数
-   - 影响：用户无法预估等待时间
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
 
-### 改进建议
-- 增加进度汇报以提升用户体验
-- 考虑通过配置文件排除项目（提升可移植性）
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
 
-### 总体评估
+### Assessment
 
-**是否可合并：修复后可合并**
+**Ready to merge: With fixes**
 
-**理由：** 核心实现扎实，架构与测试良好。重要问题（帮助信息、日期校验）易于修复且不影响核心功能。
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
 ```