33c8de02da
## dev-workflow - Spec-Driven 开发流程 - 从需求生成 spec.md - 创建功能分支 - 调用子代理开发 - 自动创建 Gitea PR ## pr-review-gate - 3 审查者并行审查(安全/质量/逻辑) - 自动合并逻辑 - 修复循环(最多3次) ## .planning - PROJECT.md: 项目定义 - REQUIREMENTS.md: 需求列表 - ROADMAP.md: 开发路线图 - STATE.md: 当前状态
167 lines
4.6 KiB
Markdown
167 lines
4.6 KiB
Markdown
---
|
||
name: dev-workflow
|
||
description: "Spec-Driven 开发流程技能。当用户说'添加功能'、'开发XXX'时使用。"
|
||
---
|
||
|
||
# dev-workflow - Spec-Driven 开发流程
|
||
|
||
## 什么时候使用
|
||
|
||
当用户发送包含以下模式的消息时触发:
|
||
|
||
| 触发词 | 行为 |
|
||
|--------|------|
|
||
| `添加功能` + 描述 | 开始 Spec-Driven 开发流程 |
|
||
| `开发` + 描述 | 同上 |
|
||
| `实现` + 描述 | 同上 |
|
||
|
||
## 环境变量
|
||
|
||
| 变量名 | 用途 | 必需 |
|
||
|--------|------|------|
|
||
| `GITEA_TOKEN` | Gitea API Token(创建 PR) | 是 |
|
||
| `GITEA_URL` | Gitea 服务地址 | 否(默认 http://192.168.1.22:8418) |
|
||
| `GITEA_REPO` | 仓库路径 | 否(默认 starmen1265/kb-skills) |
|
||
|
||
## 工作流程
|
||
|
||
```
|
||
用户描述需求
|
||
↓
|
||
┌─────────────────────────────────────┐
|
||
│ Phase 1: Spec 生成 │
|
||
│ - 澄清需求 │
|
||
│ - 生成 .planning/spec.md │
|
||
└─────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────┐
|
||
│ Phase 2: 分支创建 │
|
||
│ - 创建 feature/* 分支 │
|
||
│ - 切换到功能分支 │
|
||
└─────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────┐
|
||
│ Phase 3: 子代理开发 │
|
||
│ - 基于 spec 启动开发子代理 │
|
||
│ - 子代理执行开发任务 │
|
||
│ - 提交代码到功能分支 │
|
||
└─────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────┐
|
||
│ Phase 4: 创建 PR │
|
||
│ - 调用 Gitea API 创建 PR │
|
||
│ - 返回 PR 编号 │
|
||
└─────────────────────────────────────┘
|
||
↓
|
||
通知 pr-review-gate 开始审查
|
||
```
|
||
|
||
## 执行步骤
|
||
|
||
### Step 1: 需求澄清
|
||
|
||
使用 GSD 风格的深度提问:
|
||
|
||
1. 理解用户要做什么
|
||
2. 探索边界条件
|
||
3. 确认技术约束
|
||
4. 识别依赖关系
|
||
|
||
**示例问题:**
|
||
- "这个功能解决什么问题?"
|
||
- "期望的输入/输出是什么?"
|
||
- "有什么技术约束?"
|
||
- "需要与现有哪些模块交互?"
|
||
|
||
### Step 2: 生成 Spec
|
||
|
||
创建 `.planning/spec.md` 文件:
|
||
|
||
```bash
|
||
python3 dev_workflow.py --create-spec --title "功能名称" --description "详细描述"
|
||
```
|
||
|
||
Spec 文件结构参考 `templates/spec-template.md`。
|
||
|
||
### Step 3: 创建功能分支
|
||
|
||
```bash
|
||
python3 dev_workflow.py --create-branch --spec .planning/spec.md
|
||
```
|
||
|
||
分支命名规则:
|
||
- `feature/<简短描述>` - 新功能
|
||
- `fix/<简短描述>` - Bug 修复
|
||
- `refactor/<简短描述>` - 重构
|
||
|
||
### Step 4: 启动开发子代理
|
||
|
||
使用 `sessions_spawn` 启动开发子代理:
|
||
|
||
```
|
||
sessions_spawn(
|
||
task="根据 spec 开发 <功能名称>",
|
||
cwd="~/work/kb-skills",
|
||
runtime="subagent"
|
||
)
|
||
```
|
||
|
||
子代理会:
|
||
1. 读取 spec 文件
|
||
2. 执行开发任务
|
||
3. 提交代码到功能分支
|
||
|
||
### Step 5: 创建 PR
|
||
|
||
开发完成后:
|
||
|
||
```bash
|
||
python3 dev_workflow.py --create-pr --branch feature/xxx --title "PR 标题"
|
||
```
|
||
|
||
调用 Gitea API 创建 PR,返回 PR 编号。
|
||
|
||
### Step 6: 通知审查
|
||
|
||
PR 创建后,告知用户:
|
||
|
||
```
|
||
✅ PR #xxx 已创建
|
||
|
||
**分支:** feature/xxx
|
||
**链接:** http://192.168.1.22:8418/starmen1265/kb-skills/pulls/xxx
|
||
|
||
正在启动 pr-review-gate 审查流程...
|
||
```
|
||
|
||
## CLI 命令
|
||
|
||
```bash
|
||
# 创建 spec
|
||
python3 dev_workflow.py --create-spec --title "标题" --description "描述"
|
||
|
||
# 从 spec 创建分支
|
||
python3 dev_workflow.py --create-branch --spec .planning/spec.md
|
||
|
||
# 创建 PR
|
||
python3 dev_workflow.py --create-pr --branch feature/xxx --title "PR标题"
|
||
|
||
# 查看当前状态
|
||
python3 dev_workflow.py --status
|
||
```
|
||
|
||
## 与其他技能的协作
|
||
|
||
| 技能 | 协作方式 |
|
||
|------|----------|
|
||
| **pr-review-gate** | PR 创建后自动触发审查 |
|
||
| **kb-workflow** | 可复用其目录结构 |
|
||
| **GSD** | 采用其 Spec-Driven 方法论 |
|
||
|
||
## 注意事项
|
||
|
||
1. 确保 `GITEA_TOKEN` 已配置
|
||
2. 功能分支命名遵循规范
|
||
3. 提交信息遵循 Conventional Commits
|
||
4. 开发前先 pull 最新代码
|