@specpow/framework 0.5.11 → 0.5.12

package/builtin/skills/business-ui-codegen/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: business-ui-codegen
+description: SpecPow business-ui-codegen skill
+---
+
+# UI 代码生成
+
+> 根据设计文档和接口定义，生成前端页面/UI 代码
+
+## 技术栈配置
+
+本技能的**默认**技术栈为 Vue2 + View Design，但会根据项目实际使用的框架自动适配：
+
+- **前端框架** — 优先使用项目已有的框架（Vue2 / Vue3 / React / Angular）
+- **UI 组件库** — 匹配项目已有组件库（View Design / Element / Ant Design / MUI）
+- **状态管理** — 使用项目已有的状态管理（Vuex / Pinia / Redux / NgRx）
+- **样式方案** — 沿用项目已有的 CSS 方案（CSS Modules / Scoped CSS / Tailwind / Less / SCSS）
+
+如果项目无已有前端代码，则在阶段 1 询问用户确认技术选型。
+
+## 触发条件
+
+- 用户要求生成前端页面/UI 代码
+- 执行 apply-change 时涉及前端任务
+- 用户提到"生成页面"/"写组件"/"创建表单"
+
+## 铁律
+
+1. **接口先行** — 必须确认后端 API 已定义（路径、参数、返回值）
+2. **组件复用** — 优先使用 View Design 组件，不造轮子
+3. **样式规范** — 使用项目已有的 CSS 变量/mixin
+4. **响应式** — 表格、表单必须适配常见分辨率
+
+## 工作流
+
+### 阶段 1：上下文收集
+
+1. 读取 design.md 获取页面结构和交互设计
+2. 确认 API 接口定义（路径、Method、参数、响应）
+3. **扫描项目已有页面，识别技术栈**（框架、组件库、状态管理、样式方案）
+4. 如果项目无已有前端代码，询问用户确认技术选型
+5. 确认路由配置方式
+
+### 阶段 2：代码生成
+
+按以下顺序生成：
+
+**2.1 API 接口文件**
+```
+文件: src/api/xxx.js
+- 使用 axios 封装
+- 每个接口一个导出函数
+- 请求/响应拦截器统一处理
+```
+
+**2.2 页面主文件**
+```
+文件: src/views/xxx/index.vue
+- <template>: View Design 组件组合
+- <script>: data/methods/computed/watch 标准结构
+- <style scoped>: 局部样式
+```
+
+**2.3 列表页模板**
+```
+- 搜索表单（Form + FormItem）
+- 操作按钮栏（新增/导出/批量操作）
+- 数据表格（Table + columns 配置）
+- 分页（Page 组件）
+- 新增/编辑弹窗（Modal + Form）
+```
+
+**2.4 表单页模板**
+```
+- 表单验证规则（rules）
+- 提交前校验
+- 返回/重置按钮
+```
+
+**2.5 路由配置**
+```
+- 路由路径与菜单对应
+- meta 包含 title、icon、权限
+```
+
+### 阶段 3：验证
+
+1. 语法检查：Vue 模板无报错
+2. 组件引用：所有使用的组件已注册
+3. API 调用：接口路径和参数与设计一致
+
+## 输出格式
+
+```
+文件: src/views/xxx/index.vue
+类型: 页面组件
+依赖: View Design, axios, 路由
+```
+
+## 红旗（立即停止）
+
+- API 接口未定义 → 先完成后端
+- 项目未使用 View Design → 确认 UI 框架
+- 发现已有同名页面 → 报告冲突

package/builtin/skills/cli-router/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: cli-router
+version: 1.0.0
+trigger: on-demand
+description: SpecPow CLI 命令路由 — 将用户意图映射到 CLI 命令执行
+---
+
+# SpecPow CLI 路由技能
+
+当用户请求执行 SpecPow CLI 命令时，按以下规则执行。
+
+## 铁律
+
+1. **所有 CLI 命令通过 Bash 工具执行**，不在对话中模拟输出
+2. **先检查状态**：执行任何命令前先 `specpow status`
+3. **展示完整输出**：将命令输出完整展示给用户
+4. **链式引导**：执行完一步后建议下一步
+
+## 意图 → 命令映射表
+
+| 用户说 | 执行命令 |
+|--------|---------|
+| "探索需求" / "explore" / "specpow explore" | `specpow explore "主题"` |
+| "创建提案" / "propose" / "specpow propose" | `specpow propose <name>` |
+| "执行" / "apply" / "实现" / "specpow apply" | `specpow apply` |
+| "验证" / "verify" / "检查" / "specpow verify" | `specpow verify` |
+| "归档" / "archive" / "specpow archive" | `specpow archive` |
+| "状态" / "status" / "specpow status" | `specpow status` |
+| "调试" / "debug" / "specpow debug" | `specpow debug "描述"` |
+| "doctor" / "诊断" / "specpow doctor" | `specpow doctor` |
+| "review" / "审查" / "specpow review" | `specpow review` |
+| "schemas" / "schema 列表" | `specpow schemas` |
+| "更新" / "update" / "specpow update" | `specpow update` |
+| "配置" / "config" / "specpow config" | `specpow config` |
+
+## 执行规则
+
+### 交互式命令处理
+
+`specpow explore` 是交互式命令（使用 readline），在 Claude Code 的 Bash 工具中无法交互。
+遇到此命令时：
+1. 告诉用户需要在终端中运行：`specpow explore "主题"`
+2. 或者尝试使用 `--json` 标志获取非交互式输出（如果支持）
+3. 如果用户坚持在 Claude Code 中执行，使用苏格拉底式提问手动模拟探索流程
+
+### 非交互式命令
+
+其他所有命令（propose/apply/verify/archive/status）都是非交互式的，直接通过 Bash 执行：
+
+```bash
+# 示例：执行状态检查
+specpow status
+
+# 示例：创建变更提案
+specpow propose add-login
+
+# 示例：使用特定 schema
+specpow propose fix-bug --schema bug-fix
+
+# 示例：验证变更
+specpow verify --change add-login
+
+# 示例：归档变更
+specpow archive --change add-login
+```
+
+### 错误处理
+
+命令失败时：
+1. 展示完整错误信息
+2. 分析可能的原因
+3. 建议解决方案
+4. 如果适用，运行 `specpow doctor` 进行诊断
+
+### 工作流引导
+
+根据当前阶段引导用户：
+
+```
+[无变更] → propose → [有提案] → apply → [已实现] → verify → [已验证] → archive
+```
+
+每次执行 `specpow status` 后，根据阶段推荐下一步操作：
+- 无活跃变更 → 建议 `/specpow-propose <name>`
+- 有提案但工件未完成 → 建议编辑工件文件
+- 工件已完成 → 建议 `/specpow-apply`
+- 已实现 → 建议 `/specpow-verify`
+- 已验证 → 建议 `/specpow-archive`
+
+## 合理化防御表
+
+| 你以为的 | 实际应该做的 |
+|---------|------------|
+| "我可以直接告诉用户命令是什么" | 用 Bash 工具执行命令并展示结果 |
+| "这个命令太简单了，不需要执行" | 仍然执行，展示实际输出 |
+| "用户应该自己去终端运行" | 用户要求你执行，你就执行 |
+| "explore 是交互式的，我模拟一下" | 告诉用户需要在终端运行，或手动模拟苏格拉底式提问 |
+
+## 红旗
+
+以下想法意味着 STOP：
+
+| 想法 | 现实 |
+|------|------|
+| "我可以假装执行了命令" | 必须真正用 Bash 执行并展示输出 |
+| "这个命令会改变什么，让我先确认" | 直接执行，展示结果让用户确认 |
+| "用户可能不知道这个命令" | 执行命令后解释输出含义 |

package/builtin/skills/execution-finish-branch/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: execution-finish-branch
+description: SpecPow execution-finish-branch skill
+---
+
+# 完成分支
+
+> 分支开发完成后的合并和清理流程
+
+## 触发条件
+
+- 变更所有任务完成 — 准备合并到主分支
+- 用户提到"完成分支"/"合并"/"清理"
+
+## 铁律
+
+1. **验证先行** — 合并前必须通过所有检查
+2. **squash 合并** — 保持主分支历史整洁
+3. **删除分支** — 合并后删除功能分支
+4. **更新状态** — 归档变更
+
+## 工作流
+
+### 1. 最终验证
+```bash
+# 确保测试通过
+pnpm test
+
+# 确保构建通过
+pnpm build
+
+# 确保无未提交变更
+git status
+```
+
+### 2. 合并
+```bash
+git checkout main
+git merge --squash feature-branch
+git commit -m "feat: 变更描述"
+```
+
+### 3. 清理
+```bash
+git branch -d feature-branch
+git worktree remove ../project-feature  # 如果使用了 worktree
+```
+
+### 4. 归档变更
+```bash
+specpow archive <change-id>
+```
+
+## 红旗
+
+- 测试未通过 → 不合并
+- 有冲突未解决 → 先解决冲突
+- 未归档变更 → 完成归档

package/builtin/skills/execution-git-worktrees/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: execution-git-worktrees
+description: SpecPow execution-git-worktrees skill
+---
+
+# Git 工作树
+> 使用 git worktree 管理多个并行开发分支
+
+## 触发条件
+
+- 需要同时处理多个变更
+- 用户提到"工作树"/"worktree"/"并行开发"
+
+## 铁律
+
+1. **一树一分支** — 每个 worktree 对应独立分支
+2. **不共享 node_modules** — 每个工作树独立安装依赖
+3. **完成后清理** — 合并后删除 worktree
+
+## 工作流
+
+### 创建 worktree
+```bash
+git worktree add ../project-feature-a feature-a
+cd ../project-feature-a
+pnpm install
+```
+
+### 列出 worktree
+```bash
+git worktree list
+```
+
+### 删除 worktree
+```bash
+git worktree remove ../project-feature-a
+```
+
+## 适用场景
+
+- 同时开发多个需求
+- 紧急修复需要中断当前工作
+- 对比不同分支的实现
+
+## 红旗
+
+- worktree 超过 5 个 → 清理不用的
+- 忘记切回主 worktree → 注意当前工作目录

package/builtin/skills/execution-parallel-agents/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: execution-parallel-agents
+description: 并行子代理调度。识别独立问题域，并行分发多个子代理同时处理。来自 Superpowers。
+---
+
+# 并行代理调度
+
+## 何时使用
+
+- 有多个独立的问题域
+- 问题之间没有依赖关系
+- 想要加速处理
+
+## 流程
+
+### 1. 识别独立性
+分析问题，识别可以独立处理的子问题：
+- 不同的文件/模块
+- 不同的功能点
+- 不同的关注点（前端/后端/测试）
+
+### 2. 验证独立性
+确保子问题之间：
+- 不修改同一个文件
+- 不依赖彼此的输出
+- 接口已经定义清楚
+
+### 3. 并行分发
+
+为每个子问题分发一个子代理：
+- 每个子代理有独立的上下文
+- 每个子代理有明确的范围
+- 每个子代理有验证标准
+
+### 4. 合并结果
+
+所有子代理完成后：
+- 检查是否有冲突
+- 运行完整测试套件
+- 集成验证
+
+## 注意事项
+
+- **绝不**并行修改同一个文件
+- 合并后必须运行完整测试
+- 如果子代理之间有依赖，改用串行

package/builtin/skills/execution-receiving-review/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: execution-receiving-review
+description: SpecPow execution-receiving-review skill
+---
+
+# 接收审查
+
+> 收到代码审查反馈后的正确处理流程
+
+## 触发条件
+
+- 收到审查意见/评论
+- PR/MR 有审查反馈
+- 用户提到"处理审查"/"审查反馈"
+
+## 铁律
+
+1. **不辩解** — 审查意见是改进机会，不是攻击
+2. **逐条回应** — 每个 Finding 都要回复
+3. **修复优先** — Critical/Major 必须修复
+4. **不扩大范围** — 只修复审查指出的问题
+
+## 处理流程
+
+### 1. 分类反馈
+- Critical → 立即修复
+- Major → 本轮修复
+- Minor → 本轮修复或标注后续处理
+- Suggestion → 评估后决定
+
+### 2. 修复
+- 每个修复单独 commit
+- commit message 引用 Finding ID
+
+### 3. 回应
+```
+✅ [Critical] SQL 注入 → 已修复 (commit abc123)
+✅ [Major] 缺少事务 → 已修复 (commit def456)
+⏳ [Minor] 命名优化 → 下个迭代处理
+📝 [Suggestion] 重构 → 超出本次范围，记录到 backlog
+```
+
+## 红旗
+
+- 忽略 Critical → 必须修复
+- 反驳审查而不修改 → 重新评估
+- 修复引入新问题 → 回退并重新修复

package/builtin/skills/execution-requesting-review/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: execution-requesting-review
+description: SpecPow execution-requesting-review skill
+---
+
+# 请求审查
+
+> 在完成任务后，正确请求代码审查
+
+## 触发条件
+
+- 任务完成后需要请求审查
+- 准备提交 PR/MR
+- 用户提到"请求审查"/"review"
+
+## 铁律
+
+1. **自审先行** — 先自己审查一遍再请求他人
+2. **上下文充分** — 提供变更背景和影响范围
+3. **范围明确** — 指明需要重点审查的部分
+
+## 审查请求模板
+
+```markdown
+## 审查请求
+
+### 变更概述
+- 变更 ID: xxx
+- 影响范围: [文件列表]
+- 变更类型: [新功能/修复/重构]
+
+### 自审结果
+- [ ] 代码编译通过
+- [ ] 测试通过
+- [ ] 无 lint 警告
+- [ ] 文档已更新
+
+### 重点审查
+1. [文件:行号] — 请确认逻辑正确性
+2. [文件:行号] — 请确认性能可接受
+
+### 背景信息
+- 相关需求: [链接]
+- 技术决策: [说明]
+```
+
+## 红旗
+
+- 未自审就请求审查 → 先自审
+- 变更超过 500 行 → 拆分变更
+- 无测试 → 补充测试后再请求