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

This commit is contained in:
锦麟 王
2026-04-27 17:45:20 +08:00
commit 0cce68b38c
11 changed files with 1613 additions and 0 deletions
+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`,确保不重复处理
- 用户可覆盖审核结论(强制推进),但记录覆盖原因