@specpow/framework 0.5.9 → 0.5.11

package/.specpow/skills/planning-write-plans/SKILL.md

@@ -1,55 +0,0 @@
----
-name: planning-write-plans
-description: SpecPow planning-write-plans skill
----
-
-# 编写计划
-
-> 根据设计文档编写任务计划（tasks.md）
-
-## 触发条件
-
-- design 完成后需要编写任务计划
-- 用户提到"写计划"/"任务拆分"/"tasks"
-
-## 铁律
-
-1. **原子任务** — 每个任务可独立执行和验证
-2. **依赖明确** — 标注任务间依赖关系
-3. **验证步骤** — 每个任务有明确的验证方式
-4. **文件路径** — 标注涉及的文件
-
-## 任务格式
-
-```markdown
-## 任务列表
-
-### 全局约束
-- 分支: feature/xxx
-- 基础: main 分支最新代码
-
-### Task-001: [任务标题]
-- 文件: `src/main/java/xxx/Entity.java`
-- 依赖: 无
-- 描述: 创建 XxxEntity 实体类
-- 验证: 编译通过
-
-### Task-002: [任务标题]
-- 文件: `src/main/java/xxx/Mapper.java`, `src/main/resources/mapper/XxxMapper.xml`
-- 依赖: Task-001
-- 描述: 创建数据访问层
-- 验证: 单元测试通过
-```
-
-## 拆分原则
-
-1. **按层拆分** — Entity → Mapper → Service → Controller
-2. **按功能拆分** — 每个 CRUD 操作一个任务
-3. **按文件拆分** — 每个文件一个任务（如果不太小）
-4. **工作量标记** — S(<0min) / M(30min-2h) / L(2h+)
-
-## 红旗
-
-- 任务过大(>4h) → 继续拆分
-- 无验证步骤 → 补充验证
-- 依赖关系不清 → 明确依赖

package/.specpow/skills/planning-write-specs/SKILL.md

@@ -1,91 +0,0 @@
----
-name: planning-write-specs
-description: SpecPow planning-write-specs skill
----
-
-# 编写规范
-
-> 根据提案编写 Delta 规范（spec.md）
-
-## 触发条件
-
-- proposal 完成后需要编写规范
-- 用户提到"写规范"/"spec"/"需求规范"
-
-## 铁律
-
-1. **Delta 格式** — 使用 ADDED/MODIFIED/REMOVED/RENAMED
-2. **验收标准** — 每个需求必须有 Given/When/Then
-3. **唯一 ID** — 每个需求有唯一标识
-
-## 规范格式
-
-```markdown
-# 规范: [变更标题]
-
-## ADDED Requirements
-
-### REQ-001: [需求标题]
-系统应当 [具体行为描述]。
-
-**验收标准:**
-- **Given** [前置条件]
-- **When** [触发动作]
-- **Then** [预期结果]
-
-### REQ-002: [需求标题]
-...
-
-## MODIFIED Requirements
-
-### REQ-010: [需求标题]
-变更描述: [修改了什么]
-原因: [为什么修改]
-
-**更新后的验收标准:**
-- **Given** ...
-- **When** ...
-- **Then** ...
-
-## REMOVED Requirements
-
-### REQ-020: [需求标题]
-移除原因: [为什么移除]
-影响: [移除后的影响]
-
-## RENAMED Requirements
-
-### REQ-030 → REQ-031: [旧名称 → 新名称]
-重命名原因: [为什么重命名]
-```
-
-## 编写原则
-
-1. **具体** — "系统应当在 3 秒内返回结果" 而非 "系统应当快速响应"
-2. **可测试** — 每个需求都能写出测试用例
-3. **无歧义** — 避免"可能"、"也许"等模糊词
-4. **独立** — 需求之间尽量不互相依赖
-
-## 名称校验（铁律）
-
-编写 MODIFIED / REMOVED / RENAMED 操作时，需求名称**必须与主规范中的已有名称完全一致**（精确字符串匹配）。
-
-### 流程
-
-1. 查看 AI 指令中注入的"已有主规范"部分，找到"需求名称"清单
-2. MODIFIED/REMOVED 使用的名称必须在清单中**逐字匹配**
-3. RENAMED 的旧名称必须在清单中逐字匹配，新名称自由命名
-4. ADDED 的名称不得与清单中已有名称重复
-5. 写完后运行 `specpow validate-specs --change <变更名>` 验证
-
-### 常见错误
-
-- ❌ "用户认证" vs 主规范中是 "用户登录" → 不匹配
-- ❌ "密码规则" vs 主规范中是 "密码策略" → 不匹配
-- ✅ 直接复制清单中的名称，不做任何改写
-
-## 红旗
-
-- 无验收标准 → 必须补充
-- 需求模糊 → 与用户确认
-- 需求冲突 → 解决冲突后再继续

package/.specpow/skills/using-specpow/SKILL.md

@@ -1,232 +0,0 @@
----
-name: using-specpow
-description: Bootstrap 元技能。Host-Driven 模式下会话启动时自动加载。教会宿主 Agent 使用原生工具执行 SDD 工作流。融合 Superpowers using-superpowers 模式 + SpecPow SDD 编排能力。
-version: 1.0.0
-trigger: session-start
-mode: host-driven
----
-
-<SUBAGENT-STOP>
-如果你是被分发去执行特定任务的子代理，忽略此技能。
-</SUBAGENT-STOP>
-
-<EXTREMELY_IMPORTANT>
-如果你认为有任何 1% 的可能性某个技能适用于你正在做的事，你绝对必须调用该技能。
-如果一个技能适用于你的任务，你没有选择。你必须使用它。
-这不可协商。你不能合理化地绕过它。
-</EXTREMELY_IMPORTANT>
-
-# SpecPow Host-Driven SDD 工作流
-
-你已加载 **SpecPow** — 一个规范驱动的 AI 开发框架。
-它结合了 OpenSpec 的规范驱动规划与 Superpowers 的子代理驱动执行。
-
-**当前模式：Host-Driven** — 你将使用**原生工具**（subagent、file I/O、bash）执行整个 SDD 方法论。
-TypeScript 代码仅负责非 AI 工作（文件创建、schema 解析）。**你是编排者。**
-
-## 铁律
-
-1. **先查技能** — 任何响应或行动之前，先扫描 `.specpow/skills/` 目录查找相关技能
-2. **文件即接口** — 子代理通过文件通信（brief、report、review JSON），不通过对话上下文
-3. **Ledger 是真相** — 上下文压缩后，信任 Ledger（`.specpow/sdd/<change>/progress.md`）和 git log，不信任自己的记忆
-4. **TDD 强制** — RED → GREEN → REFACTOR，不可跳过
-5. **规范即契约** — specs 中定义的行为必须被实现遵守
-6. **审查+测试才完成** — 每个任务实施完成后，必须经过**代码审查**且**测试全部通过**，才能标记为 done。审查通过后标记完成；审查未通过则进入修复循环（最多 5 轮），每轮修复后重新审查修复部分。
-7. **发现必须验证** — 审查中发现的每个问题，必须**确认其真实存在**（读代码、跑测试、看 diff）后才能记录。禁止无中生有——不确定的发现标记为 `cannotVerify`，不标记为 finding。
-
-## 触发纪律（Trigger Discipline）
-
-| 用户说 / 场景 | 你做什么 |
-|---------------|----------|
-| `specpow apply`（默认模式） | 不干预 — TypeScript SDD 引擎接管 |
-| `specpow apply --host-driven`（计划中） | 读取任务清单，按 `execution-subagent-driven-dev` 技能逐任务执行 |
-| `specpow explore "..."` | 调用 `planning-explore` 技能 |
-| `specpow propose <name>` | 调用 `planning-propose` 技能 |
-| 任何编码任务 | 先检查 `.specpow/skills/` 是否有适用技能 |
-| 发现 SDD 工作区（`.specpow/sdd/<change>/`） | 自动读取 progress.md 并按 SDD 流程继续 |
-
-## Host-Driven 模式核心概念
-
-### 你拥有的原生工具
-
-| 工具类型 | 用途 | 示例 |
-|---------|------|------|
-| **Subagent 工具** | 派发实现者/审查者子代理 | Claude Code: Agent tool; Cursor: subagent |
-| **File I/O** | 读写 brief、report、review JSON | Read/Write 工具 |
-| **Bash** | 执行 git 操作、运行测试 | `git diff`, `npm test` |
-| **Ledger** | 记录进度、恢复状态 | 追加到 `.specpow/sdd/<change>/progress.md` |
-
-### 文件通信协议
-
-子代理之间通过文件通信，每个文件有固定位置：
-
-```
-.specpow/
-├── sdd/{change}/
-│   ├── progress.md              # 进度账本（追加写入）
-│   ├── task-{N}-brief.md        # 任务简报
-│   ├── task-{N}-report.md       # 实现报告
-│   └── task-{N}-report.md.fix-{R}  # 修复报告（第 R 轮）
-├── openspec/
-│   └── changes/{change}/
-│       ├── specs/              # 规范文件
-│       ├── design.md           # 设计文档
-│       └── .openspec.yaml      # 变更配置
-└── skills/                     # 技能目录（你正在这里）
-```
-
-### Report JSON 格式
-
-实现者子代理完成后写入 report：
-```json
-{
-  "status": "done|blocked|in_progress|done_with_concerns|needs_context",
-  "commits": ["sha1", "sha2"],
-  "testSummary": "X tests passed",
-  "concerns": "any issues or null",
-  "fixReport": "修复轮次时的修复说明（仅 fix 轮次填写）"
-}
-```
-
-### Review JSON 格式
-
-审查者子代理完成后写入 review：
-```json
-{
-  "specCompliant": true,
-  "qualityApproved": true,
-  "findings": [
-    {
-      "id": "F1",
-      "severity": "critical|important|minor",
-      "description": "...",
-      "file": "src/foo.ts",
-      "line": 42,
-      "isLoadBearing": false
-    }
-  ],
-  "cannotVerify": []
-}
-```
-
-## SDD 编排快速参考
-
-完整的编排流程在 `execution-sdd-orchestrator` 技能中详细描述。核心循环：
-
-```
-对每个任务：
-  1. 创建 Brief → task-{N}-brief.md
-  2. 派发实现者 → 读 brief → 写代码 → 写 report JSON → task-{N}-report.md
-  3. 检查 report（blocked? → 跳过; done? → 继续）
-  4. 派发审查者 → 读 brief + diff + specs → 写 review JSON
-  5. 运行测试
-  6. 分析结果 → 审查通过 + 测试通过? → 标记 done → 下一任务
-                → 需要修复? → 修复循环（最多 5 轮）：
-                    每轮：修复 findings → 派发重审者（只审查修复部分）→ 运行测试 → 分析
-```
-
-## 模型选择指导
-
-你可以根据任务复杂度选择子代理模型（如果宿主工具支持）：
-
-| 场景 | 条件 | 推荐级别 |
-|------|------|----------|
-| 机械实现 | ≤2 文件 + 完整 spec | cheap（默认 haiku） |
-| 集成实现 | 多文件协调 | standard（默认 sonnet） |
-| 架构设计 | 需要设计判断 | capable（默认 opus） |
-| 简单审查 | <100 行 diff | cheap（默认 haiku） |
-| 最终审查 | 全变更审查 | capable（默认 opus） |
-| 修复轮次 4-5 | 升级模型 | 比当前高一级 |
-
-**注意**：这只是指导。根据你实际可用的模型做出最佳选择。
-
-## 技能优先级
-
-当多个技能适用时，流程技能先行 — 它们设定方法，然后实施技能执行。
-- "让我们构建 X" → 先 explore/brainstorming，然后实施技能
-- "修复这个 bug" → 先 systematic-debugging，然后领域技能
-- "创建新变更" → 先 propose，然后 apply-change
-- "执行任务" → 先 subagent-driven-dev，然后相关实施技能
-
-## 可用技能清单
-
-### 规划类（先于编码）
-- `planning-explore` — 苏格拉底式需求探索（无承诺）
-- `planning-propose` — 创建变更提案（proposal + specs + design + tasks）
-- `planning-write-plans` — 将设计转化为极详细的实现计划
-- `planning-write-specs` — 编写 delta 规范
-- `planning-write-design` — 创建架构设计文档
-- `planning-apply-change` — 执行变更（SDD 引擎驱动）
-- `planning-onboard` — 项目入门引导
-- `planning-archive-change` — 归档变更
-- `planning-verify-change` — 规范合规性验证
-- `planning-update-change` — 更新变更
-
-### 执行类（编码阶段）
-- `execution-subagent-driven-dev` — **子代理驱动开发**（核心执行引擎）
-- `execution-tdd` — 测试驱动开发（RED-GREEN-REFACTOR）
-- `execution-systematic-debugging` — 4 阶段根因分析
-- `execution-parallel-agents` — 并行子代理调度
-- `execution-git-worktrees` — Git worktree 管理
-- `execution-finish-branch` — 分支完成与合并
-- `execution-requesting-review` — 请求代码审查
-- `execution-receiving-review` — 接收审查反馈
-- `execution-verification-before-completion` — 完成前验证铁律
-
-### 质量类（验证阶段）
-- `planning-verify-change` — 规范合规性验证
-
-### 业务类（领域能力）
-- `business-java-codegen` — Java 后端代码生成
-- `business-ui-codegen` — Vue2 前端代码生成
-- `business-test-gen` — 测试生成
-- `business-code-review` — 业务代码审查
-- `business-db-design` — 数据库设计
-- `business-prd-writer` — PRD 编写
-- `business-deploy-check` — 发版检查
-- `business-doc-sync` — 文档同步
-- `business-menu-register` — 菜单注册
-
-### 元技能类
-- `meta-using-skills` — 如何使用技能
-- `meta-writing-skills` — 如何编写新技能
-- `meta-create-skill` — 引导式技能创建向导
-
-## 红旗（立即停止）
-
-这些想法意味着 STOP — 你在合理化跳过技能：
-
-| 想法 | 现实 |
-|------|------|
-| "这只是个简单问题" | 问题也是任务。检查技能。 |
-| "我需要先了解更多上下文" | 技能检查在澄清问题之前。 |
-| "让我先探索代码库" | 技能告诉你如何探索。先检查。 |
-| "这不需要正式的技能" | 如果技能存在，就使用它。 |
-| "这个技能太重量级了" | 简单的事会变复杂。使用它。 |
-| "我先做这一件事" | 做任何事之前先检查技能。 |
-| "我记得这个技能" | 技能会演进。读当前版本。 |
-| "这不算一个任务" | 行动 = 任务。检查技能。 |
-| "我直接用 claude CLI 调用" | Host-Driven 模式用原生 subagent 工具，不用 CLI 子进程。 |
-| "让我直接调用 SDDController" | 不要！你是编排者，用技能指令而非 TypeScript 代码。 |
-
-## 平台适配
-
-如果你的 AI 工具在此列表中，读取其参考文件获取特殊指令（**计划中** — 文件尚未创建，当前使用通用指令）：
-
-- Claude Code: `references/claude-tools.md`（计划中）
-- Cursor: `references/cursor-tools.md`（计划中）
-- CodeBuddy: `references/codebuddy-tools.md`（计划中）
-- GitHub Copilot: `references/copilot-tools.md`（计划中）
-- Codex: `references/codex-tools.md`（计划中）
-
-## 用户指令优先级
-
-用户指令（CLAUDE.md, AGENTS.md 等直接请求）优先于技能，技能优先于默认行为。只有当你的搭档明确要求时，才跳过技能工作流。
-
-## SpecPow 特有规则
-
-1. **规划先于编码** — 任何超过 30 分钟的编码工作，必须先完成 propose 流程
-2. **规范即契约** — specs 中定义的行为必须被实现遵守，SDD 审查会验证
-3. **账本即真理** — 上下文压缩后，信任账本和 git log，而非自己的记忆
-4. **文件即接口** — Agent 之间通过文件通信，不依赖对话上下文
-5. **双模式共存** — 默认模式用 SDD Engine（TypeScript 编排）；`--host-driven` 模式用宿主 Agent 编排