mirror of https://github.com/jnMetaCode/superpowers-zh.git synced 2026-09-02 22:54:06 +08:00

Files

AI不止语 02d255102c refactor(skills): 同步上游 C 块 —— 说服性段落改为 rationalization 表（#19 收尾）

对齐上游 14 个 refactor commit 中尚未同步的 11 个（另 3 个已随 A/B 块完成）。
audit 上游结构漂移告警由此清零：150 pass / 0 warn / 0 fail。

## 盘点先行：不是所有改动都是风格性的

C 块开工前做了逐 commit 盘点，判定标准定为「删掉的文字里有没有别处没写的
规则」。结论纠正了我之前的假设 —— 其中 3 项是实质改动，不是纯瘦身：

- cfb6281 新增了一张 rationalization 表（2 行全新规则），替换掉
  「与工作流的集成」那份工作流清单
- 03147d2 给 executing-plans 加了「先确保隔离工作区」作为步骤 1
  （SDD 那一半已随 A 块完成）
- bc86802 把「常见错误」5 个小节 + 「红线」Never/Always 双清单压成 5 行表，
  规则一条不少 —— 这也是此前唯一有客观漂移证据的 skill

## 逐项核实后才删

每处删除都先确认规则在别处仍在：
- receiving-code-review「底线」：概述已有「核心原则：先验证再实施。先提问再假设」
- writing-skills「总结」：铁律节 + TDD 循环表已完整承载
- writing-plans「注意事项」：精确路径 / Run: / 预期输出 三条都内建在任务结构
  模板里 —— 上游是把「告知」改成「示范」
- brainstorming「核心原则」6 条：5 条已在流程详述里逐条体现（每次一个问题、
  优先选择题、2-3 种方案、增量验证、回头澄清），YAGNI 按上游移到「探索方案」
  的使用现场
- systematic-debugging / dispatching-parallel-agents / verification-before-completion
  删的是「实际效果」「核心优势」「为什么这很重要」这类社会证明与说服段，
  核心原则行全部保留
- systematic-debugging 的「相关技能」块折入第四阶段「验证修复」
- executing-plans 删掉的质量宣称按上游改写为平铺的平台清单

## 验证

结构
- 10 个 skill 的 H2 数与上游逐一对齐（8 个完全相同、2 个差 1）
- executing-plans / using-git-worktrees / requesting-code-review 的
  superpowers: 引用集与上游完全一致

行为 eval —— 两轮共 11 题全对
专门考被删段落里的规则是否仍生效：
- 原生 worktree 工具 vs git worktree add（答出「第一大错误」与「幽灵状态」）
- 跳过 check-ignore 的后果、目录名优先级顺序
- 基线测试失败能否继续、能否无证据宣称完成
- 审查建议技术上有疑问时该照做还是反驳
- 能否先打补丁再查根因
- 能否自己读 diff 代替派审查者（命中 cfb6281 新增的表行）
- 方案里的「以后可能用得上」功能怎么处理（命中 YAGNI 的新落点）

回归：audit.sh 150 pass / 0 warn / 0 fail、verify-release.sh 82 pass / 0 fail

注：audit PASS 由 152 降至 150 —— 上游有意删除的两个「集成」节里各有
superpowers: 引用，Category 4b 因此少 2 项检查；引用集已核对与上游一致。

2026-08-08 00:21:39 +08:00

5.5 KiB

Raw Blame History

name, description, version, license, metadata

name

description

version

license

metadata

executing-plans

当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用

1.0.0

MIT

hermes

执行计划

概述

加载计划，批判性审查，执行所有任务，完成后报告。

开始时宣布： "我正在使用 executing-plans 技能来实现此计划。"

注意： 告诉你的人类伙伴，Superpowers 在有子代理支持时效果好得多（Claude Code、Codex CLI、Codex App、Copilot CLI 与 Gemini CLI 都算；见 ../using-superpowers/references/ 下的各平台工具参考）。如果子代理可用，请使用 superpowers:subagent-driven-development 而非此技能。

流程

步骤 1：加载并审查计划

确保有一个隔离的工作区：用 superpowers:using-git-worktrees 创建一个，或者核实已有的那个
读取计划文件
批判性审查——识别计划中的任何问题或疑虑
如果有疑虑：在开始之前向你的人类伙伴提出
如果没有疑虑：创建 TodoWrite 并继续

审查时重点检查：

步骤之间是否有依赖遗漏？（A 依赖 B，但 B 排在 A 之后）
验证条件是否明确？（"确认可用"不算，"运行 npm test 全部通过"才算）
是否有隐含的环境假设？（Node 版本、数据库连接、API Key）

审查示例：

计划文件：docs/plan.md
任务清单：5 个任务

审查发现：
- 任务 3（添加数据库迁移）应在任务 2（编写数据模型）之后，顺序正确 ✓
- 任务 4 的验证条件写的是"确认功能正常"→ 需澄清：具体跑什么测试？
- 计划未提及 Python 版本要求 → 需确认

向伙伴提出：
"计划整体可执行。有两个问题：(1) 任务 4 的验证条件不够具体，建议改为
'运行 pytest tests/test_api.py 全部通过'；(2) 需要确认 Python 版本要求。"

步骤 2：执行任务

对于每个任务：

标记为进行中 — 更新 TodoWrite
理解目标 — 重读任务描述，明确完成标准
执行实现 — 严格按照计划步骤执行（计划已有小步骤）
运行验证 — 按要求运行测试或检查
提交变更 — 每完成一个任务提交一次，commit message 引用任务编号
标记为已完成 — 更新 TodoWrite

每个任务的节奏：

--- 任务 2/5：添加用户验证 ---
[标记进行中]

目标：为 /api/users 添加输入验证
完成标准：所有验证测试通过，无效输入返回 400

[实现]
- 添加 validateUser() 中间件
- 编写 3 个验证规则（email 格式、密码强度、用户名长度）

[验证]
$ npm test -- --grep "validation"
  ✓ 拒绝无效 email (12ms)
  ✓ 拒绝弱密码 (8ms)
  ✓ 拒绝过长用户名 (5ms)
  3 passing

[提交]
$ git add src/middleware/validate.js tests/validation.test.js
$ git commit -m "feat: 添加用户输入验证（任务 2/5）"

[标记完成]
--- 任务 2/5 完成 ---

持续自查：

执行过程中持续留意：整体方向还对吗？有没有偏离计划？
如果发现前面的实现有问题，先修复再继续，不要带着问题往下走

步骤 3：处理常见异常

测试失败：

读错误信息，定位失败原因
区分：是实现 bug？还是测试本身有问题？还是计划描述有误？
实现 bug → 修复并重跑
测试有问题 → 修复测试，向伙伴说明
计划有误 → 停下来，向伙伴报告并建议修正

依赖缺失：

任务 3 需要 Redis 连接，但计划中没有提及 Redis 配置。
→ 停止执行
→ 向伙伴报告："任务 3 需要 Redis，计划中未包含配置步骤。
   建议：在任务 3 前插入 '配置 Redis 连接' 步骤。"

指令不清：

不要猜测意图，不要"合理推断"
列出你的理解和困惑，让伙伴澄清
等待回复后再继续

步骤 4：完成开发

所有任务完成并验证后：

宣布："我正在使用 finishing-a-development-branch 技能来完成此工作。"
必需子技能： 使用 superpowers:finishing-a-development-branch
按照该技能的指引验证测试、展示选项、执行选择

完成报告模板：

## 执行报告

**计划：** docs/plan.md
**分支：** feature/user-validation
**任务：** 5/5 已完成

### 完成的任务
1. ✅ 初始化项目结构
2. ✅ 添加用户验证
3. ✅ 添加数据库迁移
4. ✅ 实现 API 端点
5. ✅ 添加集成测试

### 验证结果
- 单元测试：23/23 通过
- 集成测试：8/8 通过
- lint 检查：0 个警告

### 偏离计划的地方
- 任务 3：Redis 配置从 env 改为 config.yaml（经伙伴同意）

### 下一步
按 finishing-a-development-branch 技能处理合并/PR

何时停下来求助

在以下情况立即停止执行：

遇到阻塞（缺少依赖、测试失败、指令不清）
计划有严重缺陷导致无法开始
你不理解某条指令
验证反复失败（同一测试失败 2 次以上）

不确定时就问，不要猜测。

何时回到之前的步骤

回到审查（步骤 1）当：

伙伴根据你的反馈更新了计划
根本性的方案需要重新考虑

不要硬闯阻塞 — 停下来问。

注意事项

先批判性审查计划
严格按照计划步骤执行
不要跳过验证
每个任务单独提交，commit message 引用任务编号
计划要求时引用相应技能
遇到阻塞时停下来，不要猜测
未经用户明确同意，绝不在 main/master 分支上开始实现

5.5 KiB Raw Blame History Unescape Escape