初始化自动化开发工作流技能库
This commit is contained in:
@@ -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/` 目录传递上下文
|
||||
- 允许用户跳过阶段(用户明确选择时),但记录跳过的原因
|
||||
- 每个阶段结束后更新状态文件,确保进度不丢失
|
||||
- 不强制用户按顺序执行,但默认推荐线性流程
|
||||
- 权限不足时提示用户调整,不强行执行需要确认的操作
|
||||
Reference in New Issue
Block a user