| name | orchestration-playbook |
| description | MCC 主动性手册：Claude 遇任务时查'该派什么 agent / 激活什么 skill / 该不该并行'。触发：Claude 自己看到一个新任务但不确定是该硬干、该派 agent、该激活 skill、还是该并行——立即激活本 skill 查 playbook。与 help 分工：help 是用户导航（用户问'我在哪'激活）；本 skill 是 Claude 编排参考（Claude 自己查'该派什么'激活）。 |
Orchestration Playbook · Claude 编排手册
MCC 的执行哲学落地到具体选择。不对用户可见——这是 Claude 自己接手任务时查的 playbook：
- "该派 agent 还是硬干？" → 查 A 节
- "该激活哪个 skill？" → 查 B 节
- "该不该并行？怎么并行？" → 查 C 节
- "任务多大才启动完整流程？" → 查 D 节
A · 意图 → Agent 派发速查 {#a}
遇到用户意图或场景关键词，主动委派下列 agent（不要等用户说"帮我派"）：
| 用户意图 / 场景关键词 | 派的 agent | 备注 |
|---|
| 修 bug / 排查 / 性能慢 / 报错 | debugger | /fix-bug 的 Phase 2 主 agent |
| 新功能规划 / 设计 API / 拆解大任务 | planner | /plan 的主 agent |
| 写完 >50 行改动 | code-reviewer（+ security-reviewer 并行） | 不等用户说 review |
| 安全敏感代码（auth / 加密 / 用户输入 / DB 查询） | security-reviewer | 即使没问 |
| 扫代码里的静默失败 / 吞掉的异常 | silent-failure-hunter | code-reviewer 通过后补一刀 |
| 慢 / 延迟高 / bundle 大 / Core Web Vitals | performance-engineer | 主动，不等 |
| DB 查询慢 / N+1 / schema 设计 | database-optimizer | |
| 架构决策 / 服务边界 / 技术栈选型 | backend-architect | |
| LLM / RAG / Agent 编排 | ai-engineer | |
| Prompt 优化 | prompt-engineer | |
| 向量 DB / embedding | vector-database-engineer | |
| React / Next.js / 前端 UI | frontend-developer | |
| FastAPI 高性能 | fastapi-pro | |
| Python 实现 | python-pro | |
| TS 类型系统 / 泛型 / decorator | typescript-pro | |
| JS 异步 / Promise / event loop | javascript-pro | |
| 补测试到 80% 覆盖 | test-automator | |
| 死代码 / 重复 / 重构清理 | refactor-cleaner | |
| 在写代码前扫现有模式 | code-explorer | 只读探索 |
B · 场景 → Skill 激活速查 {#b}
遇到下列关键词 / 场景，主动激活对应 skill（不等用户说"帮我用 xxx skill"）：
| 场景 | Skill |
|---|
| 开工前心里没底 / "我真的要这么做吗" | confidence-check（5 维度 ≥90% 才动手） |
| 要写新 feature / 修 bug | tdd-workflow（先写失败测试） |
| 交付前 / 合并前 / "验证一下" | verification-loop（6 阶段 gate） |
| 做架构决策 / 技术选型落盘 | architecture-decision-records（产出 ADR） |
| 方向分歧 / 两方案选不出 | party-mode（并行 4 视角辩论） |
| 审代码 / 收 review 反馈 | code-review-workflow（两端） |
| 修完 bug / 完成 refactor 后 | continuous-learning-v2（沉淀 learned skill） |
| 用户说"建个 skill / 提炼约定" | writing-skills |
| 多独立问题并行处理 | dispatching-parallel-agents |
| 写 E2E 测试 / Playwright | e2e-testing |
| 开始新 feature 需隔离开发 | using-git-worktrees |
| 分支做完要合入 | finishing-a-development-branch |
| 执行已有 plan 的 task 链 | subagent-driven-development |
| 写代码前做产品验证 | product-lens |
| 用户问"我在哪 / 下一步" | help（纯用户导航） |
| 用户说"我刚 clone / 不熟这个项目 / 怎么接手 / 从哪开始"（已有项目） | /onboard 命令 + project-onboarding skill（4 阶段深度接手） |
| 大项目（>1k 文件）反复操作想省 token | /index-repo 命令（PROJECT_INDEX，2K 投入省 50K/session） |
| 全新空项目 / 想要轻量 CLAUDE.md | /init 命令（轻量模式，已有项目会建议改用 /onboard） |
| 涉及证据驱动 | confidence-check skill（5 维度评估） |
| 涉及 SOLID / 代码风格 | coding-standards skill（Python + TS 带示例） |
| 涉及架构取舍 / 可逆性 | architecture-decision-records skill（产出 ADR） |
| 涉及风险管理 | planner agent 的 Risks & Mitigations 段 + security-reviewer agent |
| 写/改代码时想找规范示例 | coding-standards（Python + TS 示例） |
C · 并行决策（Q1-Q4） {#c}
每次接手任务第 1 秒自问：
- Q1 能拆 2+ 独立子任务？ → fan-out 并行（同一条 message 多个 Task call）
- Q2 多视角给不同答案？ →
party-mode 辩论
- Q3 有时序依赖？ → 接力（A→B→C，每步主 session 整合）
- Q4 任务很小？ → 直接做，不派 agent
3 种最常用并行组合（熟记）：
- 代码审查 →
code-reviewer + security-reviewer 并行（大改动加 silent-failure-hunter + performance-engineer）
- Bug 盲诊 →
debugger + performance-engineer 并行（涉数据加 database-optimizer）
- 架构规划 →
planner + 栈相关 domain agent 并行（后端 / 前端 / AI 按栈选）
完整 10+ 场景组合 + 4 种协作模式 + 合流 4 动作 + 成本控制 → dispatching-parallel-agents skill。
D · 任务规模 → 流程深度 {#d}
- 小改动（<30 行 / typo / 文案）：直接做，不启流程。别 confidence-check、别 TDD、别 review——否则"一件小事连串调 skill"。
- 中等单元（一组件 / 一 endpoint / 一算法）：TDD + review 就够（tdd-workflow → 实现 → code-review-workflow）。
- 较大单元（完整页面 / 子系统 / PR 改 10+ 文件）：完整流程：confidence-check → /plan → /implement（带 subagent-driven-development）→ /review → verification-loop → /pr。
并行派发必须可视化（v1.9 新增 · 让用户看到真并行）
每次并行派 2+ agent 时，assistant message 必须输出以下可视化格式，然后紧跟 Task tool call：
派发前：
⚡ 并行派发 N agent（fan-out / 预计 ~X min）
├─ agent1 用途一句话
├─ agent2 用途一句话
└─ agent3 用途一句话
返回后合流：
✓ N agent 全部返回（耗时 X.X min）
├─ agent1 X.X min → N findings
└─ ...
合流整合：
CRITICAL (n): ...
HIGH (n): ...
完整模板 + 理由见 dispatching-parallel-agents skill 的"派发可视化模板"章节。
禁止：不说就派（用户看不到并行证据，怀疑"你是不是只派了 1 个"）。
禁止
- ❌ 等用户敲 slash 命令才激活能力（用户不知道你有什么）
- ❌ 一件小事连串调 skill（改 typo 不要先 confidence-check）
- ❌ 忽略 agent 直接在会话里硬写（上下文污染，丢失 subagent 隔离优势）
- ❌ 多 agent 并行时把某 agent 的 full report 直接贴给用户（主 session 做摘要）
- ❌ 并行派发不加可视化文本（见上节）
底线
MCC 的执行哲学：用户少敲，Claude 多主动。本 playbook 是这个哲学的具体落地手册，遇不确定时查它。
