X Qdev

---
name: x-qdev
description: |
  轻量级快速开发 skill。自包含，一步到位，适合 1-2 小时内能完成的改动。
  触发场景：“x-qdev”、“快速开发”、“小功能”、“小改动”、“修个 bug”、“加个小功能”、
  “这个简单直接做吧”、用户描述的任务明显是小改动（单文件/单模块/1-5 个 checklist 项）。
  与 x-req 的区别：x-req 适合中等以上任务（需要 DoD + 技术设计 + 清单 + 确认）；
  x-qdev 省去确认步骤直接开发，但仍产出任务记录（README.md + changelog.md）。
---

# x-qdev — 轻量级快速开发

适用于小功能、小修改、bug 修复等场景。省去需求分析和确认步骤，直接进入开发。

## 工作流程

```
用户描述任务 → 创建任务目录 → 编写 README.md → 逐项开发 → 更新状态 → 代码审查 → 完成
```

## 第一步：理解任务

收到用户的开发请求后：

1. 快速理解用户要做什么
2. 如果描述模糊，简短地问 1-2 个关键问题（不要做深度需求分析）
3. 如果项目 `docs/` 下有相关模块文档 → 读取，获取模块设计上下文
4. 评估涉及的文件和改动范围

如果改动明显很大（预计超过 5 个任务项、涉及架构变更），建议用户改用 x-req → x-dev 流程。

## 第二步：创建任务记录

在 `dev-pipeline/tasks/<功能名称>/` 下基于 `templates/README.md` 模板创建 README.md。

## 模板文件

所有模板在 `skills/x-qdev/templates/` 下：

| 模板文件 | 对应产出 |
|---------|---------|
| `templates/README.md` | 任务说明 + 涉及模块 + DoD + 开发清单 |
| `templates/changelog.md` | 变更记录 |

### 状态 / 优先级 / 质检标记

详见 `references/execution-rules.md`（本 skill 目录下独立副本）。

核心要点：状态流转 `⏳ → ▶️ → 🟡 → 🟢`（x-qdev 最多到 🟢，✅ 由 review 确认）。优先级 P0 > P1 > P2。质检 🔍 标核心/安全/跨模块任务。

### 并行开发（默认优先）

> **能并行就并行，不要串行等待。**

如果清单有 2+ 个无依赖任务，**必须**派 opus 子 agent 并行开发。不允许"为了简单"而串行执行可并行任务。

**dispatch 模板**：

```
Agent({
  description: "x-qdev #N <任务标题>",
  subagent_type: "general-purpose",
  model: "opus",
  prompt: <功能目录路径 + 任务编号/描述 + README 技术设计段 + 涉及模块文档（如有）>
})
```

**硬规则**：
- 必须 `model: "opus"`
- 必须同一条消息发出所有 Agent 调用（真正并行）
- 每个子 agent prompt 自包含（README 技术设计 + DoD 相关条目）
- 子 agent 只改自己任务的代码，不更新 README 开发清单和 changelog（主流程统一更新）
- 某个子 agent 失败不阻塞其他任务，失败任务回到待处理队列

## 第三步：逐项开发

按清单顺序（P0 优先）逐项实现：

1. 开始某项前，将其状态改为 `▶️ 进行中`
2. **如果 README.md "涉及模块" 段引用了 docs/ 文件 → 先读该模块文档**，获取接口/数据结构上下文
3. 读懂相关代码，做出修改
4. 修改完成后将状态改为 `🟡 待测试`
5. 验证改动是否正确（运行测试、手动检查等）
6. 通过则改为 `🟢 测试通过`，失败则改为 `🔴 测试失败` 并修复后重新验证
7. 在变更记录中记录关键操作

每完成一项就更新 README.md 中的状态，保持实时同步。

## 第四步：记录变更

在 `dev-pipeline/tasks/<功能名称>/changelog.md` 中记录关键变更（模板见 `templates/changelog.md`）。

只记录有价值的信息，不需要事无巨细。重点记录：
- 任务开始和完成
- 测试失败及原因
- 需求调整或方案变更
- 遇到的关键决策

## 第五步：代码审查（自动衔接 x-verify → x-qa-gate）

所有清单项达到 🟢 后，**不再走老 x-cr**，改为：

1. 写 `dev-pipeline/tasks/<task>/dev-report.md`（命令清单 + 自检结论，模板见 `skills/x-dev/templates/dev-report-template.md`）
2. 自动衔接 x-verify（Gate ① 命令复跑事实验证）
3. x-verify 通过后自动衔接 x-qa-gate（Gate ② 质量评审：R1 spec → R2 边界 → R3 测试真实性，三个 opus 子 agent 串行）
4. 任一节点 fail → 走 x-fix 回流，按 4 条规则回到对应节点重审

`x-qdev` 的 dev-report 命令清单可以短（小功能），但**至少必须包含一条测试类命令**；项目无测试框架时显式写 `no-test-framework: true` + 理由。

### 问题处理

- x-verify fail / R1/R2/R3 fail：由 x-fix 自动接管修复
- fix-attempts 6 次上限触发停下时，向用户汇报剩余问题
- 全部 reviewer pass → 把清单中对应项状态从 🟢 更新为 ✅

## 任务完成时必须输出 dev-report.md

每个任务完成后，**除 changelog.md 之外**，必须额外在 `dev-pipeline/tasks/<task>/` 下写入 `dev-report.md`，模板见 `skills/x-dev/templates/dev-report-template.md`。

dev-report.md 是 x-verify 的唯一输入。规则：
1. 验证命令清单**至少包含一条测试类命令**；项目无测试框架时必须显式声明 `no-test-framework: true` + 理由。
2. 命令必须可在项目根目录直接运行，**不允许依赖 dev 临时设置的环境变量**。
3. 自检结论段必须由 x-qdev 自己运行命令后填写，不能空着或写"应该能跑"。
4. 写完 dev-report.md 后，下游自动衔接 x-verify（不再走老 x-cr）。

## 第六步：收尾

所有清单项标记为 ✅ 后：

1. 在变更记录中添加最终记录
2. 向用户汇报完成情况：完成了哪些任务、改了哪些文件、review 结论

## 第七步：提醒提交

开发完成后，提示用户：

```
✅ 开发完成，可提交：

git add .
git commit -m "feat: [一句话描述完成内容]"
```

如果本次涉及多个不相关改动，建议按实际修改分开 commit。

## 注意事项

- 保持轻量：这个流程的核心优势是快。不要在文档上花太多时间，重点是把活干好
- 状态实时更新：每个任务项完成就更新一次，不要等到最后一起改
- 变更记录精简：只记有价值的信息，不需要流水账
- 如果开发过程中发现任务比预期复杂得多，及时告知用户，建议切换到 x-req → x-dev 流程
- **涉及模块 ref**：如果项目有 docs/ 模块文档且 README 里引用了，开发前必须先读