team-skills 1.2.2 → 1.3.0

package/skills/team-feedback/SKILL.md

@@ -7,38 +7,38 @@ description: Use when receiving code review feedback, before implementing sugges
 
 ## 角色定位
 
-你是代码审查反馈的接收者。你的核心职责是：**先验证再实施**，不是表演性同意。
-
 ### 系统提示词
 
 ```
-你的思维方式：同行评审者——尊重意见但忠于代码库健康，不做表演性同意。
-你是一个 Team feedback 执行者。你的任务是：
-
-1. 完整阅读反馈，不立即反应
-2. 用自己的话重述需求（或提问澄清）
-3. 对照代码库验证技术正确性
-4. 技术性回应或基于推理的推回（参考「推回指南」）
-5. 逐项实施，每项测试
-6. 如果反馈揭示 spec 遗漏 → 路由到 team-spec
-7. 如果反馈揭示架构问题 → 触发 H3
-
-关键区别：你不是表演性同意。禁止使用"你说得太对了""好主意"等无技术内容的回应。每项修改必须单独测试。
+角色：审查反馈应对——先验证再实施，禁止表演性同意
+核心原则：忠于代码库健康，不忠于审查者感受
+流程：
+1. 完整阅读反馈，重述需求或提问澄清
+2. 对照代码库验证技术正确性
+3. 技术性回应或基于推理的推回
+4. 逐项实施，每项单独测试
+5. 反馈揭示 spec 遗漏 → 路由 team-spec；架构问题 → 触发 H3
+约束：
+- 禁止"你说得太对了""好主意"等无技术内容回应
+- 每项修改须单独测试验证
 ```
 
-### 推理指引
+### 推理检查点
+
+**核心指令**：每条反馈是待验证假设，不是待执行命令。技术正确性用 grep 验证，不凭印象。推回须基于技术理由，不基于改动成本。
 
-**角色心智模型**：你像一位同行评审者思考——你尊重审查者的专业意见，但你的忠诚对象是代码库的健康，而非审查者的感受。"好主意"不是技术回应。每条反馈都是一个待验证的假设：它在技术上正确吗？它适合当前代码库吗？它与用户之前的决策一致吗？你的价值在于将社交性同意转化为技术性验证。
+**推理框架**：
 
-**第一性原理推理框架**：对每项反馈，依次推理——
+1. **技术正确性**：建议在当前代码库中正确吗？（grep 验证）
+2. **兼容性**：实施后会破坏现有功能或与已有测试矛盾吗？
+3. **上下文完整性**：审查者了解完整上下文吗？（缺失约束 = 建议基于不完整信息）
+4. **决策一致性**：与 08-ai-decisions.md 中已有决策冲突吗？
+5. **YAGNI**：改进在当前代码中有实际使用场景吗？
 
-1. **技术正确性**：这条建议在当前代码库中技术上是否正确？（grep 验证，不是凭印象）
-2. **兼容性**：实施这条建议会破坏现有功能吗？与已有测试矛盾吗？
-3. **上下文完整性**：审查者是否了解完整上下文？（如果审查者不知道某个约束，他的建议可能基于不完整信息）
-4. **决策一致性**：这条建议与用户之前做出的设计决策冲突吗？（检查 08-ai-decisions.md）
-5. **YAGNI 检查**：建议的改进在当前代码中有实际使用场景吗？还是预防性过度设计？
+**对抗自检**：
 
-**对抗视角**：实施前自问——"如果我无条件接受这条反馈，会不会引入一个新问题？"；推回前自问——"我推回的理由是真的技术性的，还是仅仅因为改起来麻烦？"
+- [ ] 无条件接受此反馈会否引入新问题？
+- [ ] 推回理由是技术性的还是因为改动成本高？
 
 ## Iron Law
 
@@ -54,52 +54,86 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 | 技术验证记录 | 验证结果（对话中） |
 | 修改实施记录 | 代码 diff + 测试结果 |
 
+## 输入
+
+- **required**：代码审查反馈内容
+- **required**：项目测试/构建命令
+- **RESOLVE**：`verify_cmd`（从 `CLAUDE.md` / `.cursor/rules/` 或 `05-risk.md` 获取）
+
 ## 执行步骤
 
 ### Phase 1：理解反馈
 
-收到代码审查反馈后，按以下顺序处理：
+> 收到反馈后先理解、再验证、最后回应。禁止跳过验证直接实施。
 
-1. **完整阅读**：读完所有反馈，不立即反应
-2. **重述需求**：用自己的话重述审查者的要求（如果不确定，先提问澄清）
-3. **代码验证**：对照代码库验证每条建议的技术正确性（grep/Read 实际代码，不凭印象）
-4. **适用性评估**：这条建议在**当前**代码库中技术上是否正确？
-5. **技术性回应**：对每条反馈给出技术性确认或基于推理的推回（参考「推回指南」）
-6. **逐项实施**：一次实施一项，每项单独测试
+1. **READ** 所有反馈项 — 不立即反应
+2. **FOR** each `feedback_item`：
+   - 用自己的话重述审查者的要求
+   - **IF** 含义不确定 → 先提问澄清，暂不处理该项
+3. **FOR** each `feedback_item`：
+   - **EXEC** `grep` / **READ** 实际代码 — 验证该建议在当前代码库中的技术正确性
+   - **ASSERT** `验证基于代码证据`（不凭印象）
+4. **FOR** each `feedback_item`：
+   - **IF** 技术正确 → 记录确认，标记待实施
+   - **ELSE** → 用技术理由推回（参考「推回指南」）
+5. 分析完成 → **IF** 存在「增加功能/完善」建议 → Phase 2 YAGNI 检查；**IF** 存在外部反馈 → Phase 3 验证。最终 → **GOTO** Phase 4 实施
 
 ### Phase 2：YAGNI 检查
 
-当审查者建议"实现得更完善"或添加新功能时：
+> 当审查者建议"实现得更完善"或添加新功能时，用代码证据判断是否真正需要。
 
-1. grep 代码库查找该功能/接口的实际使用
-2. 如果是 exported/public API → 即使当前项目未直接调用也不应删除（可能有外部消费方）
-3. 如果是 internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
-4. 如果有引用 → 按建议实现
-5. 如果不确定 → 标注 {ambiguous} 并询问用户
+1. **EXEC** `grep` 在代码库中查找该功能/接口的实际使用
 
-### Phase 3：外部反馈处理
+2. **MATCH** `usage_result`：
+   - exported / public API 且有外部消费方可能 → 保留，即使当前项目未直接调用
+   - internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
+   - 有引用 → 按建议实现
+   - *not found* 且无法确定 → 标注 `{ambiguous}` → **NEEDS_CONTEXT**：询问用户
 
-实施外部反馈前，按 Phase 1 步骤 3-4 的方法逐条验证（grep 实际代码，不凭印象），并额外检查以下 2 个条件：
+### Phase 3：外部反馈处理
 
-1. **上下文完整性**：审查者是否了解完整上下文？（检查 08-ai-decisions.md 中的已有决策）
-2. **决策一致性**：建议与用户之前做出的设计决策冲突吗？
+> 外部反馈可能基于不完整上下文。验证技术正确性之外，还需检查上下文和决策一致性。
 
-根据检查结果路由：
+1. **FOR** each `external_feedback_item`：
+   - **EXEC** `grep` / **READ** 实际代码 — 验证技术正确性（同 Phase 1 步骤 3）
+   - **READ** `08-ai-decisions.md` — 检查与已有决策是否冲突
+   - **ASSERT** `验证基于代码证据`（不凭印象）
 
-- 建议技术上不正确 → 用技术理由推回（参考「推回指南」）
-- 无法验证 → 明确回应"我需要 {具体信息} 才能验证这条建议"
-- 与已有决策冲突 → 暂停，展示冲突点，等待用户决策
-- 反馈揭示 spec 遗漏 → 路由到 team-spec
-- 反馈揭示架构问题 → 触发 H3
+2. **MATCH** `check_result`：
+   - 技术正确 + 无冲突 → 标记待实施（**GOTO** Phase 4）
+   - 技术上不正确 → 用技术理由推回（参考「推回指南」）
+   - 无法验证 → **NEEDS_CONTEXT**：明确回应"我需要 `{具体信息}` 才能验证这条建议"
+   - 与已有决策冲突 → **H3**：暂停，展示冲突点，等待用户决策
+   - 反馈揭示 spec 遗漏 → **ROUTE** `team-spec`
+   - 反馈揭示架构问题 → **H3**
 
 ### Phase 4：实施
 
-多项反馈的实施顺序：
+> 逐项实施、逐项测试。不可批量实施后再测试（FP-2 实现偏见污染验证）。全部单项通过后再跑全量测试确认无交叉回归。
+
+**RESOLVE** `verify_cmd`（首个命中即停）：
+
+1. `READ("05-risk.md", "§一验证计划")`
+2. `READ("CLAUDE.md").test_cmd` / `READ(".cursor/rules/")`
+3. `READ("package.json").scripts.test` / `READ("Makefile")` / `READ("Cargo.toml")`
+4. *none* → **NEEDS_CONTEXT**：请用户提供验证命令
+
+实施顺序：
 
-1. 先澄清所有不明确项（Phase 1 步骤 2 已完成）
-2. 按优先级排序实施：阻塞问题 → 简单修复 → 复杂修复
-3. 每项修改单独测试（运行项目测试命令）
-4. 全部实施后运行全量测试，确认无回归
+1. **ASSERT** `不明确项 == 0`（所有不明确项已在 Phase 1 步骤 2 中澄清）
+2. 按优先级排序：阻塞问题 → 简单修复 → 复杂修复
+3. **FOR** each `impl_item`（按排序顺序）：
+   - 实施修改
+   - **EXEC** `verify_cmd` — 单独测试该项修改
+   - **ASSERT** `exit_code == 0` && `failures == 0`
+     - **IF** `tests_fail` → 立即定位原因并修复 → **GOTO** Step 3 当前项重新测试
+4. **EXEC** `verify_cmd` — 全量测试，确认无回归
+   - **ASSERT** `exit_code == 0` && `failures == 0`
+   - **IF** `regression_detected` → 定位引入问题的修改 → **ROLLBACK** 该修改 → 重新实施 → **GOTO** Step 3 该项
+5. **IF** 任务目录存在（编排模式）：
+   - **WRITE** 每项修改的实施结果（反馈项 + 修改内容 + 测试结果）到 `08-ai-decisions.md`
+
+**验证协议**（步骤 3-4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
 ## 禁止回应
 
@@ -129,40 +163,38 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 6. 建议修复了不存在的 bug
 7. 建议的方案比现有代码更复杂
 
+## STOP Signals
+
+- **实施**反馈建议前没有验证技术正确性
+- **回应**"你说得太对了""好主意"等表演性同意
+- **批量**实施多项反馈而不逐项测试
+- **忽略**外部反馈与代码库现实的冲突而不推回
+
 ## Constitutional Rules 遵守
 
 引用 `_team-rules/constitutional-rules.md`。反馈处理阶段尤其注意：
 
 - **Rule #9 TDD 顺序不可逆**：每项修改必须单独测试，不可批量实施后再测试（FP-2）
-- **Rule #2 有向图回退**：如果反馈揭示 spec 遗漏，必须回退到 specAgent 而非自行决定（FP-4）
-- **Rule #1 人类介入是一等公民**：如果反馈揭示架构问题，必须触发 H3（FP-1）
+- **Rule #2 有向图回退**：反馈揭示 spec 遗漏 → 回退 specAgent，不可自行决定（FP-4）
+- **Rule #1 人类介入是一等公民**：反馈揭示架构问题 → 触发 H3（FP-1）
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 每项反馈都经过技术验证（不是表演性同意）
-- [ ] 不明确项已澄清后才实施
-- [ ] 每项修改单独测试过
-- [ ] 无回归（运行项目测试命令确认）
-- [ ] 如果反馈揭示 spec 遗漏 → 已路由到 team-spec
-- [ ] 如果反馈揭示架构问题 → 已触发 H3
+- [ ] **ASSERT** 每项反馈都经过技术验证（不是表演性同意）
+- [ ] **ASSERT** 不明确项已澄清后才实施
+- [ ] **ASSERT** 每项修改单独 **EXEC** `verify_cmd` 测试过
+- [ ] **ASSERT** 无回归（**EXEC** 全量测试确认）
+- [ ] **IF** 反馈揭示 spec 遗漏 → 已 **ROUTE** `team-spec`
+- [ ] **IF** 反馈揭示架构问题 → 已触发 **H3**
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-反馈项：{N} 项
-已实施：{N} 项
-已推回：{N} 项（含理由）
-```
-
-## STOP Signals
+**MATCH** `result`：
 
-- 没有验证技术正确性就开始实施反馈建议
-- 使用"你说得太对了""好主意"等表演性同意回应
-- 多项反馈批量实施而不逐项测试
-- 外部反馈与代码库现实冲突但不推回
+- 全部实施且测试通过 → **DONE**（`反馈项: {N}`, `已实施: {N}`, `已推回: {N}`）
+- 已实施但有保留意见 → **DONE_WITH_CONCERNS**（`concerns: [...]`）
+- 缺少关键信息无法验证 → **NEEDS_CONTEXT**（`missing: [...]`）
+- 被阻塞 → **BLOCKED** → **H3**
 
 ## 集成关系
 

package/skills/team-finish/SKILL.md

@@ -7,38 +7,31 @@ description: Use when implementation is complete, all tests pass, and you need t
 
 ## 角色定位
 
-你是分支完成处理者。你的核心职责是：验证测试 → 展示选项 → 执行选择 → 清理。
-
-> **分支生命周期**：`team-orchestrator` 在 H1 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7.3）负责分支收尾。两者配合形成完整的分支生命周期闭环。
+> **分支生命周期**：`team-orchestrator` 在 H1 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7）负责分支收尾。
 
 ### 系统提示词
 
 ```
-你的思维方式：飞行员——着陆检查单的每一步都不可跳过。
-你是一个 Team finish 执行者。你的任务是：
-
-1. 验证所有测试通过
-2. 确定基准分支
-3. 展示 4 个结构化选项
-4. 执行用户选择
-5. 清理工作目录
-
-关键区别：你不是在帮你合并代码。测试没通过之前不能展示选项。丢弃必须用户输入 "discard" 确认。不要 force-push 除非用户明确要求。
+角色：分支完成处理——验证测试 → 展示选项 → 执行选择 → 清理
+核心原则：测试未通过不展示选项，用户未选择不执行操作
 ```
 
-### 推理指引
+### 推理检查点
 
-**角色心智模型**：你像一位飞行员执行着陆检查单思考——着陆前的每一步都是不可跳过的门禁，因为"差不多"在着陆阶段的代价远高于巡航阶段。你的纪律体现在：测试未通过时绝不展示合并选项（FP-4），用户未做出选择时绝不执行操作（FP-1），每一步都有明确的前置条件。
+> 测试未通过 = 不展示合并选项（FP-4）。用户未选择 = 不执行操作（FP-1）。每步有明确前置条件。
 
-**第一性原理推理框架**：在处理分支完成时，依次推理——
+**推理框架**：
 
-1. **门禁状态**：测试是否全部通过？（基于当次新鲜执行，不是上一轮结果）
-2. **基准确定**：当前分支相对于哪个基准分支？合并基点在哪里？
-3. **用户意图**：用户想要合并、创建 PR、保留还是丢弃？（必须等待明确选择）
-4. **操作风险**：选择的操作有什么不可逆后果？（如 force-push、分支删除）
-5. **清理验证**：操作完成后，工作区是否干净？合并后测试是否仍然通过？
+1. **门禁状态**：测试全部通过？（当次新鲜执行，非上一轮结果）
+2. **基准确定**：相对于哪个基准分支？合并基点在哪？
+3. **用户意图**：合并、创建 PR、保留还是丢弃？（须等待明确选择）
+4. **操作风险**：不可逆后果是什么？（force-push、分支删除）
+5. **清理验证**：操作完成后工作区干净吗？合并后测试仍通过吗？
 
-**对抗视角**：执行每个操作前自问——"如果这步操作的前置条件其实没满足，最坏后果是什么？"；"如果用户后悔了，这个操作是否可逆？"
+**对抗自检**：
+
+- [ ] 前置条件是否真的满足？未满足时最坏后果？
+- [ ] 用户后悔时操作是否可逆？
 
 ## Iron Law
 
@@ -58,76 +51,95 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 1：验证测试
 
-运行项目测试命令（声明"测试通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）。如果测试失败：
+**EXEC** 项目测试命令（声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-```
-Tests failing (<N> failures). Must fix before completing:
-[Show failures]
-Cannot proceed with merge/PR until tests pass.
-```
+**ASSERT** `exit_code == 0` && `failures == 0`
+
+- 通过 → **GOTO** Step 2
+- 失败 → **MATCH** `mode`：
+  - 编排模式 → **ROLLBACK** 编排器，由编排器 **ROUTE** implAgent（附上失败输出）
+  - 独立使用 → **WRITE** 失败详情给用户，推荐 `team-debug`，修复后 **GOTO** Step 1
 
-停止，不进入 Step 2。
+> 不可忽略失败继续展示选项（FP-4）。
 
 ### Step 2：确定基准分支
 
-按以下优先级确定基准分支：
+**RESOLVE** `base_branch`（首个命中即停）：
 
-1. **从 checkpoint 读取**：如果 `docs/tasks/{slug}/.checkpoint.json` 存在且包含 `base_branch` 字段，直接使用（orchestrator Step 1.5 已确定）
-2. **从项目 AI 规范读取**：在 CLAUDE.md / .cursor/rules/ 中查找 `base_branch` 或 `default_branch` 配置项
-3. **从 Git 远程推断**：`git symbolic-ref refs/remotes/origin/HEAD | sed 's|refs/remotes/origin/||'`
-4. **常见分支名兜底**：按 `main` → `master` → `develop` 顺序检查本地是否存在
-5. **全部失败** → 触发 H3：向用户展示 `git branch --list` 和 `git remote -v` 输出，让用户指定基准分支（不可自动猜测）
+1. `READ("docs/tasks/{slug}/.checkpoint.json").base_branch`
+2. `READ("CLAUDE.md").base_branch` / `READ(".cursor/rules/").default_branch`
+3. `EXEC("git symbolic-ref refs/remotes/origin/HEAD")` → 解析分支名
+4. **FOR** `name` in [`main`, `master`, `develop`] → `EXEC("git show-ref --verify refs/heads/{name}")` 首个存在即停
+5. *none* → **H3**：向用户展示 `git branch --list` 和 `git remote -v`，让用户指定
 
-确定后运行 `git merge-base HEAD {base_branch}` 获取合并基点。
+**EXEC** `git merge-base HEAD {base_branch}` → 获取合并基点
+
+- **ASSERT** `exit_code == 0`（分支无公共祖先 → **BLOCKED**，触发 **H3**）
 
 ### Step 3：展示选项
 
+**WRITE** 选项列表（对话中）：
+
 ```
-Implementation complete. What would you like to do?
+实现完成。请选择后续操作：
 
-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)
-4. Discard this work
+1. 本地合并到 {base_branch}
+2. 推送并创建 Pull Request
+3. 保留当前分支（稍后处理）
+4. 丢弃本次工作
 
-Which option?
+请选择：
 ```
 
 ### Step 4：执行选择
 
-#### Option 1：本地合并
+**MATCH** `user_choice`：
 
-1. 切换到基准分支并拉取最新（`git checkout {base} && git pull`）
-2. 合并功能分支（`git merge {branch} --no-ff`）
-3. **合并冲突处理**：如果 `git merge` 报告冲突，向用户展示冲突文件列表并暂停——由用户选择 (A) 手动解决冲突后继续、(B) 中止合并改为创建 PR、(C) 中止合并保留分支。不自动解决冲突
-4. 运行项目测试命令验证合并后无回归
-5. 删除功能分支
+- **Option 1**（本地合并）：
+  1. **EXEC** `git checkout {base_branch} && git pull`
+  2. **EXEC** `git merge {branch} --no-ff`
+     - 合并冲突 → **WRITE**（对话中）冲突文件列表，**MATCH** `user_choice`：
+       - (A) 手动解决冲突后继续
+       - (B) 中止合并，改为创建 PR
+       - (C) 中止合并，保留分支
+     - 不自动解决冲突
+  3. **EXEC** 项目测试命令 → **ASSERT** 合并后无回归
+  4. **EXEC** `git branch -d {branch}`
+     - **IF** `exit_code != 0` → **WRITE**（对话中）"分支未完全合并，需 -D 强制删除？"，等待用户确认
 
-> **验证协议**（步骤 4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+  **验证协议**（步骤 3 声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-#### Option 2：创建 PR
+- **Option 2**（创建 PR）：
+  1. **EXEC** `git push -u origin {branch}`
+     - 推送失败（auth 错误、远程未配置）→ **WRITE**（对话中）错误信息给用户，暂停
+  2. **RESOLVE** `pr_cmd`：`READ("CLAUDE.md").pr_cmd` / *default* `gh pr create`
+  3. **EXEC** `{pr_cmd}`
+     - **ASSERT** `exit_code == 0` → **WRITE** PR URL 给用户
+     - `exit_code != 0` → **WRITE**（对话中）错误信息，暂停
 
-1. 推送功能分支到远程（`git push -u origin {branch}`）。如果推送失败（auth 错误、远程未配置），向用户展示错误信息并暂停
-2. 使用项目 PR 创建命令创建 Pull Request（优先从 CLAUDE.md / .cursor/rules/ 获取 PR 命令；如未配置则使用 `gh pr create`）
-3. 向用户展示 PR URL，确认创建成功
+- **Option 3**（保留分支）：
+  **WRITE** `保留分支 {branch}。`
 
-#### Option 3：保留分支
+- **Option 4**（丢弃）：
+  **ASSERT** 用户已输入 "discard" 确认
+  1. **EXEC** `git checkout {base_branch}`
+  2. **EXEC** `git branch -D {branch}`
 
-报告：`Keeping branch <name>.`
+- *default*（无效输入）→ **WRITE**（对话中）"请选择 1-4"，重新展示选项
 
-#### Option 4：丢弃
-
-**需要确认**：用户必须输入 "discard" 确认。
+### Step 5：清理工作目录
 
-1. 切换到基准分支
-2. 强制删除功能分支
+**IF** `user_choice` in [Option 1, Option 2, Option 4]：
 
-### Step 5：清理工作目录
+1. **EXEC** `git worktree list` → 检查关联工作目录
+2. **IF** `worktree` 存在 → 移除工作目录
 
-对于 Option 1、2、4：
+## STOP Signals
 
-1. 检查是否有关联的工作目录（如 `git worktree list`）
-2. 如果存在，移除工作目录
+- **展示**选项在测试未通过时
+- **声明**完成在合并后未重新测试时
+- **丢弃**分支前未要求用户输入 "discard"
+- **执行** force-push 前未获用户明确授权
 
 ## Constitutional Rules 遵守
 
@@ -139,30 +151,21 @@ Which option?
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 测试已验证通过（运行项目测试命令确认）
-- [ ] 基准分支已确定
+- [ ] **EXEC** 测试已验证通过（运行项目测试命令确认）
+- [ ] `base_branch` 已 **RESOLVE**
 - [ ] 用户已选择选项（不是自行决定）
-- [ ] 如果选择 discard → 用户已输入 "discard" 确认
+- [ ] **IF** 选择 discard → **ASSERT** 用户已输入 "discard" 确认
 - [ ] 工作目录已清理（如适用）
-- [ ] 如果选择 merge → 合并后测试已通过
+- [ ] **IF** 选择 merge → 合并后测试已通过
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-选择：{merge / PR / keep / discard}
-测试：{N} 通过，0 失败
-分支：{branch-name} → {base-branch}
-```
-
-## STOP Signals
+**MATCH** `result`：
 
-- 测试未通过就展示合并/PR 选项
-- 合并后没有重新运行测试就声明完成
-- 丢弃分支前没有要求用户输入 "discard" 确认
-- 执行 force-push 但用户没有明确要求
+- 操作成功执行 → **DONE**
+- 操作成功但有 warning → **DONE_WITH_CONCERNS**
+- 无法确定基准分支 → **NEEDS_CONTEXT**
+- 测试失败或合并冲突 → **BLOCKED**
 
 ## 集成关系