Scan to join WeChat groupDevDocs 工作流编排器
顶层编排器，提供 5 个流程入口，降低用户面对 13 个原子 skill 的认知负担。
语言规则
- 支持中英文提问
- 统一中文回复
定位
用户 → /devdocs-pipeline → 自动路由到合适的 skill 组合
↓
取代手动选择 13 个原子 skill
核心价值：用户只需说"我要做什么"，pipeline 负责"用哪些 skill、按什么顺序"。
运行模式
/devdocs-pipeline → 提问式调度（自动判断）
/devdocs-pipeline init → 新项目全流程
/devdocs-pipeline feature → 新功能开发
/devdocs-pipeline bugfix → Bug 修复
/devdocs-pipeline verify → 质量检查
/devdocs-pipeline close → 周期收尾
提问式调度（智能引导）
无参数调用时，通过阶段感知 + 智能引导收敛到合适的入口：
阶段检测
首先扫描 docs/devdocs/ 已有文件，判断当前阶段：
扫描 docs/devdocs/ 目录
│
├── 无文件 → 新项目判断（见下方 Q1）
│
└── 有文件 → 分析当前阶段
│
├── 仅 01-requirements.md → "需求已完成，建议运行 /devdocs-system-design"
├── 有 01 + 02 → "设计已完成，建议运行 /devdocs-test-cases"
├── 有 01~03 → "测试设计已完成，建议运行 /devdocs-dev-tasks"
├── 有 01~04 + 有 readiness-report → "就绪检查已通过，建议运行 /devdocs-dev-workflow"
├── 有 01~04 + 无 readiness-report → "任务已拆分，建议运行 /devdocs-verify --readiness"
├── 有代码提交 + 任务进行中 → "开发进行中，建议继续 /devdocs-dev-workflow"
└── 有 verify-report → "验证已完成，建议运行 /devdocs-sync 或 /devdocs-compound"
轻量分轨提示
根据用户描述的变更规模，给出路径建议：
| 变更规模 | 特征 | 建议路径 |
|----------|------|----------|
| 小改动 | bugfix、单文件修复、配置变更 | /devdocs-pipeline bugfix |
| 标准功能 | 新功能、需求变更、多文件改动 | /devdocs-pipeline feature |
| 大功能 | 跨模块、新架构、全新项目 | /devdocs-pipeline init 完整路径 |
兜底问答
阶段检测无法判断时，通过 2-3 个问题收敛：
Q1: "项目已有 DevDocs 文档吗？"
│
├── 没有 → Q1a: "已有代码还是全新项目？"
│ ├── 全新项目 → init
│ └── 已有代码 → /devdocs-retrofit（非 pipeline 管辖）
│
└── 有 → Q2: "你要做什么？"
├── 新功能 → feature
├── 修 Bug → bugfix
├── 检查质量 → verify
└── 收尾/沉淀 → close
Q3（feature/bugfix 追加，可选）:
"这次改动涉及 UI 吗？"
├── 是 → verify 阶段包含 --ui 维度
└── 否 → verify 阶段仅 --docs/--impl
入口详解
init — 新项目全流程
适用于全新项目，从需求到开发的完整流程。
/devdocs-requirements
│
▼
/devdocs-system-design
│
▼
/devdocs-test-cases
│
▼
/devdocs-dev-tasks
│
▼
/devdocs-verify --readiness ← 就绪关卡（P1 阻塞则修复后重试）
│
▼
/devdocs-dev-workflow（批量模式）
│ ← 批量模式内部已含逐任务 sync + compound
▼
/devdocs-verify ← 全量验证（覆盖 dev-workflow 逐任务验证可能遗漏的跨任务一致性）
│
▼
/devdocs-sync ← 全量补充同步（幂等，捕获跨任务遗漏）
就绪关卡：dev-tasks 完成后自动调用
verify --readiness。检查项包括：AC↔测试用例对齐、任务文件路径具体性、依赖无环、设计↔任务一致性。P1 问题阻塞进入 dev-workflow，显示问题清单并建议修复后重试。粒度说明：dev-workflow 批量模式内部已执行逐任务 sync 和 compound。pipeline 此处的 verify → sync 是全量验证+补充同步，覆盖跨任务的整体一致性。sync 是幂等的，多次执行不会产生错误结果。不再额外执行 compound——dev-workflow 批量模式已默认执行。
上下文传递：pipeline 启动时优先检查 docs/devdocs/00-context.md，如存在且未过期（< 24h），读取作为快速上下文，避免重复扫描。
feature — 新功能开发
适用于已有项目追加新功能。
/devdocs-feature（含 requirements/design/tests/tasks + readiness 关卡 + 自动衔接 dev-workflow）
│ ← feature 内置 Step 4.5 verify --readiness，P1 阻塞则修复后重试
│ ← dev-workflow 内部已含逐任务 sync
▼
/devdocs-verify ← 全量验证（覆盖所有新增任务的整体一致性）
│
▼
/devdocs-sync ← 全量补充同步（幂等，捕获跨任务遗漏）
/devdocs-feature已内置 Step 4.5 readiness 关卡和 Step 6 自动衔接 dev-workflow，pipeline 只需在 feature 完成后补充 verify 和 sync。verify 是全量验证，覆盖 dev-workflow 逐任务验证可能遗漏的跨任务一致性；sync 是幂等的全量补充同步，不是重复执行。
bugfix — Bug 修复
适用于已有项目修复 Bug。
评估复杂度
│
├── 简单 Bug → /devdocs-bugfix（直接修复）
│ │
│ ▼
│ /devdocs-verify --impl
│ │
│ ▼
│ /devdocs-sync
│
└── 复杂 Bug → /devdocs-dev-tasks（拆分任务）
│
▼
/devdocs-dev-workflow
│
▼
/devdocs-verify --impl
│
▼
/devdocs-sync
verify — 质量检查
适用于任意阶段的质量检查。
自动判断维度
│
├── 有代码变更 → /devdocs-verify --impl
├── 有文档变更 → /devdocs-verify --docs
├── 有 UI 设计稿 → /devdocs-verify --ui
└── 不确定 → 询问用户
│
▼
生成修复建议
│
▼
路由到对应 skill 执行修复
close — 周期收尾
适用于开发周期结束后的收尾工作。
/devdocs-sync（trace + audit）
│
▼
/devdocs-compound（知识沉淀）
│
▼
/devdocs-onboard --update（更新上下文摘要）
阶段间衔接
pipeline 在每个阶段完成后：
- 状态检查：确认阶段产出文件存在
- 简要摘要：向用户展示本阶段结果概要
- 衔接提示：询问用户是否继续下一阶段（默认是）
✅ 需求文档已完成（F-001~F-003, AC-001~AC-012）
是否继续进入系统设计阶段？[是(默认)/否]
编排规范（子 Agent 调度）
调度原则
pipeline 调用其他技能时，必须通过 Task tool 启动子 Agent：
pipeline（编排层）
│
├── Task: /devdocs-requirements → YAML 摘要
├── Task: /devdocs-system-design → YAML 摘要
├── Task: /devdocs-test-cases → YAML 摘要
├── Task: /devdocs-dev-tasks → YAML 摘要
├── Task: /devdocs-verify --readiness → YAML 摘要
├── Task: /devdocs-dev-workflow → YAML 摘要
├── Task: /devdocs-verify → YAML 摘要
└── Task: /devdocs-sync → YAML 摘要
摘要传递
阶段间只传递 YAML 摘要 + 文件路径。编排 Agent 不读取子技能的完整输出文档。
异常回退
子 Agent 返回 status: failed + blockers 时：
- 展示阻塞项给用户
- 询问用户处理方式（修复/跳过/终止）
- 不自行读取文档排障
上下文隔离
每个子 Agent 自行读取所需的前置文档（从 docs/devdocs/ 文件系统），不依赖编排 Agent 传递全文。
约束
编排约束
- [ ] pipeline 仅负责路由和衔接，不复制任何原子 skill 的逻辑
- [ ] 每个阶段必须委托给对应的原子 skill 执行
- [ ] 阶段间传递的信息仅限：新增编号列表、状态摘要、文件路径
- [ ] 用户可在任意阶段退出 pipeline
提问式调度约束
- [ ] 优先使用阶段检测自动判断，无法判断时才提问
- [ ] 兜底问答最多 3 个问题收敛到入口
- [ ] 问题必须有明确的选项（不开放式提问）
- [ ] 识别到 retrofit 场景时，路由到
/devdocs-retrofit并退出 pipeline - [ ] 分轨提示基于变更规模，不引入额外术语
上下文约束
- [ ] 优先读取 00-context.md 作为快速上下文（如存在且 < 24h）
- [ ] pipeline 编排层不读取大量源代码（委托给子 skill）
- [ ] 每个阶段完成后展示简要摘要（< 10 行）
编排约束（子 Agent）
- [ ] 调用其他技能时必须通过 Task tool 启动子 Agent
- [ ] 阶段间只传递 YAML 摘要 + 文件路径
- [ ] 子 Agent 失败时展示阻塞项询问用户，不自行排障
- [ ] 每个子 Agent 自行读取前置文档，编排层不传递全文
Skill 协作
| 入口 | 编排的 Skill 链 | |------|----------------| | init | requirements → system-design → test-cases → dev-tasks → verify --readiness → dev-workflow → verify → sync | | feature | feature(含 readiness + dev-workflow) → verify → sync | | bugfix | bugfix / (dev-tasks → dev-workflow) → verify → sync | | verify | verify --docs/--impl/--ui | | close | sync → compound → onboard --update |
子 Agent 摘要格式
当本 Skill 作为子 Agent 运行时，返回以下结构化摘要：
skill: devdocs-pipeline
entry: init | feature | bugfix | verify | close
stages_completed:
- { skill: devdocs-requirements, status: success }
- { skill: devdocs-system-design, status: success }
stages_remaining:
- devdocs-test-cases
summary:
new_ids: [F-001, F-002, AC-001~AC-012]
status: completed | interrupted | failed
interrupt_reason: "用户选择退出" # 仅中断时
output_files:
- docs/devdocs/01-requirements.md
- docs/devdocs/02-system-design.md
下一步
pipeline 完成后，所有产出文档均已生成/更新。用户可：
- 继续下一轮 feature/bugfix
- 运行
/devdocs-onboard --read传递上下文给新 AI - 直接进入编码（已有 dev-tasks 和 dev-workflow 的产出）