@specpow/framework 0.5.10 → 0.5.11

package/.specpow/skills/execution-subagent-driven-dev/SKILL.md

@@ -1,143 +0,0 @@
----
-name: execution-subagent-driven-dev
-description: 子代理驱动开发(SDD)。通过分发新鲜子代理执行每个任务，每个任务后进行审查，最后进行全分支审查。来自 Superpowers 的核心执行引擎。
----
-
-# 子代理驱动开发(SDD)
-
-通过为每个任务分发一个全新的实现者子代理来执行计划，每个任务后进行任务审查（规范合规 + 代码质量），最后进行全分支审查。
-
-**为什么用子代理：** 你将任务委托给具有隔离上下文的专门代理。通过精确构建它们的指令和上下文，你确保它们保持专注并成功完成任务。它们不应该继承你会话的上下文或历史 — 你构建它们需要的一切。这也保护了你自己的上下文用于协调工作。
-
-**核心原则：** 每任务新鲜子代理 + 任务审查（规范 + 质量）+ 宽泛最终审查 = 高质量、快速迭代
-
-## 何时使用
-
-- 有实现计划？
-- 任务大多独立？
-- 想在当前会话中完成？
-
-如果都是 yes → 使用此技能。
-
-## 流程
-
-### 设置
-
-1. 确保工作在隔离工作区中（使用 `git-worktrees` 技能）
-2. 解析工作区目录：`scripts/sdd-workspace PLAN_FILE`
-3. 检查账本（`<workspace>/progress.md`）
-4. 读取计划一次，为每个任务创建 todo
-5. 扫描计划中的冲突（任务间矛盾、与全局约束矛盾）
-
-### 任务循环
-
-对每个任务：
-
-#### 1. 分发实现者
-记录 BASE commit（`git rev-parse HEAD`）。
-- **任务简报：** 运行 `scripts/task-brief PLAN_FILE N`
-- **报告文件名：** 与简报同名（`task-N-report.md`）
-- **分发 prompt 包含：**
-  1. 一行项目背景
-  2. 简报路径（"先读这个"）
-  3. 来自前置任务的接口信息
-  4. 你对歧义的解读
-  5. 报告文件路径和报告契约
-
-**绝不**让子代理读取整个计划文件。
-**绝不**分发多个实现子代理并行（会冲突）。
-
-#### 2. 处理报告
-
-实现者报告四种状态之一：
-- **DONE:** 生成审查包，分发审查者
-- **DONE_WITH_CONCERNS:** 先读取疑虑，如果是正确性问题则先处理
-- **NEEDS_CONTEXT:** 提供缺失上下文，重新分发
-- **BLOCKED:** 评估阻塞原因，可能需要更强模型或拆分任务
-
-#### 3. 审查任务
-
-- 运行 `scripts/review-package PLAN_FILE BASE HEAD`
-- 分发任务审查子代理
-- 审查者输入：简报 + 报告 + 审查包 + 全局约束
-- 审查者输出：规范合规 ✓/✗ + 质量通过/不通过 + 发现列表
-
-**绝不跳过任务审查。实现者自审不能替代任务审查。**
-
-#### 4. 修复循环
-
-触发条件：规范 ❌、Critical/Important 发现、或确认有 ⚠️ 项。
-
-**Rounds 1-3 — 恢复原始实现者：**
-发送开放发现原文。它的上下文完整。
-
-**Rounds 4-5 — 分发全新实现者，使用更强模型：**
-"A prior implementer attempted this task N times; you own it now."
-
-每轮：
-1. 实现者修复 + 重新运行测试 + 追加修复报告
-2. 运行 `scripts/review-package PLAN_FILE FIX_BASE HEAD`
-3. 分发范围限定的重新审查
-4. 重新审查者裁定每个发现：ADDRESSED 或 NOT ADDRESSED
-5. 记录到账本
-
-#### 5. 断路器（5 轮后）
-停止分发。自己裁定每个开放发现：
-
-- **审查者误报/有争议：** 停放 → `Task N: parked — <finding> — ruling: <why>`
-- **真实但无下游依赖：** 停放，注明延迟
-- **真实且承重：** STOP。`Task N: BLOCKED — <reason>`。报告给用户。
-
-**只在顶部裁定。提前裁定是用不同名字预先判断。**
-
-#### 6. 完成任务
-
-审查干净后（或所有开放发现都已停放）：
-- 追加完成行到账本
-- 标记 todo 完成
-- 继续下一任务
-
-### 最终审查
-所有任务完成后：
-1. 运行 `scripts/review-package PLAN_FILE MERGE_BASE HEAD`
-2. 分发最终审查（使用最强模型）
-3. 如果有发现，分发一个修复子代理（不是每个发现一个）
-4. 然后一次范围限定的重新审查
-5. 裁定剩余发现
-
-### 完成
-
-1. 删除工作区（`rm -rf <workspace>`）
-2. 使用 `finish-branch` 技能
-
-## 模型选择
-
-| 任务类型 | 模型级别 |
-|----------|----------|
-| 机械实现（1-2文件，完整规范） | cheap |
-| 集成和判断（多文件协调） | standard |
-| 架构和设计 | capable |
-| 最终审查 | capable（总是） |
-| 修复轮次 4-5 | 至少比卡住的实现者高一级 |
-
-**总是显式指定模型。** 省略模型会继承会话模型（通常是最贵的）。
-
-## 上下文管理铁律
-- 所有产物通过文件传递
-- 分发 prompt 只包含当前任务所需
-- 不粘贴历史任务摘要
-- 审查包是文件，不在你的上下文中
-- 信任账本而非自己的记忆
-
-## 合理化防御表
-
-| 借口 | 现实 |
-|------|------|
-| "规范合规差不多就行了" | 审查者发现规范差异 = 没完成。修复或裁定。 |
-| "我自己修复，分发太麻烦" | 控制器修复污染你的上下文且跳过审查。 |
-| "再来一轮会收敛吧" | 过了顶部，轮次不会收敛。失败是结构性的。 |
-| "审查者反正会发现新东西" | 范围限定的重新审查验证修复；它们不会游荡。 |
-| "这个发现明显错了，我跳过吧" | 你只在顶部裁定，每个裁定都是账本条目。 |
-| "修复很小，跳过重新审查" | 未审查的修复是回归的方式。 |
-| "审查拖慢了循环" | 没有审查的循环只是未验证的折腾。 |
-| "账本记录是多余的" | 账本是压缩后存活的东西。 |

package/.specpow/skills/execution-systematic-debugging/SKILL.md

@@ -1,95 +0,0 @@
----
-name: execution-systematic-debugging
-description: 系统化调试 4 阶段根因分析：调查→模式分析→假设测试→实现修复。来自 Superpowers。
----
-
-# 系统化调试
-
-## 铁律
-
-```
-不要猜测。调查。
-```
-
-## 4 阶段流程
-
-### 阶段 1: 调查
-
-1. 复现问题
-2. 收集错误信息（日志、堆栈、截图）
-3. 确定影响范围
-4. 检查最近的变更（`git log --oneline -20`）
-
-### 阶段 2: 模式分析
-
-1. 错误信息中的关键词是什么？
-2. 这个错误模式在代码库中有先例吗？
-3. 最近有什么变更可能引入这个问题？
-4. 是回归还是新问题？
-
-### 阶段 3: 假设测试
-
-1. 形成假设："如果 X，那么 Y"
-2. 设计验证实验
-3. 运行实验
-4. 如果假设被否定，形成新假设
-
-### 阶段 4: 实现修复
-
-1. 修复根因，不是症状
-2. 写回归测试
-3. 验证修复
-4. 检查是否有类似问题
-
-## 根因追踪
-
-如果修复后问题再次出现，说明你没有找到根因。回到阶段 1。
-
-## 合理化防御表
-
-| 你可能的想法 | 现实 |
-|-------------|------|
-| "我猜是这个问题" | 猜测不是调试。验证。 |
-| "先修了再说" | 修症状不是修根因。 |
-| "没时间调查了" | 不调查就修 = 问题会回来。 |
-| "这个错误信息不重要" | 错误信息是线索。读它。 |
-| "肯定是最近改的" | 也可能是旧 bug 被新代码触发。 |
-| "我应该直接问同事" | 先自己调查 15 分钟再问。 |
-| "这个 bug 太复杂了" | 复杂 bug 也是简单问题的组合。分解它。 |
-| "重启一下就好了" | 重启掩盖问题，不解决问题。 |
-| "这个只在测试环境出现" | 测试环境暴露问题，不是制造问题。 |
-| "用户操作错误" | 用户操作是反馈，不是借口。 |
-| "这个优先级不高" | bug 不会因为你标记低优先级就停止影响用户。 |
-
-## 红旗清单
-
-以下 13 条危险信号出现时，立即 STOP：
-
-1. **"我猜是这个问题"** → 猜测不是调试。形成假设并验证。
-2. **"先修了再说"** → 修症状不是修根因。问题会回来。
-3. **"没时间调查了"** → 不调查就修 = 赌博。
-4. **"这个错误信息不重要"** → 错误信息是第一条线索。忽略它 = 盲人摸象。
-5. **"肯定是最近改的"** → 确认偏误。检查所有可能性。
-6. **"我加个日志看看"** → 日志是好的，但先读现有日志和堆栈。
-7. **"这个 bug 太复杂了"** → 复杂 bug 也是简单问题的组合。分解它。
-8. **"重启一下就好了"** → 重启掩盖问题。根因还在。
-9. **"这个只在测试环境出现"** → 测试环境暴露问题，不是制造问题。
-10. **"用户操作错误"** → 用户操作是反馈。系统应该能处理错误操作。
-11. **"这个优先级不高"** → bug 不会因为低优先级就停止影响用户。
-12. **"我之前遇到过类似的"** → 类似不等于相同。每次都要验证。
-13. **"应该是并发/时序问题"** → 不要跳到结论。先排除确定性 bug。
-
-## 压力测试
-
-在声称修复完成前，问自己：
-
-1. 如果输入是空的怎么办？
-2. 如果输入是 null/undefined 怎么办？
-3. 如果并发 1000 个请求怎么办？
-4. 如果网络断了怎么办？
-5. 如果磁盘满了怎么办？
-6. 如果数据库连接超时怎么办？
-7. 如果配置缺失怎么办？
-8. 如果依赖服务返回错误怎么办？
-9. 如果这个修复引入了新问题怎么办？回归测试覆盖了吗？
-10. 如果问题在另一个环境复现不了怎么办？

package/.specpow/skills/execution-tdd/SKILL.md

@@ -1,74 +0,0 @@
----
-name: execution-tdd
-description: 测试驱动开发。严格的 RED-GREEN-REFACTOR 循环。铁律：没有失败测试就不写产品代码。
----
-
-# 测试驱动开发(TDD)
-
-## 铁律
-
-```
-没有失败测试就不写产品代码。
-```
-
-## 循环
-
-### RED — 写一个失败的测试
-
-1. 写一个描述期望行为的测试
-2. 运行测试，确认它失败
-3. 测试失败的原因必须是"功能还不存在"
-
-### GREEN — 写最少的代码让测试通过
-
-1. 写刚好够让测试通过的代码
-2. 不多写。YAGNI。
-3. 运行测试，确认全部通过
-
-### REFACTOR — 清理代码
-
-1. 在测试保护下重构
-2. 消除重复
-3. 改善命名
-4. 运行测试，确认仍然全部通过
-
-## 合理化防御表
-
-| 你可能的想法 | 现实 |
-|-------------|------|
-| "这个改动太小不需要测试" | 小改动也会引入 bug。先写测试。 |
-| "测试会花太长时间" | 不测试会花更长时间调试。 |
-| "这个函数太简单了" | 简单函数也会有边界情况。 |
-| "我先实现再补测试" | 事后测试无法驱动设计。先测试。 |
-| "现有测试已经够了" | 新行为需要新测试。 |
-| "这个 edge case 不太可能发生" | 不可能发生的事总会发生。 |
-| "重构可以等一等" | 技术债会复利增长。 |
-| "文档可以后面再写" | 后面 = 永远不。现在写。 |
-| "性能优化不急" | 等用户抱怨就来不及了。 |
-| "这个 TODO 我记住了" | 你会忘的。写下来。 |
-| "其他模块更重要" | 每个模块都是最重要的。 |
-
-## 红旗
-
-这些想法意味着 STOP — 你正在合理化：
-
-| 想法 | 现实 |
-|------|------|
-| "我先写实现再补测试" | STOP。先写测试。 |
-| "这个不需要测试" | 如果它需要工作，它需要测试。 |
-| "测试太多了" | 代码太多了还差不多。 |
-| "这个 edge case 不重要" | 不重要的 edge case 经常是最重要的 bug。 |
-| "测试会让我变慢" | 没有测试会让你更慢。 |
-
-## 压力测试
-
-在声称完成前，问自己：
-
-1. 如果输入是空的怎么办？
-2. 如果输入是 null/undefined 怎么办？
-3. 如果并发 1000 个请求怎么办？
-4. 如果网络断了怎么办？
-5. 如果磁盘满了怎么办？
-6. 如果数据库连接超时怎么办？
-7. 如果用户输入包含特殊字符怎么办？
-8. 如果配置缺失怎么办？

package/.specpow/skills/execution-verification-before-completion/SKILL.md

@@ -1,75 +0,0 @@
----
-name: execution-verification-before-completion
-description: 完成前验证。铁律：没有新鲜验证证据就不声称完成。防止代理说"应该可以了"。
----
-
-# 完成前验证
-
-## 铁律
-
-```
-没有新鲜验证证据就不声称完成。
-```
-
-## 规则
-
-1. **运行测试** — 不是"应该通过"，是"确实通过"
-2. **检查构建** — 不是"应该能构建"，是"确实构建了"
-3. **验证行为** — 不是"逻辑上应该对"，是"实际运行对了"
-
-## 验证清单
-
-完成前必须确认：
-
-- [ ] 所有测试通过（`npm test` / `mvn test`）
-- [ ] 构建成功（`npm run build` / `mvn package`）
-- [ ] Lint 通过（无新增警告）
-- [ ] 手动验证关键路径（如果适用）
-- [ ] 没有遗留 TODO 或 FIXME
-
-## 合理化防御表
-
-| 你可能的想法 | 现实 |
-|-------------|------|
-| "应该可以了" | "应该"不是证据。运行测试。 |
-| "改动太小不需要验证" | 小改动也能破坏东西。验证。 |
-| "测试太慢了" | 不验证就声称完成更慢（返工）。 |
-| "我检查了代码逻辑" | 检查逻辑 ≠ 运行测试。 |
-| "这个 edge case 不太可能" | 不太可能的事总会发生。 |
-| "集成测试就够了" | 集成测试慢且定位困难。两者都需要。 |
-| "我先发布再修复" | 修复线上 bug 的成本是开发阶段的 100 倍。 |
-| "其他人都验证过了" | 责任在你。自己验证。 |
-| "这个模块不重要" | 每个模块对用户都很重要。 |
-| "性能问题以后再说" | 性能问题会滚雪球。早处理。 |
-| "文档可以后面补" | 后面 = 永远不。现在写。 |
-
-## 红旗
-
-这些想法意味着 STOP — 你正在合理化：
-
-1. **"我觉得应该没问题"** → STOP。验证它。
-2. **"这个改动很明显是对的"** → 明显的改动也经常有 bug。验证。
-3. **"测试都通过了"** → 测试通过 ≠ 行为正确。检查测试覆盖。
-4. **"我手动测试过了"** → 手动测试不可复现。自动化它。
-5. **"这个功能很简单"** → 简单功能也会有复杂 bug。
-6. **"用户不会这样用"** → 用户总会做你意想不到的事。
-7. **"这个错误不重要"** | 错误就是错误。没有"不重要"的错误。
-8. **"我先标记为已知问题"** | 已知问题也会让用户流失。
-9. **"这个只在特定环境出现"** | 特定环境也是真实环境。
-10. **"我昨天测试过了"** | 昨天 ≠ 今天。代码变了。重新测试。
-11. **"这个 warning 可以忽略"** | warning 是未来的 bug。现在修复。
-
-## 压力测试
-
-在声称完成前，问自己：
-
-1. 如果输入是空的怎么办？
-2. 如果输入是 null/undefined 怎么办？
-3. 如果并发 1000 个请求怎么办？
-4. 如果网络断了怎么办？
-5. 如果磁盘满了怎么办？
-6. 如果数据库连接超时怎么办？
-7. 如果用户输入包含特殊字符怎么办？
-8. 如果配置缺失怎么办？
-9. 如果依赖服务不可用怎么办？
-10. 如果内存不足怎么办？