fix(skills): 定位核查 —— 补回 4 处「不是增量」的对上游偏离

按「我们只是翻译上游 + 增加更多工具支持」这个定位做逐层核查，结果发现
4 处偏离**不属于增量，而是缺失或漏同步**。核查方法与结论都记在下面。

## 核查方法

1. 文件级：上游 skills/ 与我们逐文件比对，分出「仅上游有」「仅我们有」
2. 内容级：14 个翻译 skill 各自比对标题数（排除代码围栏）、表格行数、列表项数
3. 逐个追查每处差异的来源：是声明过的 fork 增量，还是漏译/漏同步

## 修掉的 4 处

① antigravity-tools.md 上游有、我们没有
   而 installer 里明明支持 Antigravity —— 该工具用户拿不到任何工具映射。
   影响是实质的：Antigravity 没有 todo 工具（manage_task 管的是后台进程），
   没这份映射，所有说「创建待办」的 skill 在它上面都会走偏。
   已翻译补入，并在 using-superpowers 的平台适配清单里按上游同序列出。

② finishing-a-development-branch 漏同步 3 个 commit
   C 块时我的 commit 清单不全，漏了 fbb6dba / bcfe798 / 9dff1a9。其中
   9dff1a9 是**行为变更**：上游把菜单从 4 个选项减为 3 个，删掉了「丢弃这份
   工作」这一项，丢弃改为只在人类伙伴明确提出时才走的独立小节；基础分支
   判定也从盲跑 merge-base 改为「先确认，合并到错分支代价很高」。
   我们的文件已把 D 块修复织进旧结构，故照上游当前状态整体重译 ——
   上游 main 已含全部 4 个 commit，一次到位。已断言 D 块修复完整保留
   （WORKTREE_PATH 仅在步骤 2 计算一次 + 那条显式警告）。

③ writing-plans 漏译整节
   上游有 Task Right-Sizing 与 Bite-Sized Task Granularity 两节，我们只有后者。
   缺的那节讲的是任务边界怎么划（能独立承载一轮测试循环、值得一个全新
   审查者把关的最小单元），已补译为「任务粒度定界」。

④ writing-skills 三个问题
   - 漏译 H2 整节 Match the Form to the Failure（让形式匹配失败类型）——
     内容是「哪类基线失败该用哪种形式」，含禁令在塑形类问题上会反噬的实测结论
   - 漏译 H3 Micro-Test Wording Before Full Scenarios（先做措辞微型测试）
   - 编号缺陷：两个连续小节都编号为 4（应为 4、5）
   - 节名仍是过时的「Claude 搜索优化（CSO）」，上游早已改名
     Skill Discovery Optimization (SDO)，正文两处引用一并同步

## 核查后的定位现状

纯增量部分（符合定位）：
- 6 个 fork 专属 skill：chinese-* ×4 + mcp-builder + workflow-runner
- 3 个 fork 专属 references：copilot / hermes / qoder（我们支持的 harness，上游不支持或已删）
- using-superpowers 的「中国特色技能路由」一节

14 个翻译 skill 的标题数现在 13 个与上游精确一致，唯一例外是
using-superpowers（+1，即上面那节声明过的增量）。

## 仍存在、需维护者决定的一处（本提交未动）

executing-plans 有一个 fork 自加的「步骤 3：处理常见异常」（上游只有 3 步，
我们是 4 步），内容是测试失败三分诊断、依赖缺失、指令不清的处理；
另外 Remember 多一条「每个任务单独提交，commit message 引用任务编号」。

这两处是内容层面的自主增补，不在「翻译 + 工具支持」的定位之内。它们本身
有用，但会让每次上游改动该节都要人工调和。留给维护者判断是保留（并在
README 里声明）还是回归上游。

验证：audit.sh 152 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail

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 技能来完成这项工作。"
+**开始时宣告：** "我正在使用 finishing-a-development-branch 技能来收尾这份工作。"
 
-## 流程
+## 步骤 1：验证测试
 
-### 步骤 1：验证测试
+运行项目的完整测试套件（`npm test` / `cargo test` / `pytest` / `go test ./...`）。
 
-**在展示选项之前，验证测试通过：**
-
-```bash
-# 运行项目的测试套件
-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 个选项（无合并） | 无清理（由外部管理） |
+| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 3 个选项 | 无 worktree 可清理 |
+| `GIT_DIR != GIT_COMMON`，命名分支 | 标准 3 个选项 | 按来源判断（见步骤 6） |
+| `GIT_DIR != GIT_COMMON`，分离 HEAD | 收敛为 2 个选项（不含合并） | 由外部管理——原地别动 |
 
-### 步骤 3：确定基础分支
+## 步骤 3：确定基础分支
 
-```bash
-# 尝试常见的基础分支
-git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
-```
+基础分支就是这份工作从哪儿分出来的那个——通常在计划里、对话里，或者分支的 upstream 里已经写明了。如果还不知道，就问："这个分支是从 <你的最佳猜测> 分出来的，对吗？"**合并之前先确认：合并到错误的基础分支，代价很高。**
 
-或者询问："这个分支是从 main 分出来的——对吗？"
+## 步骤 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 反馈继续迭代。
+
+### 选项 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. 丢弃 | - | - | - | ✓（强制） |
+| 1. 本地合并 | 是 | - | - | 是 |
+| 2. 创建 PR | - | 是 | 是 | - |
+| 3. 保持原样 | - | - | 是 | - |
+| 丢弃（仅在明确要求时） | - | - | - | 是（强制） |
 
-## 常见错误
+## 常见的合理化借口
 
-**跳过测试验证**
-
-- **问题：** 合并损坏的代码、创建失败的 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** - 清理由该技能创建的工作树
+| 借口 | 现实 |
+|------|------|
+| "测试这个会话早先通过过" | 在**你即将集成的那棵树上**跑测试套件。一次绿色运行只能证明它当时跑的那棵树。 |
+| "他们显然是想合并的" | 集成是你人类伙伴的决定。把菜单摆出来，然后等。 |
+| "他们看起来对这个功能收工了——我提议丢弃吧" | 菜单就是原文那样，不多不少。丢弃只在你的人类伙伴用明确的话提出时才发生。 |
+| "'嗯，删掉吧'算确认了" | 只有输入 `discard` 这个词才授权删除。 |
+| "PR 已经开了，worktree 现在是碍事的垃圾" | PR 反馈要在那个 worktree 里修。它得留到工作落地为止。 |
+| "另外那个 worktree 看着像过期的——我顺手也清了" | 只清理 `.worktrees/` 或 `worktrees/` 之下的 worktree。其余的都属于宿主环境。 |
+| "合并结果的失败大概是偶发的" | 合并结果失败会让一切停下。在你排查期间，分支和 worktree 原地不动。 |
+| "基础分支明显就是 main" | 确认分叉点，或者直接问。合并到错误的基础分支，代价很高。 |
+| "推送被拒了——force-push 一下就好" | 推送被拒意味着远端动过了。去排查；只有在你人类伙伴明确要求时才 force-push。 |

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`

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]`）。计划有变就更新清单。**保持它是最新的** —— 它是"还剩什么没做"的唯一事实来源；一旦对话变长，每开始一步之前先重读它。

skills/writing-plans/SKILL.md

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

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 了解完整的测试方法：
 - 如何编写压力场景
 - 压力类型（时间、沉没成本、权威、疲惫）