@wenaixi/dsh-superpower 7.4.1 → 7.5.1

package/skills/finishing-a-development-branch/SKILL.md

@@ -1,82 +1,91 @@
 ---
 name: finishing-a-development-branch
-description: "Superpower Skill：实现完成且全部测试通过后，用于决定分支集成方式，支持本地合并、创建 PR 或保留分支等完整收尾流程。"
+description: "Superpower Skill: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work"
+description_zh: "Superpower Skill：实现完成且全部测试通过后，用于决定分支集成方式，支持本地合并、创建 PR 或保留分支等完整收尾流程。"
 ---
 
-# 完成开发分支
 
-## 概述
+# Finishing a Development Branch
 
-**核心原则：** 验证测试 → 检测环境 → 提供选项 → 执行选择 → 清理收尾。
+## Overview
 
-**开始时声明：** “我将使用 finishing-a-development-branch 技能来完成收尾工作。”
+**Core principle:** Verify tests → Detect environment → Present options → Execute choice → Clean up.
 
-## 步骤 1：验证测试
+**Announce at start:** "I'm using the finishing-a-development-branch skill to complete this work."
 
-运行项目的完整测试套件（`npm test` / `cargo test` / `pytest` / `go test ./...`）。
+## Step 1: Verify Tests
 
-**若测试失败**，报告失败信息并停止——只有测试全通过后才展示选项菜单：
+Run the project's full test suite (`npm test` / `cargo test` / `pytest` / `go test ./...`).
+
+**If tests fail**, report the failures and stop — the menu comes after a green suite:
 
 ```
-测试未通过（<N> 项失败），需修复后才能完成：
+Tests failing (<N> failures). Must fix before completing:
 
-[展示失败详情]
+[Show failures]
 ```
 
-**若测试通过：** 继续进入步骤 2。
+**If tests pass:** continue to Step 2.
 
-## 步骤 2：检测环境
+## Step 2: Detect Environment
 
 ```bash
 GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
 GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
-# 此时仍在工作区内，立即捕获此值——步骤 5 会切换目录，
-# 而后清理阶段（步骤 6）需要该值
+# Capture now, while still inside the workspace — Step 5 changes directory
+# before cleanup (Step 6) needs this value
 WORKTREE_PATH=$(git rev-parse --show-toplevel)
 ```
 
-下表决定展示哪种菜单以及如何执行清理：
+This determines which menu to show and how cleanup works:
 
-| 状态 | 菜单 | 清理方式 |
+| State | Menu | Cleanup |
 |-------|------|---------|
-| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 3 项选项 | 无需清理 worktree |
-| `GIT_DIR != GIT_COMMON`，具名分支 | 标准 3 项选项 | 按来源判定（见步骤 6） |
-| `GIT_DIR != GIT_COMMON`，游离 HEAD | 精简 2 项选项（无合并） | 由外部托管——保持原样 |
+| `GIT_DIR == GIT_COMMON` (normal repo) | Standard 3 options | No worktree to clean up |
+| `GIT_DIR != GIT_COMMON`, named branch | Standard 3 options | Provenance-based (see Step 6) |
+| `GIT_DIR != GIT_COMMON`, detached HEAD | Reduced 2 options (no merge) | Externally managed — leave in place |
 
-## 步骤 3：确定基线分支
+## Step 3: Determine Base Branch
 
-基线分支即本次工作 fork 时的来源分支——通常在计划、对话记录或分支的上游中已注明。若尚未明确，请询问：“该分支是从 <你的最佳推测> fork 出来的，这样对吗？” 合并前务必确认：合错基线分支的回滚成本很高。
+The base branch is whatever this work forked from — usually named in the
+plan, the conversation, or the branch's upstream. If it is not already
+known, ask: "This branch split from <your best guess> - is that correct?"
+Confirm before merging: merging into the wrong base is expensive to undo.
 
-## 步骤 4：提供选项
+## Step 4: Present Options
 
-**普通仓库与具名分支 worktree——请严格按以下 3 项呈现：**
+**Normal repo and named-branch worktree — present exactly these 3 options:**
 
 ```
-实现已完成。接下来怎么处理？
+Implementation complete. What would you like to do?
 
-1. 本地合并回 <base-branch>
-2. 推送并创建 Pull Request
-3. 保持分支现状（稍后自行处理）
+1. Merge back to <base-branch> locally
+2. Push and create a Pull Request
+3. Keep the branch as-is (I'll handle it later)
 
-请选择：
+Which option?
 ```
 
-**游离 HEAD——请严格按以下 2 项呈现：**
+**Detached HEAD — present exactly these 2 options:**
 
 ```
-实现已完成。当前处于游离 HEAD（外部托管的 worktree）。
+Implementation complete. You're on a detached HEAD (externally managed workspace).
 
-1. 以新分支推送并创建 Pull Request
-2. 保持现状（稍后自行处理）
+1. Push as new branch and create a Pull Request
+2. Keep as-is (I'll handle it later)
 
-请选择：
+Which option?
 ```
 
-请严格按原文呈现菜单——保持简洁，所有选项均来自上表。仅当 human partner 明确要求丢弃工作时才处理丢弃流程（见下文“若 human partner 要求丢弃工作”）。等待对方答复；集成决策权归 human partner 所有。
+Present the menu exactly as written — concise, with every option coming
+from the list above. Discarding the work happens only in response to your
+human partner explicitly asking for it (see "If your human partner asks to
+discard the work" below). Wait for their answer; the integration decision
+is theirs.
 
-## 步骤 5：执行选择
+## Step 5: Execute Choice
 
-### 选项 1：本地合并
+### Option 1: Merge Locally
 
 ```bash
 # Get main repo root for CWD safety
@@ -92,15 +101,18 @@ git merge <feature-branch>
 <test command>
 ```
 
-若合并后的测试失败：立即停止，保留 worktree 与分支并展开排查——此时尚未推送，合并仅在本地，可恢复。
+If tests fail on the merged result: stop, leave the worktree and branch in
+place, and investigate — nothing has been pushed, so the merge is local
+and recoverable.
 
-合并结果测试通过后：清理 worktree（步骤 6），然后删除分支：
+Once the merged result is green: clean up the worktree (Step 6), then
+delete the branch:
 
 ```bash
 git branch -d <feature-branch>
 ```
 
-### 选项 2：推送并创建 PR
+### Option 2: Push and Create PR
 
 ```bash
 git push -u origin <feature-branch>
@@ -108,95 +120,108 @@ git push -u origin <feature-branch>
 # git push origin HEAD:refs/heads/<new-branch>
 ```
 
-然后针对 <base-branch> 创建 pull/merge request——优先使用代码托管平台的命令行工具，若无则使用推送后打印的创建链接——遵循仓库现有的 PR 模板与规范，并将 URL 汇报给 human partner。
+Then create the pull/merge request against <base-branch> with the forge's
+tooling — its CLI if one is available, or the creation URL most forges
+print when you push — following the repo's PR template and conventions if
+present, and report the URL to your human partner.
 
-保留 worktree——human partner 将在此处理 PR 反馈并继续迭代。
+Keep the worktree — your human partner iterates on PR feedback there.
 
-### 选项 3：保持现状
+### Option 3: Keep As-Is
 
-汇报：“已保留分支 <name>，worktree 保留于 <path>。”
+Report: "Keeping branch <name>. Worktree preserved at <path>."
 
-### 若 human partner 要求丢弃工作
+### If your human partner asks to discard the work
 
-此路径仅在明确要求丢弃工作时触发，需先进行确认：
+This path exists only as a response to an explicit request to throw the
+work away. Confirm first:
 
 ```
-此操作将永久删除：
-- 分支 <name>
-- 全部提交：<commit-list>
-- 位于 <path> 的 worktree
+This will permanently delete:
+- Branch <name>
+- All commits: <commit-list>
+- Worktree at <path>
 
-请输入 'discard' 以确认。
+Type 'discard' to confirm.
 ```
 
-等待该确切确认。确认后：
+Wait for that exact confirmation. When it arrives:
 
 ```bash
 MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
 cd "$MAIN_ROOT"
 ```
 
-然后清理 worktree（步骤 6）并强制删除分支：
+Then clean up the worktree (Step 6) and force-delete the branch:
 
 ```bash
 git branch -D <feature-branch>
 ```
 
-## 步骤 6：清理 worktree
+## Step 6: Cleanup Workspace
 
-**仅在选项 1 与已确认的丢弃操作中执行。** 选项 2 与选项 3 始终保留 worktree。两种调用方已切换至主仓库根目录——worktree 移除必须在 worktree 外部执行——并使用步骤 2 捕获的 `GIT_DIR`/`GIT_COMMON`/`WORKTREE_PATH` 值（目录切换前已保存）。
+**Runs for Option 1 and confirmed discards.** Options 2 and 3 always
+preserve the worktree. Both callers have already changed directory to the
+main repo root — worktree removal must run from outside the worktree —
+and use the `GIT_DIR`/`GIT_COMMON`/`WORKTREE_PATH` values captured in
+Step 2, from before that directory change.
 
-**若 `GIT_DIR == GIT_COMMON`：** 普通仓库，无需清理 worktree，流程结束。
+**If `GIT_DIR == GIT_COMMON`:** Normal repo, no worktree to clean up. Done.
 
-**若 `WORKTREE_PATH` 位于 `.worktrees/` 或 `worktrees/` 之下：** 该 worktree 由 Superpowers 创建——由我们负责清理：
+**If `WORKTREE_PATH` is under `.worktrees/` or `worktrees/`:** Superpowers
+created this worktree — we own cleanup:
 
 ```bash
 git worktree remove "$WORKTREE_PATH"
 git worktree prune  # Self-healing: clean up any stale registrations
 ```
 
-**若移除被拒绝**（提示 `contains modified or untracked files`）：说明 worktree 中存在仅存于此的未提交文件——可能是计划、笔记或临时文件。切勿自行使用 `--force`。向 human partner 展示涉及的文件并征询意见：
+**If removal is refused** (`contains modified or untracked files`): the
+worktree holds files that exist nowhere else — uncommitted plans, notes,
+or scratch work. Never `--force` on your own initiative. Show your human
+partner what is at stake and ask:
 
 ```bash
 git -C "$WORKTREE_PATH" status --porcelain -uall
 ```
 
 ```
-worktree 移除被拒绝——以下文件尚未提交：
+Worktree removal refused — these files were never committed:
 
 <file list>
 
-1. 清理前提交至 <branch>
-2. 移动至 <主仓库根目录>
-3. 删除（不可恢复）
+1. Commit them to <branch> before cleanup
+2. Move them into <main repo root>
+3. Delete them (unrecoverable)
 
-请选择：
+Which?
 ```
 
-按选择执行，随后移除 worktree。
+Carry out the choice, then remove the worktree.
 
-**其他情况：** 该 worktree 由宿主环境托管——保持原样。若平台提供了 worktree 退出工具，请使用它。
+**Otherwise:** The host environment owns this workspace — leave it in
+place. If your platform provides a workspace-exit tool, use it.
 
-## 快速参考
+## Quick Reference
 
-| 选项 | 合并 | 推送 | 保留 Worktree | 清理分支 |
+| Option | Merge | Push | Keep Worktree | Cleanup Branch |
 |--------|-------|------|---------------|----------------|
-| 1. 本地合并 | 是 | - | - | 是 |
-| 2. 创建 PR | - | 是 | 是 | - |
-| 3. 保持现状 | - | - | 是 | - |
-| 丢弃（仅在明确要求时） | - | - | - | 是（强制） |
+| 1. Merge locally | yes | - | - | yes |
+| 2. Create PR | - | yes | yes | - |
+| 3. Keep as-is | - | - | yes | - |
+| Discard (explicit request only) | - | - | - | yes (force) |
 
-## 常见借口与实际情况
+## Common Rationalizations
 
-| 借口 | 实际情况 |
+| Excuse | Reality |
 |--------|---------|
-| “本会话早些时候测试已通过” | 请在即将集成的代码树上重新运行完整测试套件，一次通过仅能证明当时的代码树。 |
-| “他们显然想直接合并” | 集成方式由 human partner 决定，请呈现菜单并等待选择。 |
-| “他们似乎已完成该功能——我来提议丢弃吧” | 菜单已完整，无需额外提议，仅当 human partner 明确要求丢弃时才处理。 |
-| “‘好，删掉吧’也算确认” | 只有输入 `discard` 才视为有效确认并授权删除。 |
-| “PR 已提交，worktree 就是冗余了” | PR 反馈需在该 worktree 中修复，工作落盘前应予以保留。 |
-| “这个 worktree 看起来废弃了——顺手一起清理” | 仅清理位于 `.worktrees/` 或 `worktrees/` 下的 worktree，其余均归宿主环境所有。 |
-| “移除被拒——用 `--force` 收个尾就行” | 拒绝意味着文件仅存在于该 worktree，`--force` 会永久销毁它们，请向 human partner 展示并征询意见。 |
-| “合并后失败大概是偶发问题” | 合并结果失败则立即中止，保留分支与 worktree 以便排查。 |
-| “基线分支显然是 main” | 请确认fork 点或主动询问，合错基线的回滚成本很高。 |
-| “推送被拒——强制推送就能解决” | 推送被拒说明远端已有更新，请先排查；仅在 human partner 明确要求时才执行强制推送。 |
+| "Tests passed earlier this session" | Run the suite on the tree you are about to integrate. A green run only proves the tree it ran on. |
+| "They obviously want it merged" | Integration is your human partner's decision. Present the menu and wait. |
+| "They seem done with this feature — I'll offer to discard it" | The menu is complete as written. Discard happens only when your human partner asks for it in so many words. |
+| "'Yeah, get rid of it' counts as confirmation" | Only the typed word `discard` authorizes deletion. |
+| "The PR is up, so the worktree is clutter now" | PR feedback gets fixed in that worktree. It stays until the work lands. |
+| "This other worktree looks stale — I'll clean it too" | Clean up only worktrees under `.worktrees/` or `worktrees/`. Everything else belongs to the host. |
+| "Removal refused — `--force` is just finishing the cleanup" | The refusal means files exist only in that worktree. `--force` destroys them permanently. Show your human partner and ask. |
+| "The merged-result failure is probably flaky" | A failing merged result stops everything. Branch and worktree stay put while you investigate. |
+| "The base branch is obviously main" | Confirm the fork point or ask. Merging into the wrong base is expensive to undo. |
+| "The push was rejected — force-push will fix it" | A rejected push means the remote moved. Investigate; force-push only on your human partner's explicit request. |

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

@@ -1,205 +1,207 @@
 ---
 name: receiving-code-review
-description: "Superpower Skill：收到代码评审意见时使用，实施建议前需技术验证与澄清，适用于反馈模糊或存疑场景，强调严谨核实而非盲从。"
+description: "Superpower Skill: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation"
+description_zh: "Superpower Skill：收到代码评审意见时使用，实施建议前需技术验证与澄清，适用于反馈模糊或存疑场景，强调严谨核实而非盲从。"
 ---
 
-# 接收代码评审
 
-## 概述
+# Code Review Reception
 
-代码评审需要的是技术研判，而非情绪化表演。
+## Overview
 
-**核心原则：** 先验证，再实施；先提问，再假设。技术正确性优先于社交舒适度。
+Code review requires technical evaluation, not emotional performance.
 
-## 响应模式
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
 
 ```
-WHEN 收到代码评审反馈时：
+WHEN receiving code review feedback:
 
-1. 阅读：完整阅读全部反馈，不急于回应
-2. 理解：用自己的话复述需求（或提问澄清）
-3. 核实：对照代码库实际情况进行校验
-4. 评估：对当前代码库而言是否技术上合理？
-5. 回应：技术性确认或有理有据的异议
-6. 实施：一次处理一项，逐项验证
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
 ```
 
-## 禁止的回应方式
+## Forbidden Responses
 
-**严禁：**
-- "你完全正确！"（明确违反指令文件）
-- "好建议！" / "非常棒的反馈！"（表演式认同）
-- "我马上来实现"（未经核实就承诺）
+**NEVER:**
+- "You're absolutely right!" (explicit instruction-file violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
 
-**应改为：**
-- 复述技术需求
-- 提出澄清问题
-- 若判断有误，用技术理由提出异议
-- 直接开始动手（行动胜于空话）
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
 
-## 处理模糊的反馈
+## Handling Unclear Feedback
 
 ```
-IF 存在表述不清的条目：
-  停止 - 在澄清前不要实施任何内容
-  针对不清晰的条目请求澄清
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
 
-原因：各条目之间可能存在关联。理解不完整会导致实现错误。
+WHY: Items may be related. Partial understanding = wrong implementation.
 ```
 
-**示例：**
+**Example:**
 ```
-你的 human partner："修复 1-6 项"
-你已理解 1,2,3,6，对 4,5 不清楚。
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
 
-[FAIL] 错误做法：先实现 1,2,3,6，之后再问 4,5
-[OK] 正确做法："我已理解 1,2,3,6 项。在继续之前，需要澄清 4 和 5。"
+[FAIL] WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+[OK] RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
 ```
 
-## 按来源区分处理
+## Source-Specific Handling
 
-### 来自你的 human partner
-- **可信** - 理解后即可实施
-- **仍需提问** - 若范围不清晰
-- **不做表演式认同**
-- **直接进入行动**或做技术性确认
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
 
-### 来自外部 reviewer
+### From External Reviewers
 ```
-实施前：
-  1. 检查：对当前代码库而言技术上是否正确？
-  2. 检查：是否会破坏现有功能？
-  3. 检查：当前实现是否有特定原因？
-  4. 检查：是否在所有平台/版本上均可用？
-  5. 检查：reviewer 是否了解完整上下文？
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
 
-IF 建议看似有误：
-  用技术理由提出异议
+IF suggestion seems wrong:
+  Push back with technical reasoning
 
-IF 无法轻易核实：
-  直接说明："没有 [X] 我无法核实这一点。是否需要我[去调研/去询问/继续推进]？"
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
 
-IF 与 human partner 之前的决策冲突：
-  先与 human partner 讨论，再做决定
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
 ```
 
-**你的 human partner 的原则：** "对待外部反馈——保持怀疑，但要认真核查"
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
 
-## 对“专业化”功能的 YAGNI 检查
+## YAGNI Check for "Professional" Features
 
 ```
-IF reviewer 建议"按规范完整实现"：
-  grep 代码库，检查实际调用情况
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
 
-  IF 未被调用："该接口未被调用。是否直接移除（YAGNI）？"
-  IF 已被调用：再按规范完整实现
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
 ```
 
-**你的 human partner 的原则：** "你和 reviewer 都向我汇报。如果我们不需要这个功能，就不要添加。"
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
 
-## 实施顺序
+## Implementation Order
 
 ```
-FOR 多条反馈：
-  1. 先澄清所有不清晰的项
-  2. 然后按以下顺序实施：
-      - 阻塞性问题（崩溃、安全）
-      - 简单修复（拼写、导入）
-      - 复杂修复（重构、逻辑）
-  3. 逐项单独测试
-  4. 验证无回归
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
 ```
 
-## 何时提出异议
+## When To Push Back
 
-出现以下情况时应提出异议：
-- 建议会破坏现有功能
-- reviewer 缺乏完整上下文
-- 违反 YAGNI（功能未被使用）
-- 在当前技术栈下技术上不正确
-- 存在历史/兼容性原因需要保留现状
-- 与 human partner 的架构决策冲突
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
 
-**如何提出异议：**
-- 使用技术理由，而非防御性措辞
-- 提出具体问题
-- 引用可运行的测试/代码
-- 若涉及架构问题，请 human partner 介入
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
 
-**如果你不便当面提出异议：** 先点明这种顾虑，然后私下告知 human partner 你发现的问题。他们会欣赏你的坦诚。
+**If you're uncomfortable pushing back out loud:** Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
 
-## 确认正确的反馈
+## Acknowledging Correct Feedback
 
-当反馈确实正确时：
+When feedback IS correct:
 ```
-[OK] "已修复。[简要说明改了什么]"
-[OK] "捉得好——[具体问题]。已在[位置]修复。"
-[OK] [直接修复，并在代码中体现]
+[OK] "Fixed. [Brief description of what changed]"
+[OK] "Good catch - [specific issue]. Fixed in [location]."
+[OK] [Just fix it and show in the code]
 
-[FAIL] "你完全正确！"
-[FAIL] "好建议！"
-[FAIL] "感谢指出！"
-[FAIL] "谢谢你的[任何内容]"
-[FAIL] 任何形式的感谢措辞
+[FAIL] "You're absolutely right!"
+[FAIL] "Great point!"
+[FAIL] "Thanks for catching that!"
+[FAIL] "Thanks for [anything]"
+[FAIL] ANY gratitude expression
 ```
 
-**为何不说感谢：** 行动即回应。直接修复即可。代码本身就能证明你已听取反馈。
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
 
-**如果你发现自己正要写"感谢"：** 删掉它。改为陈述修复内容。
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
 
-## 优雅地纠正你的异议
+## Gracefully Correcting Your Pushback
 
-如果你提出异议后发现自己错了：
+If you pushed back and were wrong:
 ```
-[OK] "你是对的——我检查了 [X]，确实会 [Y]。正在实现。"
-[OK] "已核实，你是正确的。我最初理解有误是因为[原因]。正在修复。"
+[OK] "You were right - I checked [X] and it does [Y]. Implementing now."
+[OK] "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
 
-[FAIL] 长篇道歉
-[FAIL] 为何当初要提出异议的辩解
-[FAIL] 过度解释
+[FAIL] Long apology
+[FAIL] Defending why you pushed back
+[FAIL] Over-explaining
 ```
 
-客观陈述纠正事实，然后继续推进。
+State the correction factually and move on.
 
-## 常见错误
+## Common Mistakes
 
-| 错误 | 修正方法 |
+| Mistake | Fix |
 |---------|-----|
-| 表演式认同 | 陈述需求或直接行动 |
-| 盲目实施 | 先对照代码库核实 |
-| 批量修改且不测试 | 一次一项，逐项测试 |
-| 默认 reviewer 一定正确 | 检查是否会引发破坏 |
-| 回避异议 | 技术正确性优先于舒适度 |
-| 部分实现 | 先澄清所有条目 |
-| 无法核实仍继续推进 | 说明局限性，请求指示 |
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
 
-## 实际示例
+## Real Examples
 
-**表演式认同（错误）：**
+**Performative Agreement (Bad):**
 ```
-reviewer："移除历史遗留代码"
-[FAIL] "你完全正确！我来移除……"
+Reviewer: "Remove legacy code"
+[FAIL] "You're absolutely right! Let me remove that..."
 ```
 
-**技术核实（正确）：**
+**Technical Verification (Good):**
 ```
-reviewer："移除历史遗留代码"
-[OK] "核查中……构建目标是 10.15+，该 API 需要 13+。为兼容旧版本仍需保留历史代码。当前实现 bundle ID 有误——是修复它，还是放弃对 13 以下版本的支持？"
+Reviewer: "Remove legacy code"
+[OK] "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
 ```
 
-**YAGNI（正确）：**
+**YAGNI (Good):**
 ```
-reviewer："用数据库、日期筛选、CSV 导出完整实现指标统计"
-[OK] "已 grep 代码库——没有地方调用该接口。是否直接移除（YAGNI）？还是有我未发现的调用场景？"
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+[OK] "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
 ```
 
-**条目不清晰（正确）：**
+**Unclear Item (Good):**
 ```
-你的 human partner："修复 1-6 项"
-你已理解 1,2,3,6，对 4,5 不清楚。
-[OK] "已理解 1,2,3,6。实现前需要澄清 4 和 5。"
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+[OK] "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
 ```
 
-## GitHub 评论线程回复
+## GitHub Thread Replies
 
-在 GitHub 上回复行内评审意见时，请在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而非作为 PR 的顶层评论。
+When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.