锦麟 王
139 lines
5.1 KiB
Markdown
139 lines
5.1 KiB
Markdown
---
|
||
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/` 目录传递上下文
|
||
- 允许用户跳过阶段（用户明确选择时），但记录跳过的原因
|
||
- 每个阶段结束后更新状态文件，确保进度不丢失
|
||
- 不强制用户按顺序执行，但默认推荐线性流程
|
||
- 权限不足时提示用户调整，不强行执行需要确认的操作
|