superpowers-zh 1.7.7 → 1.7.8

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "superpowers-zh",
       "description": "AI 编程超能力中文增强版：20 个 skills（14 翻译 + 4 中国原创 + 2 上游历史保留），支持 Claude Code / Hermes Agent / Cursor / Claw Code / Qoder 等 23 款工具",
-      "version": "1.7.7",
+      "version": "1.7.8",
       "source": "./",
       "author": {
         "name": "jnMetaCode",

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "superpowers-zh",
   "description": "AI 编程超能力中文增强版：20 个 skills（14 翻译 + 4 中国原创 + 2 上游历史保留），支持 Claude Code / Hermes Agent / Cursor / Claw Code / Qoder 等 23 款工具",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "author": {
     "name": "jnMetaCode",
     "url": "https://github.com/jnMetaCode"

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "superpowers-zh",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "description": "AI 编程超能力中文增强版：头脑风暴、subagent 驱动开发、规划、TDD、调试、代码审查、收尾工作流，附 4 个中文 skills 沉淀。",
   "author": {
     "name": "jnMetaCode",

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "superpowers-zh",
   "displayName": "Superpowers 中文版",
   "description": "AI 编程超能力中文增强版：20 个 skills（14 翻译 + 4 中国原创 + 2 上游历史保留），支持 Cursor / Claude Code / Hermes Agent / Claw Code / Qoder 等 23 款工具",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "author": {
     "name": "jnMetaCode",
     "url": "https://github.com/jnMetaCode"

package/README.md

@@ -16,7 +16,8 @@ Chinese community edition of [superpowers](https://github.com/obra/superpowers)
 >
 > 🌍 Also available in [English](https://aiolaola.com/en?utm_source=github&utm_campaign=superpowers) · [日本語](https://aiolaola.com/ja?utm_source=github&utm_campaign=superpowers) · [Español](https://aiolaola.com/es?utm_source=github&utm_campaign=superpowers) · [한국어](https://aiolaola.com/ko?utm_source=github&utm_campaign=superpowers) · [繁體中文](https://aiolaola.com/zh-Hant?utm_source=github&utm_campaign=superpowers)
 
-> 🆕 **v1.7.7 更新亮点**（[完整 Release Notes →](RELEASE-NOTES.zh.md)）
+> 🆕 **v1.7.8 更新亮点**（[完整 Release Notes →](RELEASE-NOTES.zh.md)）
+> - 🔍 **定位核查** —— 逐层比对上游，修掉 5 处「不是增量」的偏离；新增 audit 检查强制 fork 增量必须显式声明
 > - 🆕 **新增 Crush**（工具数 22 → 23）—— 若你已为 CC / Cursor / Codex 装过，Crush 其实已经能读到，别重复装
 > - 🎯 **上游 v6.2.0 对齐完成** —— audit 的结构漂移告警清零；C 块盘点时发现其中 3 项不是风格改动而是实质新规则
 > - 🐛 **两个 worktree / Gemini 的真问题** —— 修掉 worktree 清理静默空转；更正「Gemini 不支持子智能体」的错误说法（原说法会让 3 个 skill 在 Gemini CLI 上瘸腿）
@@ -118,6 +119,7 @@ AI：在开始实现之前，我需要了解几个关键问题：
 | 🇨🇳 中文文档规范 | 无 | 中文排版 + 中英混排规则 + 告别机翻味 |
 | ➕ MCP 服务器构建 | 无 | 独立 `mcp-builder` skill |
 | ➕ 工作流执行器 | 无 | 独立 `workflow-runner` skill（多角色 YAML 编排） |
+| ➕ 翻译 skill 内的增量 | — | 仅 2 处，均在正文显式标注「本节是 superpowers-zh 的增量内容」：`executing-plans` 的「常见异常处理」、`using-superpowers` 的「中国特色技能路由」。**上游各节均为逐节翻译，不被改动**；audit 会强制未标注的增量报错 |
 | 🔄 版本跟进 | 独立迭代 | **同步上游 + 国产增量叠加** |
 | 🤝 接受新 skill PR | 一般不接受（原文：*"we don't generally accept contributions of new skills"*） | 欢迎 PR（中国开发者痛点优先） |
 | 💬 社区 | Discord | 微信公众号「AI不止语」+ 微信群 + QQ 群 |

package/README.zh-Hant.md

@@ -16,7 +16,8 @@ Chinese community edition of [superpowers](https://github.com/obra/superpowers)
 
 > 📖 **免費配套學習** → [從零學會 AI 編程](https://aiolaola.com/?utm_source=github&utm_campaign=superpowers)：180 節免費實操課 + 《AI 編程實戰三卷書》線上閱讀 + 實戰社群 · superpowers 裝好後配上方法論效率翻倍 · 永久免費
 
-> 🆕 **v1.7.7 更新亮點**（[完整 Release Notes →](RELEASE-NOTES.zh.md)）
+> 🆕 **v1.7.8 更新亮點**（[完整 Release Notes →](RELEASE-NOTES.zh.md)）
+> - 🔍 **定位核查** —— 逐層比對上游，修掉 5 處「不是增量」的偏離；新增 audit 檢查強制 fork 增量必須顯式聲明
 > - 🆕 **新增 Crush**（工具數 22 → 23）—— 若你已為 CC / Cursor / Codex 裝過，Crush 其實已經能讀到，別重複裝
 > - 🎯 **上游 v6.2.0 對齊完成** —— audit 的結構漂移告警清零；C 塊盤點時發現其中 3 項不是風格改動而是實質新規則
 > - 🐛 **兩個 worktree / Gemini 的真問題** —— 修掉 worktree 清理靜默空轉；更正「Gemini 不支援子智能體」的錯誤說法（原說法會讓 3 個 skill 在 Gemini CLI 上瘸腿）
@@ -118,6 +119,7 @@ AI：在開始實作之前，我需要了解幾個關鍵問題：
 | 🇨🇳 中文文件規範 | 無 | 中文排版 + 中英混排規則 + 告別機翻味 |
 | ➕ MCP 伺服器建置 | 無 | 獨立 `mcp-builder` skill |
 | ➕ 工作流執行器 | 無 | 獨立 `workflow-runner` skill（多角色 YAML 編排） |
+| ➕ 翻譯 skill 內的增量 | — | 僅 2 處，均在正文顯式標註「本節是 superpowers-zh 的增量內容」：`executing-plans` 的「常見異常處理」、`using-superpowers` 的「中國特色技能路由」。**上游各節均為逐節翻譯，不被改動**；audit 會強制未標註的增量報錯 |
 | 🔄 版本跟進 | 獨立迭代 | **同步上游 + 國產增量疊加** |
 | 🤝 接受新 skill PR | 一般不接受（原文：*"we don't generally accept contributions of new skills"*） | 歡迎 PR（中國開發者痛點優先） |
 | 💬 社群 | Discord | 微信公眾號「AI不止語」+ 微信群 + QQ 群 |

package/RELEASE-NOTES.zh.md

@@ -6,6 +6,67 @@
 
 ---
 
+## v1.7.8 (2026-08-08)
+
+本版本源于一次**定位核查**：按「superpowers-zh 只是完整翻译上游 + 增加更多工具支持」这个定位，逐层比对我们与 [obra/superpowers](https://github.com/obra/superpowers) 的差异。结论是**定位基本站得住，但不完全** —— 查出 5 处偏离，全部修掉。
+
+### 🔍 核查方法
+
+1. **文件级**：上游 `skills/` 与我们逐文件比对，分出「仅上游有」「仅我们有」
+2. **内容级**：14 个翻译 skill 各自比对标题数（排除代码围栏）、表格行数、列表项数
+3. **溯源**：每处差异追查来源 —— 是声明过的 fork 增量，还是漏译／漏同步
+
+### 🐛 修掉的 5 处偏离
+
+**① `antigravity-tools.md` 上游有、我们没有**
+
+而 installer 里明明支持 Antigravity —— 该工具用户拿不到任何工具映射。影响是实质的：**Antigravity 没有 todo 工具**（`manage_task` 管的是后台进程），没这份映射，所有说「创建待办」的 skill 在它上面都会走偏。已翻译补入，并按上游同序列入平台适配清单。
+
+**② `finishing-a-development-branch` 漏同步 3 个 commit**
+
+C 块时的 commit 清单不全，漏了 `fbb6dba` / `bcfe798` / `9dff1a9`。其中 `9dff1a9` 是**行为变更**：上游把菜单从 4 个选项减为 3 个，**删掉了「丢弃这份工作」**，丢弃改为只在人类伙伴明确提出时才走的独立小节；基础分支判定也从盲跑 `merge-base` 改为「先确认，合并到错分支代价很高」。已照上游当前状态整体重译（一次拿到全部 4 个 commit），并断言 D 块的 worktree 修复完整保留。
+
+**③ `writing-plans` 漏译整节** —— 上游的 `Task Right-Sizing`（任务边界怎么划）我们完全没有。
+
+**④ `writing-skills` 四个问题** —— 漏译 H2 整节 `Match the Form to the Failure`（含「禁令在塑形类问题上会反噬」的实测结论）、漏译 H3 `Micro-Test Wording Before Full Scenarios`、**两个连续小节都编号为 4**、节名仍是过时的「Claude 搜索优化（CSO）」（上游早已改名 SDO），正文两处引用一并同步。
+
+**⑤ fork 增量插在了上游步骤序列中间**
+
+`executing-plans` 把「处理常见异常」插成步骤 3，于是上游的 `Step 3: Complete Development` 被挤成我们的「步骤 4」；`Remember` 也从上游的 6 条被加到 7 条。**这不是「不影响上游」，是改了上游的结构编号。**
+
+改为**外挂式**：增量移出步骤序列、挂在「何时停下来求助」之后（它本就是那节三种情形的展开），步骤编号恢复 1/2/3，`Remember` 恢复 6 条。
+
+### 🛡️ 让「不影响上游」成为可执行的检查
+
+README 声明会漂移，所以新增 **audit 3c-bis**：
+
+> 翻译 skill 的标题数必须等于「上游标题数 + 本文件里带标注的增量节数」
+
+增量节靠正文里一行标注声明（`本节是 superpowers-zh 的增量内容`），标注与内容同处一文件、不会各自漂移。**未标注就多出章节 = 隐性分叉，直接 FAIL。** 已双向验证：偷偷加一节会被拦下并给出可操作提示，加标注后放行。
+
+目前全仓仅 2 处带标注的增量：`executing-plans` 的「常见异常处理」、`using-superpowers` 的「中国特色技能路由」。
+
+### 🐛 修掉一个让守卫从未生效的 bug
+
+3c-bis 第一次测试**没拦住**。查出原因：`grep -c` 匹配到 0 个时输出 `"0"` 但**退出码为 1**，写成 `$(grep -c ... || echo 0)` 会拼出 `"0\n0"`，后续整数比较直接报错、检查静默失效。改用 `; true` 只吞退出码。
+
+全仓扫同一模式，**测试辅助里也有 3 处**（上游同样有）：`test-helpers.sh` 的 `assert_count`、`test-subagent-driven-development-integration.sh` 的 `task_count` / `todo_count`。后果是这些断言**永远无法正常失败** —— 模式没匹配到时比较报错而非判定失败。三处一并修掉并加注释。（`tests/` 不进 npm 包，仅开发使用。）
+
+修复后 audit 由 154 升到 **166 pass** —— 因为 3c-bis 现在真的对 14 个 skill 都跑了。
+
+### ✅ 核查后的定位现状
+
+**纯增量部分（符合定位）：**
+- 6 个 fork 专属 skill：`chinese-*` ×4 + `mcp-builder` + `workflow-runner`
+- 3 个 fork 专属 references：`copilot` / `hermes` / `qoder`（我们支持、上游不支持或已删的 harness）
+- 2 处带标注的翻译 skill 内增量
+
+**14 个翻译 skill 的上游各节现已全部逐节对应。**
+
+`scripts/audit.sh` **166 pass / 0 warn / 0 fail**、`scripts/verify-release.sh` **90 pass / 0 fail**。
+
+---
+
 ## v1.7.7 (2026-08-08)
 
 ### 🆕 新增 Crush 适配（工具数 22 → 23，关 #40）

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "superpowers-zh",
   "description": "AI 编程超能力中文版 — TDD、调试、代码审查等经过实战验证的工作方法论",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "contextFileName": "GEMINI.md"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "superpowers-zh",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "engines": {
     "node": ">=20.0.0"
   },

package/skills/executing-plans/SKILL.md

@@ -90,29 +90,7 @@ $ git commit -m "feat: 添加用户输入验证（任务 2/5）"
 - 执行过程中持续留意：整体方向还对吗？有没有偏离计划？
 - 如果发现前面的实现有问题，先修复再继续，不要带着问题往下走
 
-### 步骤 3：处理常见异常
-
-**测试失败：**
-1. 读错误信息，定位失败原因
-2. 区分：是实现 bug？还是测试本身有问题？还是计划描述有误？
-3. 实现 bug → 修复并重跑
-4. 测试有问题 → 修复测试，向伙伴说明
-5. 计划有误 → 停下来，向伙伴报告并建议修正
-
-**依赖缺失：**
-```
-任务 3 需要 Redis 连接，但计划中没有提及 Redis 配置。
-→ 停止执行
-→ 向伙伴报告："任务 3 需要 Redis，计划中未包含配置步骤。
-   建议：在任务 3 前插入 '配置 Redis 连接' 步骤。"
-```
-
-**指令不清：**
-- 不要猜测意图，不要"合理推断"
-- 列出你的理解和困惑，让伙伴澄清
-- 等待回复后再继续
-
-### 步骤 4：完成开发
+### 步骤 3：完成开发
 
 所有任务完成并验证后：
 - 宣布："我正在使用 finishing-a-development-branch 技能来完成此工作。"
@@ -156,6 +134,35 @@ $ git commit -m "feat: 添加用户输入验证（任务 2/5）"
 
 **不确定时就问，不要猜测。**
 
+## 常见异常处理
+
+> 🇨🇳 **本节是 superpowers-zh 的增量内容，上游 obra/superpowers 没有。**
+> 它展开的是上一节「遇到阻塞（缺少依赖、测试失败、指令不清）」的三种具体情形。
+> 上游的步骤 1–3 与其余各节均为逐节翻译，未被本节改动。
+
+
+**测试失败：**
+1. 读错误信息，定位失败原因
+2. 区分：是实现 bug？还是测试本身有问题？还是计划描述有误？
+3. 实现 bug → 修复并重跑
+4. 测试有问题 → 修复测试，向伙伴说明
+5. 计划有误 → 停下来，向伙伴报告并建议修正
+
+**依赖缺失：**
+```
+任务 3 需要 Redis 连接，但计划中没有提及 Redis 配置。
+→ 停止执行
+→ 向伙伴报告："任务 3 需要 Redis，计划中未包含配置步骤。
+   建议：在任务 3 前插入 '配置 Redis 连接' 步骤。"
+```
+
+**指令不清：**
+- 不要猜测意图，不要"合理推断"
+- 列出你的理解和困惑，让伙伴澄清
+- 等待回复后再继续
+
+**提交粒度：** 每个任务单独提交，commit message 引用任务编号。
+
 ## 何时回到之前的步骤
 
 **回到审查（步骤 1）当：**
@@ -168,7 +175,6 @@ $ git commit -m "feat: 添加用户输入验证（任务 2/5）"
 - 先批判性审查计划
 - 严格按照计划步骤执行
 - 不要跳过验证
-- 每个任务单独提交，commit message 引用任务编号
 - 计划要求时引用相应技能
 - 遇到阻塞时停下来，不要猜测
 - 未经用户明确同意，绝不在 main/master 分支上开始实现

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

@@ -1,6 +1,6 @@
 ---
 name: finishing-a-development-branch
-description: 当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
+description: 当实现完成、所有测试通过、需要决定如何集成这份工作时使用
 version: "1.0.0"
 license: MIT
 metadata:
@@ -8,44 +8,29 @@ metadata:
     tags: [git, workflow]
 ---
 
-# 完成开发分支
+# 收尾一个开发分支
 
 ## 概述
 
-通过提供清晰的选项并执行所选工作流来引导开发工作的收尾。
-
 **核心原则：** 验证测试 → 检测环境 → 展示选项 → 执行选择 → 清理。
 
-**开始时宣布：** "我正在使用 finishing-a-development-branch 技能来完成这项工作。"
-
-## 流程
-
-### 步骤 1：验证测试
+**开始时宣告：** "我正在使用 finishing-a-development-branch 技能来收尾这份工作。"
 
-**在展示选项之前，验证测试通过：**
+## 步骤 1：验证测试
 
-```bash
-# 运行项目的测试套件
-npm test / cargo test / pytest / go test ./...
-```
+运行项目的完整测试套件（`npm test` / `cargo test` / `pytest` / `go test ./...`）。
 
-**如果测试失败：**
+**如果测试失败**，报告失败并停下——菜单是在测试全绿之后才出现的：
 
 ```
-测试失败（<N> 个失败）。必须先修复才能继续：
-
-[显示失败信息]
+测试失败（<N> 个）。完成之前必须先修：
 
-在测试通过之前无法进行合并/PR。
+[展示失败详情]
 ```
 
-停止。不要继续到步骤 2。
-
 **如果测试通过：** 继续步骤 2。
 
-### 步骤 2：检测环境
-
-**在展示选项之前，先确定工作区状态：**
+## 步骤 2：检测环境
 
 ```bash
 GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
@@ -59,51 +44,44 @@ WORKTREE_PATH=$(git rev-parse --show-toplevel)
 
 | 状态 | 菜单 | 清理 |
 |------|------|------|
-| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 4 个选项 | 无 worktree 可清理 |
-| `GIT_DIR != GIT_COMMON`，命名分支 | 标准 4 个选项 | 按来源判断（见步骤 6） |
-| `GIT_DIR != GIT_COMMON`，分离 HEAD | 收敛 3 个选项（无合并） | 无清理（由外部管理） |
-
-### 步骤 3：确定基础分支
+| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 3 个选项 | 无 worktree 可清理 |
+| `GIT_DIR != GIT_COMMON`，命名分支 | 标准 3 个选项 | 按来源判断（见步骤 6） |
+| `GIT_DIR != GIT_COMMON`，分离 HEAD | 收敛为 2 个选项（不含合并） | 由外部管理——原地别动 |
 
-```bash
-# 尝试常见的基础分支
-git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
-```
+## 步骤 3：确定基础分支
 
-或者询问："这个分支是从 main 分出来的——对吗？"
+基础分支就是这份工作从哪儿分出来的那个——通常在计划里、对话里，或者分支的 upstream 里已经写明了。如果还不知道，就问："这个分支是从 <你的最佳猜测> 分出来的，对吗？"**合并之前先确认：合并到错误的基础分支，代价很高。**
 
-### 步骤 4：展示选项
+## 步骤 4：展示选项
 
-**普通仓库和命名分支 worktree —— 准确展示以下 4 个选项：**
+**普通仓库和命名分支 worktree——精确展示这 3 个选项：**
 
 ```
 实现已完成。你想怎么做？
 
-1. 在本地合并回 <base-branch>
+1. 本地合并回 <base-branch>
 2. 推送并创建 Pull Request
-3. 保持分支现状（我稍后处理）
-4. 丢弃这项工作
+3. 保留分支不动（我稍后自己处理）
 
 选哪个？
 ```
 
-**分离 HEAD —— 准确展示以下 3 个选项：**
+**分离 HEAD——精确展示这 2 个选项：**
 
 ```
-实现已完成。你在分离 HEAD 上（由外部管理的工作区）。
+实现已完成。你当前处于分离 HEAD（由外部管理的工作区）。
 
 1. 作为新分支推送并创建 Pull Request
-2. 保持现状（我稍后处理）
-3. 丢弃这项工作
+2. 保持原样（我稍后自己处理）
 
 选哪个？
 ```
 
-**不要添加解释** —— 保持选项简洁。
+**照原文展示菜单**——简洁，每个选项都来自上面的列表。**丢弃工作只在你的人类伙伴明确提出时才发生**（见下方"如果你的人类伙伴要求丢弃这份工作"）。等他们回答；集成与否是他们的决定。
 
-### 步骤 5：执行选择
+## 步骤 5：执行选择
 
-#### 选项 1：本地合并
+### 选项 1：本地合并
 
 ```bash
 # 切到主仓库根目录，保证 CWD 安全
@@ -116,164 +94,95 @@ git pull
 git merge <feature-branch>
 
 # 在合并结果上验证测试
-<test command>
-
-# 合并成功之后再：清理 worktree（步骤 6），然后删除分支
+<测试命令>
 ```
 
-然后：清理 worktree（步骤 6），再删除分支：
+如果测试在**合并结果**上失败：停下，把 worktree 和分支原地留着，去排查——什么都还没推送，所以这次合并是本地的、可恢复的。
+
+一旦合并结果全绿：清理 worktree（步骤 6），然后删除分支：
 
 ```bash
 git branch -d <feature-branch>
 ```
 
-#### 选项 2：推送并创建 PR
+### 选项 2：推送并创建 PR
 
 ```bash
-# 推送分支
 git push -u origin <feature-branch>
 # 从分离 HEAD 出发时，在远端指定新分支名：
 # git push origin HEAD:refs/heads/<new-branch>
-
-# 创建 PR
-gh pr create --title "<title>" --body "$(cat <<'EOF'
-## 摘要
-<2-3 条变更要点>
-
-## 测试计划
-- [ ] <验证步骤>
-EOF
-)"
 ```
 
-**不要清理 worktree** —— 用户在 PR 反馈迭代时还需要它存活。
+然后用**代码托管平台**（forge）的工具针对 <base-branch> 创建 pull/merge request——有 CLI 就用它，没有就用推送时大多数平台会打印出来的创建 URL——遵循仓库里已有的 PR 模板与约定（如果有），并把 URL 报告给你的人类伙伴。
 
-#### 选项 3：保持现状
+**保留 worktree**——你的人类伙伴要在那里根据 PR 反馈继续迭代。
 
-报告："保留分支 <name>。工作树保留在 <path>。"
+### 选项 3：保持原样
 
-**不要清理工作树。**
+报告："保留分支 <name>。工作树保留在 <path>。"
 
-#### 选项 4：丢弃
+### 如果你的人类伙伴要求丢弃这份工作
 
-**先确认：**
+**这条路只作为对"明确要求把工作扔掉"的响应而存在。** 先确认：
 
 ```
 这将永久删除：
 - 分支 <name>
-- 所有提交：<commit-list>
-- 工作树 <path>
+- 所有 commit：<commit 列表>
+- 位于 <path> 的工作树
 
-输入 'discard' 确认。
+输入 'discard' 以确认。
 ```
 
-等待精确的确认。
-
-确认后：
+等待**这个精确的**确认词。收到之后：
 
 ```bash
 MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
 cd "$MAIN_ROOT"
 ```
 
-然后：清理 worktree（步骤 6），再强制删除分支：
+然后清理 worktree（步骤 6），再强制删除分支：
 
 ```bash
 git branch -D <feature-branch>
 ```
 
-### 步骤 6：清理工作区
+## 步骤 6：清理工作区
 
-**只对选项 1 和 4 执行。** 选项 2 和 3 始终保留 worktree。两个调用方都已经切到主仓库根目录了 —— 移除 worktree 必须从 worktree 外面执行 —— 因此这里使用**步骤 2 里捕获的** `GIT_DIR` / `GIT_COMMON` / `WORKTREE_PATH`，也就是那次目录切换之前的值。
+**只对选项 1 和已确认的丢弃执行。** 选项 2 和 3 始终保留 worktree。两个调用方都已经切到主仓库根目录了——移除 worktree 必须从 worktree 外面执行——因此这里使用**步骤 2 里捕获的** `GIT_DIR` / `GIT_COMMON` / `WORKTREE_PATH`，也就是那次目录切换之前的值。
 
 > ⚠️ **不要在这里重新计算这些值。** 此刻 `git rev-parse --show-toplevel` 返回的是主仓库根目录，不是 worktree 路径 —— 溯源判断会永远匹配不上，清理会静默空转，随后分支删除还会因为 worktree 仍挂着而失败。
 
 **如果 `GIT_DIR == GIT_COMMON`：** 普通仓库，无 worktree 可清理。结束。
 
-**如果 `WORKTREE_PATH` 在 `.worktrees/` 或 `worktrees/` 之下：** 这是 Superpowers 创建的 worktree —— 我们负责清理。
+**如果 `WORKTREE_PATH` 在 `.worktrees/` 或 `worktrees/` 之下：** 这是 Superpowers 创建的 worktree——我们负责清理：
 
 ```bash
 git worktree remove "$WORKTREE_PATH"
 git worktree prune  # 自愈：清理任何过期的注册记录
 ```
 
-**否则：** 这个工作区由宿主环境（harness）管理。**不要**移除它。如果你的平台提供了工作区退出工具，用它。否则原样保留工作区。
+**否则：** 这个工作区归宿主环境所有——原地别动。如果你的平台提供了工作区退出工具，用它。
 
 ## 快速参考
 
 | 选项 | 合并 | 推送 | 保留工作树 | 清理分支 |
 |------|------|------|-----------|---------|
-| 1. 本地合并 | ✓ | - | - | ✓ |
-| 2. 创建 PR | - | ✓ | ✓ | - |
-| 3. 保持现状 | - | - | ✓ | - |
-| 4. 丢弃 | - | - | - | ✓（强制） |
-
-## 常见错误
-
-**跳过测试验证**
-
-- **问题：** 合并损坏的代码、创建失败的 PR
-- **修复：** 在提供选项前始终验证测试
-
-**开放式问题**
-
-- **问题：** "接下来该做什么？" → 含糊不清
-- **修复：** 准确展示 4 个结构化选项（分离 HEAD 时是 3 个）
-
-**为选项 2 清理 worktree**
-
-- **问题：** 删掉用户 PR 迭代还需要的 worktree
-- **修复：** 只在选项 1 和 4 时清理
-
-**先删分支再删 worktree**
-
-- **问题：** `git branch -d` 失败，因为 worktree 还引用着该分支
-- **修复：** 先合并，再删 worktree，最后删分支
-
-**在 worktree 内部跑 `git worktree remove`**
-
-- **问题：** 当 CWD 在被删除的 worktree 内时，命令静默失败
-- **修复：** 跑 `git worktree remove` 前先 `cd` 到主仓库根目录
-
-**清理 harness 拥有的 worktree**
-
-- **问题：** 移除 harness 创建的 worktree 会造成幻影状态
-- **修复：** 只清理 `.worktrees/` 或 `worktrees/` 下的 worktree
-
-**丢弃时不确认**
-
-- **问题：** 意外删除工作成果
-- **修复：** 要求输入 'discard' 确认
-
-## 红线
-
-**绝不：**
-
-- 在测试失败时继续
-- 合并前不验证合并结果上的测试
-- 不确认就删除工作成果
-- 未经明确请求就强制推送
-- 在确认合并成功之前移除 worktree
-- 清理不是你创建的 worktree（按来源判断）
-- 在 worktree 内部跑 `git worktree remove`
-
-**始终：**
-
-- 在提供选项前验证测试
-- 展示菜单前检测环境
-- 准确展示 4 个选项（分离 HEAD 时是 3 个）
-- 选项 4 要求输入确认
-- 只在选项 1 和 4 时清理 worktree
-- 移除 worktree 前 `cd` 到主仓库根目录
-- 移除后跑 `git worktree prune`
-
-## 集成
-
-**被以下技能调用：**
-
-- **subagent-driven-development**（步骤 7）- 所有任务完成后
-- **executing-plans**（步骤 5）- 所有批次完成后
-
-**配合使用：**
-
-- **using-git-worktrees** - 清理由该技能创建的工作树
+| 1. 本地合并 | 是 | - | - | 是 |
+| 2. 创建 PR | - | 是 | 是 | - |
+| 3. 保持原样 | - | - | 是 | - |
+| 丢弃（仅在明确要求时） | - | - | - | 是（强制） |
+
+## 常见的合理化借口
+
+| 借口 | 现实 |
+|------|------|
+| "测试这个会话早先通过过" | 在**你即将集成的那棵树上**跑测试套件。一次绿色运行只能证明它当时跑的那棵树。 |
+| "他们显然是想合并的" | 集成是你人类伙伴的决定。把菜单摆出来，然后等。 |
+| "他们看起来对这个功能收工了——我提议丢弃吧" | 菜单就是原文那样，不多不少。丢弃只在你的人类伙伴用明确的话提出时才发生。 |
+| "'嗯，删掉吧'算确认了" | 只有输入 `discard` 这个词才授权删除。 |
+| "PR 已经开了，worktree 现在是碍事的垃圾" | PR 反馈要在那个 worktree 里修。它得留到工作落地为止。 |
+| "另外那个 worktree 看着像过期的——我顺手也清了" | 只清理 `.worktrees/` 或 `worktrees/` 之下的 worktree。其余的都属于宿主环境。 |
+| "合并结果的失败大概是偶发的" | 合并结果失败会让一切停下。在你排查期间，分支和 worktree 原地不动。 |
+| "基础分支明显就是 main" | 确认分叉点，或者直接问。合并到错误的基础分支，代价很高。 |
+| "推送被拒了——force-push 一下就好" | 推送被拒意味着远端动过了。去排查；只有在你人类伙伴明确要求时才 force-push。 |

package/skills/using-superpowers/SKILL.md

@@ -60,6 +60,7 @@ metadata:
 
 - Codex：`references/codex-tools.md`
 - Pi：`references/pi-tools.md`
+- Antigravity：`references/antigravity-tools.md`
 - Copilot CLI：`references/copilot-tools.md`
 - Hermes Agent：`references/hermes-tools.md`
 - Qoder：`references/qoder-tools.md`
@@ -68,6 +69,9 @@ Gemini CLI 用户通过 GEMINI.md 自动获得 `references/gemini-tools.md` 的
 
 ## 中国特色技能路由
 
+> 🇨🇳 **本节是 superpowers-zh 的增量内容，上游 obra/superpowers 没有。**
+> 用于把中文场景路由到本 fork 原创的 chinese-* 系列 skill。其余各节均为逐节翻译。
+
 当检测到以下场景时，**必须**优先调用对应的中国特色技能：
 
 | 场景 | 调用技能 |

package/skills/using-superpowers/references/antigravity-tools.md

@@ -0,0 +1,14 @@
+# Antigravity CLI（`agy`）工具映射
+
+Skills 说的是动作（"分派一个子智能体"、"建一条待办"、"读一个文件"）。在 Antigravity CLI（`agy`）上，这些动作对应下面这些工具。
+
+| Skill 请求的动作 | Antigravity CLI 等价工具 |
+|----------------|----------------------|
+| 分派子智能体（`Subagent (general-purpose):` 模板） | `invoke_subagent`，配一个内置的 `TypeName` —— 全能力工作用 `self`，只读调研用 `research` |
+| 任务跟踪（"建一条待办"、"标记完成"） | 一个 **task artifact** —— 用 `write_to_file` 并带上 `IsArtifact: true` 与 `ArtifactType: "task"`（见下方[任务跟踪](#任务跟踪)）。**不是** `manage_task`，那个是管后台进程的。 |
+
+## 任务跟踪
+
+Antigravity **没有 todo 工具**（`manage_task` 管的是后台进程 —— `list`／`kill`／`status`／`send_input` —— 它**不是**清单工具）。当某个 skill 说要创建待办清单或跟踪任务时，改为维护一个 **task artifact**：一份用 `write_to_file` 保存的 markdown 清单（`IsArtifact: true`、`ArtifactMetadata.ArtifactType: "task"`），过程中用 `replace_file_content` ／ `multi_replace_file_content` 来编辑。
+
+任何多步任务一开始，就创建这个 task artifact，把你计划里的每一步都列上。每完成一步，就编辑该 artifact 把它标记为完成（`- [x]`）。计划有变就更新清单。**保持它是最新的** —— 它是"还剩什么没做"的唯一事实来源；一旦对话变长，每开始一步之前先重读它。

package/skills/writing-plans/SKILL.md

@@ -38,6 +38,10 @@ metadata:
 
 此结构决定了任务分解。每个任务应产出独立的、有意义的变更。
 
+## 任务粒度定界
+
+一个任务是**能独立承载自己那一轮测试循环、且值得一个全新审查者把关**的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个**可独立测试的交付物**结束。
+
 ## 小步骤任务粒度
 
 **每步是一个操作（2-5 分钟）：**

package/skills/writing-skills/SKILL.md

@@ -103,7 +103,7 @@ skills/
 - `description`：第三人称，仅描述何时使用（不是做什么）
   - 以"Use when..."开头，聚焦于触发条件
   - 包含具体的症状、场景和上下文
-  - **绝不总结技能的流程或工作流**（参见 CSO 章节了解原因）
+  - **绝不总结技能的流程或工作流**（参见 SDO 章节了解原因）
   - 尽量控制在 500 字符以内
 
 ```markdown
@@ -141,7 +141,7 @@ description: Use when [具体的触发条件和症状]
 ```
 
 
-## Claude 搜索优化（CSO）
+## 技能发现优化（SDO）
 
 **发现至关重要：** 未来的 Claude 需要找到你的技能
 
@@ -279,7 +279,7 @@ wc -w skills/path/SKILL.md
 - `creating-skills`、`testing-skills`、`debugging-with-logs`
 - 主动的，描述你正在进行的操作
 
-### 4. 交叉引用其他技能
+### 5. 交叉引用其他技能
 
 **编写引用其他技能的文档时：**
 
@@ -460,6 +460,23 @@ pptx/
 
 **以上所有都意味着：部署前测试。无例外。**
 
+## 让形式匹配失败类型
+
+在写指导内容之前，先给基线失败**归类**。能让某一类失败变得无懈可击的形式，用在另一类上会**可测量地反噬**。
+
+| 基线失败 | 正确的形式 | 错误的形式 |
+|---|---|---|
+| 压力之下跳过/违反规则（明知故犯） | 禁令 + 合理化借口表 + 红线（见下方"让技能经受住合理化的考验"） | 软性建议（"优先……"、"考虑……"） |
+| 遵守了，但产出的**形状**不对（提示词臃肿、结论被埋、复述规格） | 正面配方或契约：直接说明产出**是什么** —— 它由哪些部分组成、按什么顺序 | 禁令清单（"不要复述"、"绝不旁白"） |
+| 在他们**本来就会产出**的东西里漏掉了必需元素 | 结构性手段：在他们要填的模板里放一个 REQUIRED 字段或占位槽 | 在模板附近写散文式提醒 |
+| 行为**应当取决于某个条件** | 挂在可观察谓词上的条件句（"如果简报存在，就引用它"） | 无条件规则 + 一堆例外条款 |
+
+**为什么禁令在"塑形"类问题上会反噬：** 在存在竞争性激励时（比如"让提示词自包含"），智能体会**跟"不要 X"讨价还价**。在针对分派提示词指导做的同题措辞对照测试里，禁令组产出的不想要的内容明显**多于**配方组（两组分布完全分离），甚至比"完全不给指导"的对照组还差 —— 请对你自己的场景做微型测试，别想当然，但**永远不要把禁令当默认选择**。配方留不下可讨价还价的空间：产出要么符合所说的形状，要么不符合。
+
+**无论你选哪种形式，都适用的规则：**
+- **不要加"视情况"从句。** "不要 X，除非它很重要"会重新打开谈判 —— 在同一批措辞测试里，给一个胜出的配方追加**一条**"视情况"从句，就把它从稳定退化成了飘忽。真正的例外要表达成**它自己的**条件句，挂在可观察的谓词上。
+- **豁免条款不会限定作用域。** "这条长度限制不适用于代码块"，照样会压制代码块。如果产出里有一部分必须豁免，就**重构结构让规则碰不到它**，而不是写豁免。
+
 ## 让技能经受住合理化的考验
 
 执行纪律的技能（如 TDD）需要抵抗合理化。智能体很聪明，在压力下会找到漏洞。
@@ -526,7 +543,7 @@ pptx/
 **以上所有都意味着：删除代码。用 TDD 重新开始。**
 ```
 
-### 更新 CSO 以包含违规症状
+### 更新 SDO 以包含违规症状
 
 在描述中添加：你即将违反规则时的症状：
 
@@ -557,6 +574,18 @@ description: use when implementing any feature or bugfix, before writing impleme
 
 智能体找到了新的合理化借口？添加明确的反驳。重新测试直到无懈可击。
 
+### 先做措辞微型测试，再跑完整场景
+
+完整的压力场景是最后一道关卡，但它每轮迭代都又慢又贵。先用**微型测试**验证措辞本身：
+
+1. **每次调用一个全新上下文的样本** —— 一次裸 API 调用，或者没有 API 权限时用一个单发子智能体。system prompt 放**这条指导实际会存在的真实上下文**（完整的 skill 或提示词模板，不是把指导单独拎出来）；user message 放一个会**诱发该失败**的任务。
+2. **永远带一个"不给指导"的对照组。** 如果对照组根本没表现出那个失败，那就没什么可修的 —— 停下，别写这条指导。
+3. **每个变体至少 5 次重复。** 单个样本会骗人。
+4. **每一条被标记的命中都要人工读一遍。** 想用程序打分可以，但模板回声和被引用的反例会**伪装成命中**；只看自动计数会同时高估失败和成功。
+5. **方差本身就是一个指标。** 指导真正生效时，多次重复会收敛到同一种形状。5 次重复出现 5 种不同解读，说明这个措辞**没有约束力** —— 先收紧形式，别急着加字。
+
+微型测试验证的是**措辞**；对纪律执行类技能，它**不能替代**压力场景。
+
 **测试方法论：** 参见 @testing-skills-with-subagents.md 了解完整的测试方法：
 - 如何编写压力场景
 - 压力类型（时间、沉没成本、权威、疲惫）