congsh/workFlowSkill
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

初始化自动化开发工作流技能库

Browse Source
This commit is contained in:
锦麟 王
2026-04-27 17:45:20 +08:00
commit 0cce68b38c
11 changed files with 1613 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+16
View File
@@ -0,0 +1,16 @@
# 系统文件
.DS_Store
Thumbs.db
# IDE
.vscode/
.idea/
*.swp
*.swo
# 临时文件
*.tmp
*.temp
# 日志
*.log
README.md
+164
View File
@@ -0,0 +1,164 @@
# 自动化开发工作流技能库
> 基于 Claude Code 的自动化开发全流程技能集合，覆盖需求 → 审核 → 设计 → TDD → 计划 → 开发 → 测试 → 交付的完整闭环。
## 技能清单
| 技能 | 指令 | 说明 | 阶段 |
|------|------|------|------|
| dev-workflow | `/dev-workflow` | 工作流总控，管理全流程进度 | 总控 |
| dev-requirement | `/dev-requirement` | 需求分析，产出需求文档 | 第 1 阶段 |
| dev-review | `/dev-review` | 需求审核，过滤无关/复杂需求 | 第 2 阶段 |
| dev-design | `/dev-design` | 技术设计与选型 | 第 3 阶段 |
| dev-tdd | `/dev-tdd` | 测试先行，生成测试骨架 | 第 4 阶段 |
| dev-plan | `/dev-plan` | 步骤分解，定义验收标准 | 第 5 阶段 |
| dev-develop | `/dev-develop` | 开发执行，让测试变绿 | 第 6 阶段 |
| dev-test | `/dev-test` | 测试验证，代码审核 | 第 7 阶段 |
| dev-deliver | `/dev-deliver` | 交付发布 + 反馈闭环 | 第 8 阶段 |
## 安装方式
### 安装整个技能库
```bash
npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --all
```
### 安装单个技能
```bash
# 安装主控技能
npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --skill dev-workflow
# 安装需求分析技能
npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --skill dev-requirement
```
### 全局安装（推荐）
```bash
npx skills add http://jiulu-gameplay.com.cn:13001/congsh/workFlowSkill.git --all -g -y
```
## 快速开始
安装完成后，在项目目录中：
```bash
# 启动工作流
claude /dev-workflow
# 或直接启动某个阶段
claude /dev-requirement
```
## 权限配置
为获得最佳自动化体验，建议配置权限等级：
```bash
# 开发模式：常用命令自动批准
cp .claude/permissions/level-3-dev.json .claude/settings.json
```
## 工作流流程
```
╔═════════════════════════════════════════════════════════════════════════╗
║ 自动化开发工作流 ║
╚═════════════════════════════════════════════════════════════════════════╝
┌───────────────┐
│ 需求收集 │ /dev-requirement
│ 产出文档 │ docs/requirements/
└───────────────┘
│
▼
┌───────────────┐
│ 需求审核 │ /dev-review
│ 通过/拒绝/ │ docs/reviews/
│ 上报决策 │
└───────────────┘
│
▼
┌───────────────┐
│ 技术设计 │ /dev-design
│ 架构与选型 │ docs/design/
└───────────────┘
│
▼
┌───────────────┐
│ TDD测试 │ /dev-tdd
│ 先行 │ docs/test-cases/
└───────────────┘
│
▼
┌───────────────┐
│ 步骤分解 │ /dev-plan
│ 验收标准 │ docs/plans/
└───────────────┘
│
▼
┌───────────────┐
│ 开发执行 │ /dev-develop
│ 让测试变绿 │ docs/dev-logs/
└───────────────┘
│
▼
┌───────────────┐
│ 测试验证 │ /dev-test
│ 审核+测试 │ docs/test-reports/
└───────────────┘
│
▼
┌───────────────┐
│ 交付发布 │ /dev-deliver
│ +反馈闭环 │ docs/deliverables/
└───────────────┘
│
└──────────┐
▼
┌────────────┐
│ 人工反馈 │
│ 驱动迭代 │
└────────────┘
```
## 更新技能
```bash
# 更新本库所有技能
npx skills update workFlowSkill -y
# 检查是否有更新
npx skills check
```
## 目录结构
```
workFlowSkill/
├── README.md
├── .gitignore
├── dev-workflow/SKILL.md # 工作流总控
├── dev-requirement/SKILL.md # 需求分析
├── dev-review/SKILL.md # 需求审核
├── dev-design/SKILL.md # 技术设计
├── dev-tdd/SKILL.md # TDD测试先行
├── dev-plan/SKILL.md # 步骤分解
├── dev-develop/SKILL.md # 开发执行
├── dev-test/SKILL.md # 测试验证
└── dev-deliver/SKILL.md # 交付发布
```
## 外部工具占位（后续接入）
| 功能 | 当前占位 | 后续替换 |
|------|---------|---------|
| 工单状态同步 | `docs/processed-requirements.md` | 工单系统 API |
| 上报决策人 | `docs/reviews/pending/` | 邮件 MCP / Webhook |
| 定时触发 | 无 | 外部脚本 + Claude CLI |
## License
MIT
dev-deliver/SKILL.md
+219
View File
@@ -0,0 +1,219 @@
---
name: dev-deliver
description: 开发流程 - 交付阶段，生成接口文档、使用文档、部署文档等交付物
---
# 交付
> 开发流程第六阶段：基于实际代码和文档生成交付文档。
## 调用方式
`/dev-deliver`，也可说"生成交付文档"或"准备交付"。
## 产出目录
`docs/deliverables/`
## 执行流程
### Checklist
- [ ] 前置检查：读取所有前序产出物
- [ ] 生成接口文档
- [ ] 生成使用文档
- [ ] 生成部署文档
- [ ] 生成变更摘要
- [ ] 用户审阅并保存
### 1. 前置检查
读取所有前序阶段的产出物：
- `docs/requirements/` — 需求文档
- `docs/design/` — 设计文档
- `docs/plans/` — 步骤计划
- `docs/dev-logs/` — 开发日志
- `docs/test-reports/` — 测试报告
如果某些阶段缺失，提示用户但不阻止执行。基于已有信息生成交付文档。
### 2. 生成接口文档
**基于实际代码扫描：**
- 读取项目源代码文件
- 识别 API 端点、路由定义
- 提取函数签名和参数
- 识别请求/响应格式
- 提取错误码定义
**生成格式：**
```markdown
## 接口文档
### API 接口 N：<名称>
**方法**：POST
**路径**：/api/xxx
**描述**：xxx
**请求参数**：
| 参数 | 类型 | 必填 | 描述 |
|------|------|------|------|
**响应格式**：
[实际响应结构]
**错误码**：
| 错误码 | 描述 |
|--------|------|
```
如果项目不是 API/库类型，调整为文档对应的接口形式（函数接口、模块接口等）。
### 3. 生成使用文档
**基于项目配置文件：**
- 读取 package.json / pyproject.toml / Makefile 等
- 识别依赖和版本要求
- 提取安装/构建命令
- 读取配置文件示例
**生成格式：**
```markdown
## 使用文档
### 环境要求
- Node.js >= 18
- npm >= 9
### 安装
[实际安装命令]
### 配置
[实际配置说明]
### 基本用法
[使用示例]
```
### 4. 生成部署文档
**基于项目结构和配置：**
- 识别部署相关文件（Dockerfile、docker-compose.yml 等）
- 提取环境变量定义
- 识别外部依赖服务
- 提取构建和部署命令
**生成格式：**
```markdown
## 部署文档
### 环境变量
| 变量名 | 必填 | 描述 | 默认值 |
|--------|------|------|--------|
### 部署步骤
1. xxx
2. yyy
### 依赖服务
- 数据库：xxx
- 缓存：xxx
```
### 5. 生成变更摘要
**基于需求文档和开发日志：**
```markdown
## 变更摘要
### 新增
- 功能 A（涉及文件：src/xxx.ts）
### 修改
- 功能 B 优化（涉及文件：src/yyy.ts）
### 已知问题
- [问题 1]：描述及临时解决方案
```
### 6. 用户审阅
- 将完整交付文档展示给用户
- 分段确认：接口文档 → 使用文档 → 部署文档 → 变更摘要
- 收集反馈并修改
- 循环直到用户确认
### 7. 保存文档
按以下格式保存完整交付文档：
```markdown
# 交付文档：<项目名称>
> 创建日期：YYYY-MM-DD
> 版本：1.0.0
> 状态：已交付
## 1. 项目概览
## 2. 接口文档
## 3. 使用文档
## 4. 部署文档
## 5. 变更摘要
```
保存到 `docs/deliverables/YYYY-MM-DD-<项目名>.md`
### 8. 发布执行（可选）
根据项目类型，询问用户是否需要执行发布操作：
```
是否执行发布操作？
[1] git tag + push
[2] npm publish / docker push
[3] 跳过，仅保留文档
```
如选择发布，协助用户执行对应的命令（通过 Bash tool），并记录操作日志。
### 9. 反馈收集（闭环）
交付完成后，收集本轮开发的反馈：
```markdown
## 反馈记录
> 对应交付：docs/deliverables/xxx.md
> 反馈日期：YYYY-MM-DD
### 评分（1-5）
- 需求理解准确度：
- 实现符合预期度：
- 整体满意度：
### 问题与优化点
- [ ] 问题 1
- [ ] 问题 2
### 是否启动新一轮迭代
- [ ] 是 → 更新 workflow-status.md 为"需求分析"阶段
- [ ] 否 → 标记流程结束
```
保存到 `docs/feedback/YYYY-MM-DD-<项目名>.md`。
更新 `docs/workflow-status.md`：
- 如用户选择迭代：当前阶段 = "需求分析"，提示 `/dev-requirement`
- 如用户结束：状态 = "已完成"
## 关键行为
- 接口文档必须基于实际代码，不凭空编造
- 环境变量从代码中实际提取（搜索 process.env、os.environ 等）
- 部署步骤基于项目实际配置（Dockerfile、CI/CD 等）
- 如无法从代码提取，明确标注"需手动补充"
dev-design/SKILL.md
+127
View File
@@ -0,0 +1,127 @@
---
name: dev-design
description: 开发流程 - 设计阶段，技术选型与细节设计，产出设计文档
---
# 设计
> 开发流程第二阶段：基于需求文档进行技术选型和细节设计。
## 调用方式
`/dev-design`，也可说"开始设计"。
## 产出目录
`docs/design/`
## 执行流程
### Checklist
- [ ] 前置检查：读取需求文档
- [ ] 探索现有代码库
- [ ] 技术选型
- [ ] 前端风格设计（如涉及）
- [ ] 细节设计循环
- [ ] 用户确认并保存
### 1. 前置检查
- 读取 `docs/requirements/` 目录下的需求文档
- 如果不存在，提示用户先运行 `/dev-requirement` 完成需求分析
- 用户可选择跳过（直接进入设计）
- 展示需求文档摘要，确认设计范围
### 2. 探索现有代码库
- 查看项目文件结构
- 识别现有技术栈（package.json、pyproject.toml 等）
- 了解现有架构模式
- 识别可复用的模块和接口
### 3. 技术选型
识别需要做出的技术决策，逐个讨论：
**规则：**
- 每个决策点提出 2-3 个方案
- 说明每个方案的优缺点
- 给出推荐方案和理由
- 使用多选方式让用户选择
**常见决策点：**
- 框架选择
- 数据库/存储方案
- 状态管理方案
- API 风格（REST/GraphQL/RPC）
- 认证方案
### 4. 前端风格设计（如涉及）
如果项目涉及 UI：
- 询问视觉风格偏好
- 确定配色方案、字体、间距规范
- 确定组件库（如有）
- 确定布局模式
如果项目不涉及 UI，跳过此步骤。
### 5. 细节设计循环
按以下维度逐个展开设计，每个维度分段展示给用户确认：
**模块划分：**
- 将系统拆分为职责单一的模块
- 每个模块有清晰的边界和接口
**数据模型：**
- 核心数据结构定义
- 数据关系
- 存储方案
**接口设计：**
- 模块间接口 / API 端点
- 输入输出规范
- 错误码定义
**错误处理：**
- 异常场景识别
- 错误处理策略
- 边界情况处理
### 6. 保存设计文档
按以下模板保存：
```markdown
# 设计文档：<项目名称>
> 创建日期：YYYY-MM-DD
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 状态：已确认
## 1. 技术选型
| 决策点 | 选择 | 理由 | 备选方案 |
|-------|------|------|---------|
## 2. 架构设计
### 整体架构
### 模块划分
| 模块 | 职责 | 依赖 |
|------|------|------|
## 3. 数据模型
## 4. 接口设计
## 5. 前端设计（如适用）
## 6. 错误处理与边界情况
```
保存为 `docs/design/YYYY-MM-DD-<项目名>.md`，提示下一步可调用 `/dev-tdd` 生成测试用例（测试先行）。
## 关键行为
- 技术选型基于项目实际约束，不盲目追求新技术
- 设计文档中的每个需求都能追溯到需求文档
- 前端风格仅在涉及 UI 时展开
- 模块划分遵循单一职责原则
dev-develop/SKILL.md
+132
View File
@@ -0,0 +1,132 @@
---
name: dev-develop
description: 开发流程 - 开发执行阶段，按步骤执行开发并逐条验证验收标准
---
# 开发执行
> 开发流程第四阶段：按步骤计划执行开发，每步完成后验证验收标准。
## 调用方式
`/dev-develop`，也可说"开始开发"。
支持指定步骤：`/dev-develop 步骤3` 或 `/dev-develop 3`
## 产出目录
`docs/dev-logs/`
## 执行流程
### Checklist
- [ ] 前置检查：读取步骤计划
- [ ] 读取/创建开发日志
- [ ] 步骤执行循环（对每个步骤）
- [ ] 生成完整开发日志
### 1. 前置检查
- 读取 `docs/plans/` 目录下的步骤计划
- 如果不存在，提示用户先运行 `/dev-plan`（用户可选择跳过，直接开始开发）
- 展示步骤概览和进度
### 2. 读取/创建开发日志
- 检查 `docs/dev-logs/` 是否已有本次开发日志
- 如果有：读取进度，从未完成的步骤继续
- 如果没有：创建新的开发日志
开发日志格式：
```markdown
# 开发日志：<项目名称>
> 创建日期：YYYY-MM-DD
> 对应计划：docs/plans/YYYY-MM-DD-xxx.md
> 状态：进行中
## 进度概览
| # | 步骤 | 状态 | 完成时间 |
|---|------|------|---------|
| 1 | xxx | ✅ 已完成 | HH:MM |
| 2 | yyy | 🔄 进行中 | - |
| 3 | zzz | ⏳ 待执行 | - |
---
## 步骤 N：xxx
**开始时间**：HH:MM
**完成时间**：HH:MM
**执行内容**：
- 创建了 src/xxx.ts
- 修改了 src/yyy.ts
**验收结果**：
- [x] 标准 1：通过（附验证命令输出）
- [x] 标准 2：通过
**备注**：
[任何偏离计划的情况]
```
### 3. 步骤执行循环
对每个待执行的步骤：
**3a. 展示步骤详情**
- 展示当前步骤的目标、具体任务和验收标准
- 确认用户准备开始
**3b. 执行开发任务**
- 按步骤计划中的任务项逐一执行
- 编写/修改代码，保持简洁
- 不添加计划之外的功能
**3c. 自动运行检查**
- 检查是否有 lint 配置，有则运行
- 检查是否有 type check 配置，有则运行
- 检查是否有 build 命令，有则运行
- 运行现有测试（如有）
- 如果检查失败，修复后重新运行
**3d. 逐条验证验收标准**
- 对照步骤计划中的每条验收标准
- 展示每条标准的验证方式和结果
- 对于命令行验证：展示命令输出
- 对于文件检查：展示文件内容
- 对于功能验证：描述验证过程
**3e. 用户确认**
- 展示所有验收标准的验证结果
- 询问用户是否确认通过
- **通过**：标记步骤完成，更新开发日志，进入下一步
- **未通过**：根据反馈修复，重新验证，回到 3d
### 4. 完成开发日志
所有步骤完成后：
- 更新开发日志状态为"已完成"
- 记录总体完成时间
- 保存到 `docs/dev-logs/YYYY-MM-DD-<项目名>.md`
- 提示下一步可调用 `/dev-test` 进行测试
## 断点续做
如果开发中途退出（会话结束），下次启动 `/dev-develop` 时：
- 自动读取开发日志
- 识别最后一个"进行中"的步骤
- 询问用户是从该步骤重新开始，还是继续下一步
- 支持用户指定任意步骤：`/dev-develop 3`
## 关键行为
- 每个步骤开始前明确展示目标，不盲目动手
- 验收标准逐条核对，不自评"通过"
- 用户确认后才进入下一步，不跳过
- 遇到问题及时反馈，不强行继续
- 代码修改保持简洁，不添加计划外的增强
dev-plan/SKILL.md
+123
View File
@@ -0,0 +1,123 @@
---
name: dev-plan
description: 开发流程 - 步骤分解阶段，将设计拆解为可验证的实施步骤
---
# 步骤分解
> 开发流程第三阶段：将设计拆解为可验证的实施步骤，每步提供验收标准。
## 调用方式
`/dev-plan`，也可说"分解步骤"或"制定开发计划"。
## 产出目录
`docs/plans/`
## 执行流程
### Checklist
- [ ] 前置检查：读取需求和设计文档
- [ ] 分析设计，识别实现步骤
- [ ] 定义每个步骤的验收标准
- [ ] 展示完整步骤列表
- [ ] 用户确认并保存
### 1. 前置检查
- 读取 `docs/requirements/` 和 `docs/design/`
- 如果任一目录为空，提示用户先完成对应阶段（可选择跳过）
- 展示需求和设计摘要，确认分解范围
### 2. 分析设计，识别步骤
基于设计文档的模块划分和架构，将实现工作拆解为步骤。
**拆解原则：**
- 每个步骤必须**可独立验证**
- 步骤粒度：一个步骤应能在一次开发会话中完成
- 优先按依赖关系排序：基础模块先于上层模块
- 同一模块的相关任务归为同一步骤
### 3. 定义验收标准
为每个步骤定义验收标准。
**验收标准要求：**
- **可客观判断**：能通过命令执行、文件检查或视觉确认
- **具体明确**：不使用"基本完成"、"大致可用"等模糊描述
- **可演示**：每个步骤完成后都能展示具体成果
**好的验收标准示例：**
```
- [ ] 执行 `npm run build` 无错误
- [ ] 访问 /api/users 返回 200 和用户列表 JSON
- [ ] 用户可以点击"添加"按钮并在列表中看到新条目
```
**不好的验收标准示例：**
```
- [ ] 基本功能可用
- [ ] 接口设计完成
```
### 4. 展示步骤列表
按以下格式展示完整计划：
```markdown
# 实施计划：<项目名称>
> 创建日期：YYYY-MM-DD
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 对应设计：docs/design/YYYY-MM-DD-xxx.md
> 状态：待执行
## 步骤概览
| # | 步骤名称 | 依赖 | 状态 |
|---|---------|------|------|
| 1 | xxx | 无 | 待执行 |
---
## 步骤 N：<标题>
**目标**：一句话描述
**具体任务**：
- [ ] 任务项 1
- [ ] 任务项 2
**验收标准**：
- [ ] 标准 1（可验证描述）
- [ ] 标准 2
**涉及文件**：
- src/xxx.ts（新建/修改）
**预估复杂度**：低/中/高
---
## 依赖关系图
步骤 1 → 步骤 2, 3 → 步骤 4
```
### 5. 用户确认
- 展示完整步骤列表
- 询问是否需要调整（合并、拆分、重排序）
- 修改后循环展示直到用户确认
- 保存为 `docs/plans/YYYY-MM-DD-<项目名>.md`
- 提示下一步可调用 `/dev-develop` 开始开发
## 关键行为
- 验收标准是步骤分解的核心，必须可验证
- 步骤之间依赖关系必须明确，无循环依赖
- 不遗漏设计文档中的任何模块或接口
- 步骤数量适中（通常 3-10 个），避免过度拆分
dev-requirement/SKILL.md
+125
View File
@@ -0,0 +1,125 @@
---
name: dev-requirement
description: 开发流程 - 需求分析阶段，通过探讨和澄清循环产出需求文档
---
# 需求分析
> 开发流程第一阶段：通过探讨 → 产出 → 澄清循环，产出满意的需求文档。
## 调用方式
`/dev-requirement` 或 `/dev-req`，也可说"开始需求分析"。
支持传入需求来源：`/dev-requirement docs/idea.md` 或 `/dev-requirement Issue#42`。
## 产出目录
`docs/requirements/`
## 执行流程
### Checklist
- [ ] 探索项目上下文
- [ ] 收集原始需求
- [ ] 探讨循环（澄清问题）
- [ ] 产出需求文档
- [ ] 用户确认并保存
### 1. 探索项目上下文
启动后首先了解当前项目状态：
- 读取项目根目录的文件结构
- 查看现有文档（README、CLAUDE.md 等）
- 查看最近的 git 提交（如有）
- 查看是否已有 `docs/requirements/` 目录下的需求文档
### 2. 收集原始需求
根据用户输入获取需求来源：
- 如果传入文件路径，读取该文件作为原始需求
- 如果传入 Issue 编号，尝试读取 Issue 内容
- 如果无参数，询问用户描述需求
### 3. 探讨循环
参考 superpowers:brainstorming 的核心模式：
**规则：**
- 一次只问一个澄清问题
- 优先使用多选选项向用户提问
- 提出 2-3 个方案供选择时，说明权衡和推荐
- YAGNI 原则：主动去掉不必要的需求
- 不要自作主张添加用户没提到的需求
**探讨内容：**
- 业务背景和目标
- 用户角色和使用场景
- 核心功能需求
- 非功能需求（性能、安全等）
- 约束和假设
- 范围边界（包含/不包含）
**退出条件：** 你已充分理解以下内容：
- 为什么做这个项目
- 谁是目标用户
- 核心功能有哪些
- 成功标准是什么
### 4. 产出需求文档
按以下模板生成需求文档，分段展示给用户审阅：
```markdown
# 需求文档：<项目名称>
> 创建日期：YYYY-MM-DD
> 状态：已确认
## 1. 背景与目标
### 业务背景
### 核心目标
### 成功指标
## 2. 功能需求
（每个需求用用户故事格式）
### 用户故事 N
**作为** [角色]，**我想要** [功能]，**以便** [价值]
验收条件：
- [ ] 条件 1
## 3. 非功能需求
- 性能：
- 安全：
- 兼容性：
- 可维护性：
## 4. 约束与假设
### 技术约束
### 业务假设
## 5. 范围说明
### 包含
### 不包含
```
**审阅规则：**
- 每展示一段后询问是否满意
- 收集反馈后修改，进入下一轮展示
- 循环直到用户确认整体满意
### 5. 保存文档
- 确保 `docs/requirements/` 目录存在
- 保存为 `docs/requirements/YYYY-MM-DD-<项目名>.md`
- 告知用户文件位置，提示下一步可调用 `/dev-review` 进行需求审核
## 关键行为
- 探讨阶段不急躁，确保充分理解后再产出
- 产出时不遗漏探讨中确认的任何需求点
- 文档中的每个需求都有对应的验收条件
- 范围说明中的"不包含"要明确列出并说明原因
dev-review/SKILL.md
+218
View File
@@ -0,0 +1,218 @@
---
name: dev-review
description: 开发流程 - 需求审核阶段，评估需求相关性、复杂度与可行性，决定推进、拒绝或上报决策
---
# 需求审核
> 开发流程第二阶段：审核需求的相关性、复杂度与可行性，过滤无关需求，拦截复杂/高风险需求上报决策。
## 调用方式
`/dev-review`，也可说"审核需求"。
## 产出目录
`docs/reviews/`（审核通过的记录）
`docs/reviews/pending/`（待决策的审核记录）
## 执行流程
### Checklist
- [ ] 前置检查：读取需求文档
- [ ] 相关性评估
- [ ] 复杂度评估
- [ ] 可行性评估
- [ ] 生成审核结论
- [ ] 更新状态（避免重复触发）
- [ ] 上报决策人（如需要，外部工具占位）
### 1. 前置检查
- 读取 `docs/requirements/` 目录下最新的需求文档
- 读取 `docs/processed-requirements.md` 已处理需求清单（如存在）
- 检查该需求是否已在处理中或已处理，避免重复审核
- 如未找到需求文档，提示用户先运行 `/dev-requirement`
### 2. 相关性评估
判断需求是否属于本系统的业务范围。
**评估标准：**
- 需求的功能领域是否在本系统职责范围内
- 是否涉及本系统已有模块的合理扩展
- 是否属于本团队/项目的维护范围
**结论：**
- **相关** → 继续下一步评估
- **无关** → 直接拒绝，记录原因
### 3. 复杂度评估
评估需求的技术实现复杂度。
| 等级 | 判断标准 | 处理方式 |
|------|---------|---------|
| 简单 | 现有模式直接套用，无新架构 | 直接通过 |
| 中等 | 需要新模块或接口设计，但技术路径清晰 | 直接通过 |
| 复杂 | 涉及架构变更、跨系统协调、性能敏感场景 | 标记需决策 |
**触发"需决策"的典型情况：**
- 需要引入新的技术栈或基础设施
- 涉及大量数据迁移或兼容性问题
- 需要与其他团队/系统协调接口
- 性能要求超出当前架构能力
- 安全合规风险较高
### 4. 可行性评估
检查需求在当前约束下是否可行。
**评估维度：**
- **技术约束**：现有技术栈是否支持
- **资源约束**：人力、时间是否足够
- **依赖约束**：是否依赖外部系统/团队
- **合规约束**：是否符合安全/合规要求
### 5. 生成审核结论
三种结论，只能有一种：
#### A. 通过
需求属于本系统范围，复杂度在可控范围内，可直接进入设计阶段。
**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md`
```markdown
# 需求审核报告
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD
## 审核结论：通过
## 评估详情
### 相关性：相关
[说明]
### 复杂度：简单/中等
[说明]
### 可行性：可行
[说明]
## 建议下一步
进入设计阶段：`/dev-design`
```
#### B. 拒绝
需求与本系统无关，或技术上不可行。
**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md`
```markdown
# 需求审核报告
## 审核结论：拒绝
## 拒绝原因
- 原因 1
- 原因 2
## 建议
[转交给哪个系统/团队，或建议用户如何调整]
```
**操作：**
- 将需求标记为"已拒绝"
- 更新 `docs/processed-requirements.md`
- 告知用户流程终止，不进入后续阶段
#### C. 需决策
需求相关但复杂度过高或存在不确定性，需要上报决策人评估。
**产出：** `docs/reviews/pending/YYYY-MM-DD-<项目名>-pending.md`
```markdown
# 待决策需求上报
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD
## 需决策事项
| # | 问题 | 影响 | 建议方案 |
|---|------|------|---------|
| 1 | 涉及架构变更 | 影响现有模块 A、B | 方案 X / 方案 Y |
| 2 | 需要跨团队协作 | 依赖团队 C 的接口 | 先协调再排期 |
## 复杂度评估
[详细说明]
## 推荐决策
[给出倾向性建议]
```
### 6. 更新状态（避免重复触发）
**当前实现（文件占位）：**
更新 `docs/processed-requirements.md`：
```markdown
# 已处理需求清单
| 需求文件 | 审核结论 | 状态 | 处理日期 |
|---------|---------|------|---------|
| YYYY-MM-DD-xxx.md | 通过 | 处理中 | YYYY-MM-DD |
| YYYY-MM-DD-yyy.md | 拒绝 | 已关闭 | YYYY-MM-DD |
| YYYY-MM-DD-zzz.md | 需决策 | 待决策 | YYYY-MM-DD |
```
**后续替换（外部工具接入时）：**
```
# TODO: 接入工单系统 API
# - 通过的工单：调用 set_status(ticket_id, "处理中")
# - 拒绝的工单：调用 set_status(ticket_id, "已拒绝")
# - 需决策的工单：调用 set_status(ticket_id, "待决策")
```
### 7. 上报决策人（外部工具占位）
对于"需决策"的需求，当前流程：
1. 生成 `docs/reviews/pending/xxx-pending.md`
2. 展示给用户，说明需要上报的内容
3. **提示用户手动转发给决策人**
**后续替换（外部工具接入时）：**
```
# TODO: 接入通知渠道
# 方案 A：邮件 MCP server
# - 调用 send_email(decision_maker, subject, content)
# 方案 B：企业微信/钉钉 Webhook
# - 调用 send_webhook(url, message)
# 方案 C：工单系统内置通知
# - 调用 add_comment(ticket_id, "@决策人 请审核")
```
## 流转规则
| 审核结论 | 下一步 | 状态 |
|---------|--------|------|
| 通过 | `/dev-design` | 处理中 |
| 拒绝 | 流程终止 | 已关闭 |
| 需决策 | 等待外部反馈，之后重新 `/dev-review` | 待决策 |
## 关键行为
- 审核不通过时明确说明原因，给出替代建议
- "需决策"不是拒绝，而是暂停等待更多信息
- 每次审核都记录到 `processed-requirements.md`，确保不重复处理
- 用户可覆盖审核结论（强制推进），但记录覆盖原因
dev-tdd/SKILL.md
+169
View File
@@ -0,0 +1,169 @@
---
name: dev-tdd
description: 开发流程 - TDD 测试先行阶段，基于设计文档生成测试骨架，实现测试驱动开发
---
# TDD 测试先行
> 开发流程第四阶段：基于设计文档生成测试骨架，先写测试再写实现，确保验收标准可量化。
## 调用方式
`/dev-tdd`，也可说"生成测试用例"或"TDD"。
## 产出目录
`docs/test-cases/`（测试用例设计文档）
项目源码中的测试文件（`.test.ts` / `.spec.ts` / `_test.py` 等）
## 执行流程
### Checklist
- [ ] 前置检查：读取需求和设计文档
- [ ] 检测项目测试框架
- [ ] 按模块识别测试点
- [ ] 生成测试用例文档
- [ ] 生成测试代码骨架（空实现 / 先失败）
- [ ] 验证测试可运行且初始状态为失败
- [ ] 用户确认
### 1. 前置检查
- 读取 `docs/requirements/` 需求文档
- 读取 `docs/design/` 设计文档（模块划分、接口定义、数据模型）
- 如果设计文档不存在，提示用户先运行 `/dev-design`（可选择跳过，基于需求直接生成）
- 展示设计摘要，确认测试生成范围
### 2. 检测项目测试框架
自动检测项目使用的测试框架：
| 语言 | 检测方式 | 常用框架 |
|------|---------|---------|
| JavaScript/TypeScript | package.json devDependencies | jest, vitest, mocha, playwright |
| Python | pyproject.toml / requirements.txt | pytest, unittest |
| Java | pom.xml / build.gradle | JUnit, TestNG |
| Go | go.mod | testing, testify |
| Rust | Cargo.toml | 内置 test |
如果没有检测到测试框架：
- 询问用户是否安装（推荐 Vitest 或 Jest 用于 JS/TS，pytest 用于 Python）
- 如用户拒绝，生成 `docs/test-cases/` 下的纯文本测试用例文档，不生成代码
### 3. 按模块识别测试点
基于设计文档的模块划分，为每个模块识别测试点：
**每个模块的测试点维度：**
- **正常路径**：标准输入下的预期输出
- **边界情况**：空值、最大值、最小值、空数组等
- **错误路径**：异常输入、权限不足、网络失败等
- **状态转换**：涉及状态机的模块，各状态转换路径
### 4. 生成测试用例文档
为每个模块生成测试用例设计文档，保存到 `docs/test-cases/`：
```markdown
# 测试用例设计：<模块名>
> 对应设计：docs/design/xxx.md
> 对应模块：模块 A
## 测试用例 1：正常路径 - [简短描述]
**目标**：验证标准场景下的正确行为
**输入**：[具体值或描述]
**预期输出**：[具体值或描述]
**涉及接口**：[函数/端点名]
**优先级**：高
## 测试用例 2：边界情况 - [简短描述]
**目标**：验证边界输入的处理
**输入**：[边界值]
**预期输出**：[预期行为]
**优先级**：中
## 测试用例 3：错误路径 - [简短描述]
**目标**：验证异常情况的处理
**输入**：[异常输入]
**预期输出**：[错误码/异常类型]
**优先级**：中
```
### 5. 生成测试代码骨架
基于检测到的测试框架，生成实际的测试代码文件：
**原则：**
- 每个测试用例对应一个测试函数
- 测试函数名清晰描述场景：`should_xxx_when_xxx`
- 导入被测模块（根据设计文档中的接口定义）
- 使用 `todo()` 或 `skip()` 标记尚未实现的测试，或先写失败的断言
- 不编写被测模块的实现代码
**示例（Vitest / TypeScript）：**
```typescript
// src/modules/user/user.service.test.ts
import { describe, it, expect } from 'vitest'
import { UserService } from './user.service'
describe('UserService', () => {
describe('创建用户', () => {
it('should create user with valid input', () => {
// TODO: 实现测试
// const service = new UserService()
// const result = service.create({ name: '张三', email: 'zs@example.com' })
// expect(result.name).toBe('张三')
expect(true).toBe(false) // 初始状态：失败
})
it('should reject empty name', () => {
// TODO: 实现测试
expect(true).toBe(false) // 初始状态：失败
})
})
})
```
### 6. 验证测试可运行且失败
生成测试后：
- 运行测试框架（如 `npm test` / `pytest`）
- 确认测试可以被识别并执行
- 确认测试当前状态为**失败**（红）
- 如测试无法运行，修复配置问题（路径、导入、框架设置等）
### 7. 用户确认
- 展示生成的测试用例文档摘要
- 展示测试代码骨架的关键部分
- 展示测试运行结果（确认是失败的）
- 询问用户是否满意，或需要补充/修改测试场景
- 修改后循环直到确认
## 流转规则
生成完成后，提示下一步：
- `/dev-plan` — 将开发工作拆解为步骤（推荐）
- `/dev-develop` — 直接进入开发，让测试变绿
## 关键行为
- 测试用例必须能追溯到设计文档中的接口定义
- 测试初始状态必须为失败（红），不允许一开始就通过
- 不编写被测模块的实现代码，只写测试
- 测试函数名使用描述性语言，不依赖注释解释场景
- 如果设计文档中的接口不明确，先回到 `/dev-design` 澄清
## TDD 原则提醒
1. **红**：先写一个失败的测试
2. **绿**：写最小代码让测试通过
3. **重构**：优化代码，保持测试通过
本阶段只负责第 1 步（红）。第 2-3 步在 `/dev-develop` 中完成。
dev-test/SKILL.md
+182
View File
@@ -0,0 +1,182 @@
---
name: dev-test
description: 开发流程 - 测试阶段，包括代码审核、单模块测试和全流程测试
---
# 测试
> 开发流程第五阶段：代码审核 + 单模块测试 + 全流程测试。
## 调用方式
`/dev-test`，也可说"开始测试"。
## 产出目录
`docs/test-reports/`
## 执行流程
### 启动时选择
展示测试范围选择：
```
请选择测试范围：
[1] 完整测试流程（代码审核 → 模块测试 → 全流程测试）
[2] 仅代码审核
[3] 仅模块测试
[4] 仅全流程测试
```
使用多选方式让用户选择。
### Checklist
- [ ] 前置检查：读取计划和开发日志
- [ ] 阶段 A：代码审核（如选择）
- [ ] 阶段 B：单模块测试（如选择）
- [ ] 阶段 C：全流程测试（如选择）
- [ ] 生成测试报告
### 前置检查
- 读取 `docs/plans/` 和 `docs/dev-logs/`
- 确认开发已全部完成（所有步骤状态为"已完成"）
- 如果未完成，提示用户先运行 `/dev-develop` 完成剩余步骤
- 用户可选择跳过（对已完成部分进行测试）
### 阶段 A：代码审核
#### A1. 确定审核范围
- 从开发日志中提取所有修改/新建的文件列表
- 展示给用户确认
#### A2. 逐文件审核
对每个文件检查以下维度：
| 维度 | 检查内容 |
|------|---------|
| 安全性 | SQL 注入、XSS、命令注入、敏感信息泄露等 OWASP Top 10 |
| 性能 | N+1 查询、内存泄漏、不必要的同步操作、大数据量处理 |
| 代码规范 | 命名一致性、函数长度、代码重复 |
| 设计符合度 | 对照设计文档，检查实现是否符合设计 |
| 边界情况 | 空值处理、错误路径、并发场景 |
#### A3. 审核报告
产出审核结果：
```markdown
## 代码审核详情
### 审核文件列表
- src/xxx.ts
- src/yyy.ts
### 发现问题
| # | 文件 | 行号 | 严重度 | 描述 | 状态 |
|---|------|------|--------|------|------|
| 1 | xxx.ts | 42 | 高 | SQL 注入风险 | ⏳ 待修复 |
```
#### A4. 用户确认修复
- 展示审核发现的问题
- 与用户确认哪些需要修复
- 执行修复
- 修复后重新验证
### 阶段 B：单模块测试
#### B1. 框架检测
自动检测项目使用的测试框架：
- JavaScript/TypeScript：检查 package.json 中的 jest、vitest、mocha 等
- Python：检查 pytest、unittest 等
- 如果没有测试框架，询问用户是否需要安装
#### B2. 逐模块生成测试
按步骤计划中的模块划分：
- 为每个模块生成单元测试
- 测试覆盖：正常路径、边界情况、错误路径
- 生成测试代码后展示给用户确认
#### B3. 运行测试
- 执行生成的测试
- 展示测试结果
- 失败的测试进入修复循环：修复 → 重新运行 → 直到通过
#### B4. 测试结果记录
```markdown
## 模块测试详情
### 测试框架：Vitest
| 模块 | 测试文件 | 用例数 | 通过 | 失败 |
|------|---------|--------|------|------|
| 模块A | xxx.test.ts | 5 | 5 | 0 |
```
### 阶段 C：全流程测试
#### C1. 设计测试场景
基于需求文档中的用户故事设计端到端测试场景：
- 每个用户故事对应至少一个测试场景
- 场景应覆盖完整的用户操作流程
#### C2. 执行全流程测试
- 按场景逐步验证
- 检查模块间的协作是否正常
- 验证完整的数据流转
- 检查集成点（API 调用、数据库操作等）
#### C3. 记录结果
```markdown
## 全流程测试详情
### 场景 1：用户注册流程
- 步骤 1：打开注册页 ✅
- 步骤 2：填写表单 ✅
- 步骤 3：提交注册 ✅
- 步骤 4：验证成功 ✅
```
### 生成测试报告
汇总所有阶段的测试结果：
```markdown
# 测试报告：<项目名称>
> 创建日期：YYYY-MM-DD
> 对应计划：docs/plans/YYYY-MM-DD-xxx.md
> 状态：已完成
## 审核摘要
| 阶段 | 状态 | 发现问题 | 已修复 |
|------|------|---------|--------|
| 代码审核 | 完成 | N | N |
| 模块测试 | 完成 | N | N |
| 全流程测试 | 完成 | N | N |
```
保存到 `docs/test-reports/YYYY-MM-DD-<项目名>.md`，提示下一步可调用 `/dev-deliver` 生成交付文档。
## 关键行为
- 代码审核以设计文档为基准，检查实现是否符合设计
- 测试失败不跳过，必须修复后重新运行
- 全流程测试按用户故事场景组织，确保端到端可运行
- 兼容已有的 `automated-testing` 技能（框架检测和模板可复用）
dev-workflow/SKILL.md
+138
View File
@@ -0,0 +1,138 @@
---
name: dev-workflow
description: 自动化开发工作流主控，串联需求→设计→计划→开发→测试→交付全流程
---
# 自动化开发工作流
> 开发流程总控：管理全流程状态，引导用户按阶段推进，记录进度上下文。
## 调用方式
`/dev-workflow`，也可说"开始工作流"或"查看进度"。
支持指定阶段：`/dev-workflow 需求` 或 `/dev-workflow test`
## 状态文件
`docs/workflow-status.md`
## 执行流程
### 启动时
首先读取 `docs/workflow-status.md`（如存在），确定当前阶段和进度。如果不存在，创建新的状态文件。
### 阶段路由
根据用户输入或当前状态，引导至对应阶段：
| 阶段 | Skill 指令 | 说明 |
|------|-----------|------|
| 需求分析 | `/dev-requirement` | 收集并确认需求 |
| 需求审核 | `/dev-review` | 评估相关性、复杂度，决定推进/拒绝/上报 |
| 技术设计 | `/dev-design` | 技术选型与架构设计 |
| TDD 测试先行 | `/dev-tdd` | 基于设计生成测试骨架（先写测试） |
| 步骤分解 | `/dev-plan` | 将开发工作拆解为可执行步骤 |
| 开发执行 | `/dev-develop` | 按步骤执行开发，让测试变绿 |
| 测试验证 | `/dev-test` | 代码审核、模块测试、全流程测试 |
| 交付发布 | `/dev-deliver` | 发布操作 + 生成交付文档 + 收集反馈 |
### 状态跟踪
状态文件格式：
```markdown
# 工作流状态
> 项目：[项目名]
> 创建日期：YYYY-MM-DD
> 最后更新：YYYY-MM-DD HH:MM
## 阶段进度
| 阶段 | 状态 | 完成时间 | 产出文件 |
|------|------|---------|---------|
| 需求分析 | ⏳ 未开始 / ✅ 已完成 | - | docs/requirements/xxx.md |
| 需求审核 | ⏳ 未开始 / ✅ 已通过 / ❌ 已拒绝 / ⏸️ 待决策 | - | docs/reviews/xxx.md |
| 技术设计 | ⏳ 未开始 / ✅ 已完成 | - | docs/design/xxx.md |
| TDD 测试先行 | ⏳ 未开始 / ✅ 已完成 | - | docs/test-cases/xxx.md |
| 步骤分解 | ⏳ 未开始 / ✅ 已完成 | - | docs/plans/xxx.md |
| 开发执行 | ⏳ 未开始 / 🔄 进行中 / ✅ 已完成 | - | docs/dev-logs/xxx.md |
| 测试验证 | ⏳ 未开始 / ✅ 已完成 | - | docs/test-reports/xxx.md |
| 交付发布 | ⏳ 未开始 / ✅ 已完成 | - | docs/deliverables/xxx.md |
## 当前阶段
[当前所处阶段及简要说明]
## 建议下一步
- [ ] [具体的下一步操作建议]
```
### 阶段完成回调
每个阶段 skill 执行完成后，自动更新状态文件：
- 标记当前阶段为"已完成"
- 记录产出文件路径
- 推荐下一步 skill
### 断点续做
重新调用 `/dev-workflow` 时：
- 读取状态文件，定位到上次完成的阶段
- 询问用户是继续下一阶段，还是回顾/修改已完成的阶段
- 支持用户指定任意阶段重新执行
### 权限等级检测（启动时）
工作流启动时检测当前自动批准权限范围，给出等级建议：
**四个预设等级（配置模板位于 `.claude/permissions/`）：**
| 等级 | 名称 | 自动批准范围 | 适用场景 |
|------|------|-------------|---------|
| level-1 | 严格模式 | 无，所有操作需确认 | 生产环境、敏感项目 |
| level-2 | 标准模式 | 只读操作（Read/Glob/Grep/ls/git status） | 日常查看、低风险 |
| level-3 | 开发模式 | 开发常用命令 + 只读 + 编辑 | **本工作流推荐** |
| level-4 | 完全自动 | 所有操作 | 仅隔离环境（Docker/worktree） |
**检测逻辑：**
- 检查项目级 `.claude/settings.json` 是否存在
- 根据 `permissions.allow` 的数量和范围判断当前等级
- 如未配置或等级低于 level-2，提示用户调整
**切换方式：**
```bash
# 方式一：项目级配置（仅影响本项目，推荐）
cp .claude/permissions/level-3-dev.json .claude/settings.json
# 方式二：用户级配置（影响所有项目）
# 手动编辑 ~/.claude/settings.json，在 permissions.allow 中添加允许项
```
**各阶段对权限的需求：**
| 阶段 | 最小推荐等级 | 原因 |
|------|-------------|------|
| 需求分析 | level-2 | 主要是读取和提问 |
| 需求审核 | level-2 | 读取需求文档，生成审核报告 |
| 技术设计 | level-2 | 读取代码、生成设计文档 |
| TDD 测试先行 | level-3 | 需要创建测试文件、运行测试框架 |
| 步骤分解 | level-2 | 主要是读取和生成计划文档 |
| 开发执行 | **level-3** | 需要大量 Edit/Write/Bash（build/test/git） |
| 测试验证 | **level-3** | 需要运行测试、生成报告 |
| 交付发布 | level-3 | 需要 git tag/push、生成交付文档 |
> **建议**：使用本工作流时至少配置为 level-3，否则每步操作都需要确认，流程推进效率极低。
## 关键行为
- 始终先读取状态，不重复创建已存在的文档
- 阶段之间通过 `docs/` 目录传递上下文
- 允许用户跳过阶段（用户明确选择时），但记录跳过的原因
- 每个阶段结束后更新状态文件，确保进度不丢失
- 不强制用户按顺序执行，但默认推荐线性流程
- 权限不足时提示用户调整，不强行执行需要确认的操作