Spec 工作流
Nexus 的 AI 驱动开发由一组 Spec 技能编排，覆盖「新功能 / Bug 修复 / 改进重构」三类典型链路。所有链路都遵循 SDD 的「规格先行、测试先行、层级推进」。
三条工作流链路
链路一：新功能开发（feature）
text
[spec-issue →] spec-milestone → spec-sprint → spec-plan
→ [spec-design] → spec-dod → spec-impl → spec-test
↔ [spec-review] → spec-checkpoint → spec-commit- 使用
spec-issue记录和追踪需求（或由里程碑驱动）。 - 创建里程碑（
spec-milestone）→ Sprint（spec-sprint）→ 功能规划（spec-plan）。 - 必要时使用
spec-research做技术研究，再进行技术设计（spec-design）。 - 先写测试规格 DoD（
spec-dod），再实施（spec-impl）。 - 全量测试（
spec-test）→ 评审（spec-review）→ 归档（spec-checkpoint）→ 提交（spec-commit）。
链路二：Bug 修复（fix）
text
[spec-issue →] spec-fix → [spec-checkpoint]聚焦定位与修复，修复后归档沉淀。
链路三：改进与重构（refine）
text
[spec-issue →] spec-refine → [spec-checkpoint]在保持行为不变的前提下改进代码结构，更新规格后归档。
Spec 技能清单（.claude/skills/）
| 技能 | 作用 | 产出物 |
|---|---|---|
spec-spec | 初始化项目规格 | SPEC.md + CONTEXT.md |
spec-issue | 问题与需求追踪 | ISSUES.md 或问题记录 |
spec-research | 深度技术研究 | 研究记录与决策依据 |
spec-milestone | 创建里程碑 | 里程碑规格 + CONTEXT.md 里程碑 section |
spec-sprint | 创建 Sprint | sprints/<name>/spec.md + CONTEXT.md Sprint section |
spec-plan | 功能规划 | plans/<feature>/spec.md + 链接 |
spec-design | 技术设计 | plans/<feature>/design.md |
spec-dod | 测试规格（Definition of Done） | plans/<feature>/dod.md |
spec-impl | 实施（TDD） | 测试代码 + 实现代码 |
spec-test | 全量测试 | 测试报告 |
spec-review | 多维度评审 | 评审报告 |
spec-fix | Bug 修复 | 修复代码 + 诊断记录 |
spec-refine | 改进重构 | 更新规格 + 改进代码 |
spec-checkpoint | 阶段归档 | feats/ 归档 + 技术决策沉淀 |
spec-commit | 提交变更 | Git commit |
spec-build | 构建与多平台交付 | 构建产物、镜像或发布包 |
技能名称以项目
.claude/skills/中的SKILL.md为准，当前统一使用spec-*连字符命名。
Sprint 类型路由
- feature 型（默认）：走完整开发链路（
spec-plan→spec-dod→ [spec-design] →spec-impl→spec-test↔spec-review→spec-checkpoint）。 - build 型：使用
spec-build，跳过 dod/design/review，以构建产物验证为核心（适合纯构建型 Sprint）。
状态管理
CONTEXT.md中的 📋 链接行是唯一的「已规划」标志。- Sprint / 功能完成并归档后，从
plans/移至feats//done/，更新CONTEXT.md。