@specpow/framework 0.5.9 → 0.5.11

package/.specpow/skills/meta-create-skill/SKILL.md

@@ -1,374 +0,0 @@
----
-name: meta-create-skill
-description: 技能创建元技能。引导用户创建新的 SpecPow 技能，自动生成 SKILL.md 骨架、测试文件，并注册到技能目录。
----
-
-# 创建技能 (Meta Create Skill)
-> 指导用户创建新的 SpecPow 技能，包括文件结构、测试生成和目录注册
-
-## 触发条件
-
-- 用户要求创建新技能
-- 需要扩展 SpecPow 能力
-- 用户提到"写技能"/"创建 SKILL"/"新增技能"
-- 需要为特定业务场景创建专用技能
-
-## 铁律
-
-1. **单一职责** — 一个技能只做一件事，解决一个明确的问题
-2. **可测试** — 每个技能必须有配套的验证方法
-3. **有边界** — 明确什么时候用、什么时候不用
-4. **遵循规范** — 必须使用标准 SKILL.md 格式
-5. **自动注册** — 新技能必须出现在 `specpow doctor` 检查中
-
-## 合理化防御表
-
-| 你可能的想法 | 现实 |
-|-------------|------|
-| "这个技能太简单了，不需要正式创建" | 简单的技能也可能变复杂。正式创建。 |
-| "我可以晚点再写测试" | 晚点 = 永远不。现在写测试。 |
-| "这个技能只有我会用" | 其他人也会用。写清楚文档。 |
-| "命名不重要" | 命名很重要。用 kebab-case，见名知意。 |
-| "我可以跳过 doctor 检查" | doctor 检查确保技能可被发现。不要跳过。 |
-| "铁律可以少写几条" | 铁律是底线。至少写 3 条。 |
-| "工作流不需要分阶段" | 分阶段让技能更清晰。至少分 2 阶段。 |
-| "红旗可以模糊一点" | 红旗必须具体。模糊的红旗无法触发。 |
-
-## 工作流
-
-### 阶段 1: 需求分析
-
-**目标：** 明确技能的目的和边界
-
-1. **确定技能名称**
-   - 使用 kebab-case（如 `java-codegen`、`test-gen`）
-   - 格式：`<category>-<purpose>`
-   - 分类：planning / execution / quality / business / meta
-
-2. **明确技能职责**
-   - 这个技能解决什么问题？
-   - 什么时候应该使用这个技能？
-   - 什么时候不应该使用？
-
-3. **定义输入输出**
-   - 输入：用户需要提供什么？
-   - 输出：技能会生成什么？
-
-**完成标志：** 能用一句话说清楚技能的用途
-
----
-
-### 阶段 2: 创建技能文件
-
-**目标：** 生成标准 SKILL.md 文件
-
-1. **创建技能目录**
-   ```bash
-   mkdir -p skills/<skill-name>
-   ```
-
-2. **生成 SKILL.md 骨架**
-   
-   使用下方模板生成完整的 SKILL.md 文件：
-
-```markdown
----
-name: <category>-<skill-name>
-description: <一句话描述技能用途>
----
-
-# <技能名称>
-> <一句话描述技能用途>
-
-## 触发条件
-
-- <什么情况下使用这个技能>
-- <用户提到什么关键词时触发>
-
-## 铁律
-
-1. **<规则 1>** — <解释>
-2. **<规则 2>** — <解释>
-3. **<规则 3>** — <解释>
-
-## 合理化防御表
-
-| 你可能的想法 | 现实 |
-|-------------|------|
-| "<常见借口 1>" | <反驳 1> |
-| "<常见借口 2>" | <反驳 2> |
-| "<常见借口 3>" | <反驳 3> |
-
-## 工作流
-
-### 阶段 1: <阶段名称>
-
-**目标：** <阶段目标>
-
-1. <步骤 1>
-2. <步骤 2>
-3. <步骤 3>
-
-**完成标志：** <什么表示阶段完成>
-
----
-
-### 阶段 2: <阶段名称>
-
-**目标：** <阶段目标>
-
-1. <步骤 1>
-2. <步骤 2>
-3. <步骤 3>
-
-**完成标志：** <什么表示阶段完成>
-
-## 输出格式
-
-- <期望的输出 1>
-- <期望的输出 2>
-
-## 红旗（立即停止）
-
-这些想法意味着 STOP — 你正在合理化：
-
-| 想法 | 现实 |
-|------|------|
-| "<危险信号 1>" | <现实 1> |
-| "<危险信号 2>" | <现实 2> |
-| "<危险信号 3>" | <现实 3> |
-
-## 压力测试
-
-在声称完成前，问自己：
-
-1. <边界情况 1>
-2. <边界情况 2>
-3. <边界情况 3>
-```
-
-3. **填写模板内容**
-   - 根据需求分析的结果填写所有占位符
-   - 确保每个章节都有实质内容
-   - 铁律至少 3 条，最多 5 条
-   - 合理化防御表至少 5 行
-   - 红旗至少 3 条
-   - 压力测试至少 3 个问题
-
-**完成标志：** SKILL.md 文件创建完成，格式正确
-
----
-
-### 阶段 3: 创建测试文件（可选但推荐）
-
-**目标：** 为技能创建验证方法
-
-1. **创建测试文件**
-   ```bash
-   touch test/<skill-name>.test.ts
-   ```
-
-2. **编写测试用例**
-   
-   测试文件模板：
-
-```typescript
-/**
- * <技能名称> 测试
- *
- * 测试 skills/<skill-name>/SKILL.md 的效果
- */
-
-import { describe, it, expect } from 'vitest';
-import { readFileSync } from 'fs';
-import { join } from 'path';
-
-describe('<skill-name>', () => {
-  it('should have valid SKILL.md format', () => {
-    const skillPath = join(process.cwd(), 'skills', '<skill-name>', 'SKILL.md');
-    const content = readFileSync(skillPath, 'utf-8');
-    
-    // 检查 frontmatter
-    expect(content).toMatch(/^---\nname: .+\ndescription: .+\n---\n/);
-    
-    // 检查必需章节
-    expect(content).toContain('## 触发条件');
-    expect(content).toContain('## 铁律');
-    expect(content).toContain('## 工作流');
-    expect(content).toContain('## 红旗');
-  });
-
-  it('should have at least 3 iron rules', () => {
-    const skillPath = join(process.cwd(), 'skills', '<skill-name>', 'SKILL.md');
-    const content = readFileSync(skillPath, 'utf-8');
-    
-    const ironRulesSection = content.match(/## 铁律\n([\s\S]*?)(?=\n## |\n$)/);
-    expect(ironRulesSection).not.toBeNull();
-    
-    const rules = ironRulesSection![1].match(/^\d+\./gm);
-    expect(rules!.length).toBeGreaterThanOrEqual(3);
-  });
-
-  it('should have defense table', () => {
-    const skillPath = join(process.cwd(), 'skills', '<skill-name>', 'SKILL.md');
-    const content = readFileSync(skillPath, 'utf-8');
-    
-    expect(content).toContain('## 合理化防御表');
-    expect(content).toContain('| 你可能的想法 | 现实 |');
-  });
-
-  it('should have pressure testing section', () => {
-    const skillPath = join(process.cwd(), 'skills', '<skill-name>', 'SKILL.md');
-    const content = readFileSync(skillPath, 'utf-8');
-    
-    expect(content).toContain('## 压力测试');
-  });
-});
-```
-
-3. **运行测试**
-   ```bash
-   npx vitest run test/<skill-name>.test.ts
-   ```
-
-**完成标志：** 测试文件创建并通过
-
----
-
-### 阶段 4: 验证技能
-
-**目标：** 确保技能可被正确发现和使用
-
-1. **运行 doctor 检查**
-   ```bash
-   specpow doctor
-   ```
-   
-   确认输出中包含：
-   ```
-   ✓ 技能文件: 找到 <N> 个技能文件
-   ```
-
-2. **手动验证技能格式**
-   - 检查 frontmatter 是否正确
-   - 检查所有必需章节是否存在
-   - 检查命名是否符合规范
-
-3. **测试技能触发**
-   - 在对话中提到触发条件
-   - 确认 AI 会引用这个技能
-
-**完成标志：** doctor 检查通过，技能可被正确引用
-
----
-
-### 阶段 5: 文档更新（可选）
-
-**目标：** 更新相关文档以包含新技能
-
-1. **更新 CLAUDE.md**（如果是核心技能）
-   - 在技能分类表格中添加新技能
-   - 在技能列表中提及
-
-2. **更新 README.md**（如果需要对外宣传）
-   - 在技能列表中添加新技能
-   - 提供使用示例
-
-**完成标志：** 相关文档已更新
-
-## 输出格式
-
-完成技能创建后，应该生成：
-
-1. **技能目录**
-   ```
-   skills/<skill-name>/
-   └── SKILL.md
-   ```
-
-2. **测试文件**（可选）
-   ```
-   test/<skill-name>.test.ts
-   ```
-
-3. **doctor 检查结果**
-   ```
-   ✓ 技能文件: 找到 <N> 个技能文件
-   ```
-
-## 技能分类参考
-
-| 分类 | 用途 | 示例 |
-|------|------|------|
-| meta | 元技能，管理其他技能 | using-skills, writing-skills, create-skill |
-| planning | 规划和设计阶段 | explore, propose, write-specs, write-design |
-| execution | 执行阶段 | subagent-driven-dev, tdd, parallel-agents |
-| quality | 质量保障 | requesting-review, receiving-review, verification |
-| business | 业务特定 | java-codegen, ui-codegen, test-gen, code-review |
-
-## 命名规范
-
-1. **目录名：** kebab-case（如 `java-codegen`、`test-gen`）
-2. **文件名：** 固定为 `SKILL.md`
-3. **frontmatter name：** `<category>-<name>`（如 `execution-tdd`）
-4. **分类前缀：**
-   - `meta-` — 元技能
-   - `planning-` — 规划技能
-   - `execution-` — 执行技能
-   - `quality-` 或 `execution-` — 质量技能
-   - `business-` — 业务技能
-
-## 红旗（立即停止）
-
-这些想法意味着 STOP — 你正在合理化：
-
-| 想法 | 现实 |
-|------|------|
-| "我可以跳过测试" | 测试确保技能质量。不要跳过。 |
-| "frontmatter 不重要" | frontmatter 是技能被发现的关键。必须正确。 |
-| "我可以少写几个章节" | 每个章节都有用途。全部填写。 |
-| "命名随便取一个" | 命名影响可发现性。认真取。 |
-| "doctor 检查会失败也没关系" | doctor 检查确保技能可用。必须通过。 |
-| "我可以稍后再补防御表" | 防御表防止合理化。现在就写。 |
-
-## 压力测试
-
-在声称技能创建完成前，问自己：
-
-1. 如果用户完全不了解这个技能，能看懂 SKILL.md 吗？
-2. 如果 AI 没有看到这个技能，会错过什么关键信息？
-3. 如果多个技能同时适用，优先级清晰吗？
-4. 如果技能被误用，后果是什么？如何防止？
-5. 如果技能需要更新，更新路径清晰吗？
-6. 如果其他开发者想贡献，贡献指南明确吗？
-7. 如果技能有 bug，如何发现和修复？
-8. 如果技能与其他技能冲突，如何解决？
-
-## 示例：创建一个简单的技能
-
-假设要创建一个 `execution-code-review` 技能：
-
-1. **需求分析**
-   - 名称：`execution-code-review`
-   - 职责：指导如何进行代码审查
-   - 触发：用户要求审查代码
-
-2. **创建目录和文件**
-   ```bash
-   mkdir -p skills/execution-code-review
-   ```
-
-3. **生成 SKILL.md**（使用上方模板）
-
-4. **创建测试**（可选）
-   ```bash
-   touch test/execution-code-review.test.ts
-   ```
-
-5. **验证**
-   ```bash
-   specpow doctor
-   npx vitest run test/execution-code-review.test.ts
-   ```
-
-完成！

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

@@ -1,97 +0,0 @@
----
-name: meta-using-skills
-description: 系统入口技能。每次会话开始时自动加载。建立"先检查技能再行动"的铁律。融合 Superpowers using-superpowers + OpenSpec 工作流意识。
----
-
-<SUBAGENT-STOP>
-如果你是被分发去执行特定任务的子代理，忽略此技能。
-</SUBAGENT-STOP>
-
-<EXTREMELY-IMPORTANT>
-如果你认为有任何 1% 的可能性某个技能适用于你正在做的事，你绝对必须调用该技能。
-如果一个技能适用于你的任务，你没有选择。你必须使用它。
-这不可协商。你不能合理化地绕过它。
-</EXTREMELY-IMPORTANT>
-
-## 铁律
-
-**在任何响应或行动之前调用相关技能** — 包括澄清问题、探索代码库、或检查文件。如果它不适合当前情况，你可以不用。
-
-**在进入规划模式之前：** 如果你还没有进行头脑风暴，先调用 brainstorming/explore 技能。
-
-然后宣布 "使用 [技能名] 用于 [目的]" 并严格遵循技能。如果它有检查清单，为每一项创建一个 todo。
-
-## 技能优先级
-
-当多个技能适用时，流程技能先行 — 它们设定方法，然后实施技能执行。
-- "让我们构建 X" → 先 explore/brainstorming，然后实施技能
-- "修复这个 bug" → 先 systematic-debugging，然后领域技能
-- "创建新变更" → 先 propose，然后 apply-change
-- "执行任务" → subagent-driven-development
-
-## 技能分类
-
-### 规划类（先于编码）
-- `explore` — 苏格拉底式需求探索（无承诺）
-- `propose` — 创建变更提案（proposal + specs + design + tasks）
-- `write-plans` — 将设计转化为极详细的实现计划
-
-### 执行类（编码阶段）
-- `apply-change` — 执行变更（SDD 引擎驱动）
-- `subagent-driven-dev` — 子代理驱动开发（核心执行引擎）
-- `tdd` — 测试驱动开发（RED-GREEN-REFACTOR）
-- `systematic-debugging` — 4 阶段根因分析
-- `parallel-agents` — 并行子代理调度
-
-### 质量类（验证阶段）
-- `requesting-review` — 请求代码审查
-- `receiving-review` — 接收审查反馈
-- `verification-before-completion` — 完成前验证铁律
-- `verify-change` — 规范合规性验证
-
-### 业务类（领域能力）
-- `java-codegen` — Java 后端代码生成
-- `ui-codegen` — Vue2 前端代码生成
-- `test-gen` — 测试生成
-- `code-review` — 业务代码审查
-- `db-design` — 数据库设计
-- `prd-writer` — PRD 编写
-- `deploy-check` — 发版检查
-- `doc-sync` — 文档同步
-
-## 红旗
-
-这些想法意味着 STOP — 你在合理化跳过技能：
-
-| 想法 | 现实 |
-|------|------|
-| "这只是个简单问题" | 问题也是任务。检查技能。 |
-| "我需要先了解更多上下文" | 技能检查在澄清问题之前。 |
-| "让我先探索代码库" | 技能告诉你如何探索。先检查。 |
-| "这不需要正式的技能" | 如果技能存在，就使用它。 |
-| "这个技能太重量级了" | 简单的事会变复杂。使用它。 |
-| "我先做这一件事" | 做任何事之前先检查技能。 |
-| "我记得这个技能" | 技能会演进。读当前版本。 |
-| "这不算一个任务" | 行动 = 任务。检查技能。 |
-| "我知道那是什么意思" | 知道概念 ≠ 使用技能。调用它。 |
-
-## 平台适配
-
-如果你的 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 之间通过文件通信，不依赖对话上下文

package/.specpow/skills/meta-writing-skills/SKILL.md

@@ -1,66 +0,0 @@
----
-name: meta-writing-skills
-description: SpecPow meta-writing-skills skill
----
-
-# 编写技能
-> 指导如何创建新的 SpecPow 技能文件
-
-## 触发条件
-
-- 用户要求创建新技能
-- 需要扩展 SpecPow 能力
-- 用户提到"写技能"/"创建 SKILL"
-
-## 铁律
-
-1. **单一职责** — 一个技能只做一件事
-2. **可组合** — 技能之间可以互相引用
-3. **有边界** — 明确什么时候用、什么时候不用
-4. **可测试** — 技能的效果可以验证
-
-## 技能文件结构
-```markdown
-# 技能名称
-> 一句话描述技能用途
-
-## 触发条件
-- 什么情况下使用这个技能
-
-## 铁律
-1. 不可违反的规则
-2. ...
-
-## 工作流
-### 阶段 1: ...
-### 阶段 2: ...
-
-## 输出格式
-- 期望的输出结果
-
-## 红旗（立即停止）
-- 什么情况下必须停止
-```
-
-## 命名规范
-
-- 目录名: kebab-case（如 `java-codegen`）
-- 文件名: 固定为 `SKILL.md`
-- 分类: planning / execution / quality / business / meta
-
-## 技能分类
-| 分类 | 用途 | 示例 |
-|------|------|------|
-| meta | 元技能，管理其他技能 | using-skills, writing-skills |
-| planning | 规划和设计阶段 | explore, propose, write-specs |
-| execution | 执行阶段 | subagent-driven-dev, tdd |
-| quality | 质量保障 | code-review, test-gen |
-| business | 业务特定 | java-codegen, ui-codegen |
-
-## 编写原则
-
-1. **开头用 `>` 引用块写一句话描述**
-2. **铁律不超过 5 条**
-3. **工作流分阶段，每阶段有明确目标**
-4. **红旗必须具体，不能模糊**
-5. **包含具体示例**