# Spec 驱动开发规则包（Roo Code）

**Repository Path**: byemonkey/spec-driven-rules

## Basic Information

- **Project Name**: Spec 驱动开发规则包（Roo Code）
- **Description**: Spec 驱动开发规则包（Roo Code）

背景是公司的云主机开发环境自建的大模型只集成了roocode，暂且自己写一套规则来使用
- **Primary Language**: JavaScript
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-04-14
- **Last Updated**: 2026-05-06

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Spec 驱动开发规则包（Roo Code）
让 Roo Code 插件具备类似 Qoder Quest / Trae Solo 的自主开发能力。提供 Spec 后，Agent 先完成"解析 → 设计 → 拆任务"三个阶段，每个阶段产出文档后**必须等你确认**才进入下一步。确认任务分解后，Agent 全自主完成"实现 → 验证 → 交付"。
## 快速开始
1. 将本仓库所有文件复制到你的项目根目录（保持目录结构不变）
2. 根据项目实际情况编辑 constitution.md（也可留空，Agent 会自动推断）
3. 重新打开 Roo Code 插件，直接发送你的 Spec 即可
## 目录结构
**项目根目录/**

- **README.md** — 本文件
- **constitution.md** — 项目宪章（技术栈/风格/约束等硬性规则）
- **.roo/**

  - **rules/**

    - **spec-driven-development.md** — 主流程（6 阶段协议 + 绝对规则 + 禁止行为）
    - **spec-quality-gates.md** — 质量门禁（7 道硬关卡 + 阶段间依赖）
    - **spec-task-sizing.md** — 任务拆分（尺寸约束 + 三场景模板 + 风险标注）
    - **spec-lifecycle.md** — Spec 生命周期（归档/分支对齐/变更记录/协作）
    - **spec-testability.md** — 可测试性与需求追溯（验收条件 + 覆盖矩阵）
- **.spec-state/** — Agent 自动创建，无需手动操作（建议添加到.gitignore）
  - **context.md** — Phase 0 产出：项目状态检测
  - **spec-analysis.md** — Phase 0 产出：需求解析
  - **architecture.md** — Phase 1 产出（新建场景）
  - **impact-analysis.md** — Phase 1 产出（增量场景）
  - **change-plan.md** — Phase 1 产出（改造场景）
  - **tasks.md** — Phase 2 产出：任务清单
  - **progress.md** — Phase 3 实时更新：执行进度
  - **delivery-report.md** — Phase 5 产出：交付报告
  - **active/** — 活跃 Spec（按 change-id 分目录）
  - **archive/** — 归档 Spec（合并/关闭后移入）
## 文件说明
| 文件 | 作用 | 你需要改吗 |
|------|------|-----------|
| constitution.md | 定义项目级硬约束，Agent 必须遵守 | 按需填写，留空也可 |
| spec-driven-development.md | 核心流程：6 个 Phase 的完整协议 | 不建议改 |
| spec-quality-gates.md | 编译/导入/接口/深度/回归等 7 道门禁 | 不建议改 |
| spec-task-sizing.md | 任务拆分粒度、三场景标准顺序、风险分级 | 不建议改 |
| spec-lifecycle.md | Spec 的归档、分支对齐、变更记录规则 | 不建议改 |
| spec-testability.md | 需求可测试性、FR 到任务/测试的追溯 | 不建议改 |
## 核心流程
**用户给 Spec**

↓

**Phase 0** — 上下文感知 + Spec 解析 → ⛔ **等你确认 G0**

↓

**Phase 1** — 方案设计（按场景自动分流）→ ⛔ **等你确认 G1**

↓

**Phase 2** — 任务分解（带风险标注、依赖排序）→ ⛔ **等你确认 G2**

↓ **（你确认后，Agent 全自主执行以下阶段，不再停顿）**

**Phase 3** — 逐任务执行循环（实现 → 自验证 → 修复，最多重试 3 次）

↓

**Phase 4** — 集成验证（编译/测试/lint/断裂导入/需求覆盖）

↓

**Phase 5** — 交付报告（需求覆盖矩阵 + 变更摘要 + 运行验证结果）

> **三道确认门禁（G0/G1/G2）是强制的**。Agent 在每个阶段产出文档后必须展示给你并等待你的肯定回复，不得跳过。只有 G2 通过后才进入全自主实现模式。
## 三种场景自动适配
Agent 在 Phase 0 自动检测项目状态，后续所有阶段按场景走不同路径：
| 场景 | 判定条件 | Phase 1 产出 | 任务首步 | SPEC-STUB | 测试要求 |
|------|---------|-------------|---------|-----------|---------|
| **新建** | 无项目配置或用户明确说明 | 完整架构设计 | 脚手架 | ✅ 允许 | 新功能测试 |
| **增量** | 有项目，Spec 描述新功能 | 变更影响分析 | 阅读现有代码 | ❌ 禁止 | 新功能 + 回归 |
| **改造** | 有项目，Spec 描述修改/重构 | 变更方案 | 阅读目标代码+调用链 | ❌ 禁止 | 全量回归（硬性） |
### 场景间的关键差异
- **增量**：新文件放现有目录、新导出加到 barrel 文件、不自己选技术栈
- **改造**：先改被依赖方再改调用方、改签名时 grep 所有调用方同步适配、不顺手重构
## 质量门禁（7 道）
| # | 门禁 | 适用场景 | 说明 |
|---|------|---------|------|
| 1 | 编译/类型检查 | 全部 | 从项目配置自动发现命令，不硬编码 |
| 2 | 无断裂导入 | 全部 | 增量/改造额外检查 barrel 注册 |
| 3 | 接口合规 | 全部 | 改造额外检查签名变更后的调用方 |
| 4 | 无残留桩代码 | 仅新建 | SPEC-STUB 清零、TODO 有编号 |
| 5 | 最低实现深度 | 全部 | 禁止空壳函数、纯注释文件 |
| 6 | 不破坏现有功能 | 增量/改造 | 现有测试通过率不降 |
| 7 | 需求可追溯 | 全部 | 覆盖矩阵无空行、❌ 有原因 |

另有**阶段间硬依赖**：无 spec-analysis 不做设计 → 无方案不做任务 → 无任务不实现 → 验证不通过不交付。
Phase 0/1/2 各有一道人工确认门禁（G0/G1/G2），必须用户确认后才可进入下一阶段。
## 关键设计决策
**宪章优先级**

constitution.md > .roo/rules/ > Agent 自行推断。宪章里的"不可做清单"是硬约束，Agent 不会违反。
**零假设侵入**

增量/改造场景下，技术栈、目录结构、代码风格、工具链命令全部从现有项目读取，Agent 不会自己选、自己规划。
**自动发现工具链**

不写死 npx tsc --noEmit 之类的命令。按优先级查：package.json scripts → 配置文件推断 → turbo.json → 文件扩展名兜底。
**任务风险分级**

- **high**：安全/支付/权限/核心业务 → 交付时额外输出风险评估
- **medium**：跨模块集成/复杂状态 → 至少跑完整测试
- **low**：UI 样式/文案/配置 → 依赖自动化检查
## constitution.md 填写指南
按需填写，**全部留空也完全可用**。以下是填写示例：

**技术栈**

React 18 + TypeScript + Next.js 14 (App Router) + Prisma + PostgreSQL

**代码风格**

- 函数式组件 + hooks，不用 class
- camelCase 命名，文件名 kebab-case
- 错误处理用 Result\<T, E\> 模式，不用 try-catch 到处包
- 导出统一走 src/modules/*/index.ts

**测试策略**

- 新功能必须有单测，用 Vitest + Testing Library
- API 路由用 supertest 做集成测试

**安全与合规**

- 禁止硬编码密钥，走环境变量
- 用户输入必须 zod 校验

**性能基线**

- 列表页首屏 < 2s
- API P99 < 500ms

**不可做清单**

- 禁止引入新的状态管理库（已有 zustand）
- 禁止修改 prisma/schema.prisma 的已有模型（需单独提 Spec）
- 禁止在组件里直接调 prisma，必须走 service 层
## 与其他方案的对比
| | 本规则包 | Qoder Quest | Trae Solo | 手动指挥 Roo |
|---|---|---|---|---|
| 平台 | Roo Code (VSCode) | Qoder | Trae | Roo Code |
| 自主程度 | 全自主 | 全自主 | 全自主 | 逐步指挥 |
| 增量开发 | ✅ 自动适配 | ⚠️ 偏新建 | ⚠️ 偏新建 | 取决于人 |
| 改造/重构 | ✅ 自动适配 | ❌ | ❌ | 取决于人 |
| 质量门禁 | 7 道硬关卡 | 产品内置 | 产品内置 | 无 |
| 可定制性 | 完全可控 | 产品内置 | 产品内置 | 完全可控 |
| 离线可用 | ✅ 纯规则文件 | ❌ 云端 | ❌ 云端 | ✅ |
| 多人协作 | ✅ 分支+归档 | 不明 | 不明 | 取决于人 |
## 常见问题

**Q: 放好后需要重启 VSCode 吗？**


不需要，重新打开 Roo Code 侧边栏或新建对话即可。

**Q: 可以只用在某个子目录吗？**


可以，把 .roo/rules/ 放到子目录下，Roo Code 会按工作区层级加载。

**Q: 想临时禁用怎么办？**


把 .roo/rules/ 下的 .md 文件后缀改为 .md.bak，或新建对话时手动覆盖指令。

**Q: 多人协作怎么用？**


每条功能分支对应一个 change-id（如 001-add-user-auth），Spec 存在 .spec-state/active/001-add-user-auth/，合并后移到 archive/。详见 spec-lifecycle.md。

**Q: 和 CLAUDE.md 冲突吗？**


不冲突。CLAUDE.md 是 Claude Code 的约定，Roo Code 只读 .roo/rules/。如果你同时用两个工具，可以各放各的。

**Q: Agent 不等我确认就直接改代码怎么办？**

确认使用最新版规则，新建 Roo Code 对话重新加载。新版规则设了 G0/G1/G2 三道门禁，Agent 必须等你确认。

**Q: Agent 还是会问太多问题怎么办？**


检查是否是真正的"阻塞型模糊点"（不回答就无法动工）。非阻塞问题 Agent 不应该问，如果出现说明宪章或现有代码上下文不够丰富，补充 constitution.md 中的约束即可减少提问。

**Q: .spec-state 要提交到 Git 吗？**


建议 .spec-state/active/ 提交（团队可见当前进行中的 Spec），.spec-state/archive/ 提交（历史记录），progress.md 加入 .gitignore（临时状态）。
## License
MIT