orchestrator

Orchestrator 是用于协调多智能体 Claude Code 端到端构建的技能，定位为“指挥者”而非实现者，核心工作是架构设计、集成契约和协调验证。

【用途与工作模型】 采用契约优先的多智能体构建模型：编排者并行派发角色智能体；每个角色智能体从 /contracts/ 读取机器可读契约；qe-agent 通过 qa-report.json 对构建进行门禁。单智能体或临时性工作不适合使用本技能。核心理念为约 50% 精力用于设计（架构、契约、文件归属）、20% 用于并行实现、30% 用于 QA/评审/集成；在没有契约的情况下急于派发智能体是多智能体构建失败的首要原因。

【主要能力】

1. 按阶段调用配套技能：nano-banana（种子图像）、ui-ux-pro-max 与 frontend-design（UI 质量）、ux-review 与 render-sanity（构建后渲染级验证）、design-token-guard（源码级设计令牌门禁）、class-extraction-guard（源码级类组织门禁）、repo-deep-dive（参考研究）、llm-wiki（项目知识库）、mermaid-charts（架构图）、deployment-checklist（发布就绪）。
2. 并行派发角色智能体：backend-agent、frontend-agent、infrastructure-agent、db-migration-agent、security-agent、observability-agent、performance-agent、docs-agent、qe-agent。
3. 将差异/代码评审委托给外部 /code-review CLI；仓库内 code-review-agent 不是默认构建阶段，仅在有意进行独立仓库感知评审时调用。
4. 不抢占、不先于构建阶段执行 brainstorming、plan-builder、writing-plans、claude-design-brief、ui-brief、feature-dev、claude-mem:* 等前置技能，而是从它们产出的工件继续。
5. 以循环方式运行验证阶段：wave gate 与 QA gate 是收敛循环；fix-until-green 驱动安装/类型检查/测试/QA 从红到绿；loop-controller 提供迭代→评估→护栏→停止的底层框架，其无进展/振荡护栏即 3 次失败熔断。原生 Agent Teams 下由 orchestrator-task-loop 驱动整个任务列表外层循环。上述循环均为 disable-model-invocation: true，需显式派发，不会因测试失败自动触发。
6. 任务需要时可派发四个构建循环：contract-conformance-loop（按规格构建，由全新上下文评估者评分）、coverage-loop（测试覆盖率目标）、perf-loop（性能预算）、migration-loop（枚举式大范围重构集）。

【使用方式要点】

• Git 分支策略：所有编排构建在功能分支上进行，绝不直接在 main 上操作；开始前创建描述性分支，频繁提交，不合并、不推送 main，除非用户明确要求合并或创建 PR。
• 快速开始：先查 wiki（若有 Obsidian wiki，先调用 wiki-research，约 3–4 页 wiki 可替代爬取大量源码）；创建功能分支；阶段 0 审计外部服务（读取其 Terraform/部署配置，运行中服务的允许来源、重定向 URI 和环境变量是硬约束）；将计划/任务书作为多阶段脚本阅读并端到端执行各阶段；生成任务技能清单 coordination/MISSION_SKILLS.md；若存在则审计 docs/agents/ 下 domain-docs.md、contract-format.md、work-item-tracker.md 三个配置文件，缺失时提示用户运行 /setup-project-skills 或采用默认值；按 references/team-sizing.md 确定团队规模；在契约前调用创意与研究类技能产出真实工件；编写契约（关键阶段，调用 contract-author）；使用精简提示并行派发智能体，角色标签不是子代理类型，需用 general-purpose 并在提示中携带角色技能；强制派发 QE 智能体；在并行波次之间协调并执行 wave gate；以 QA 报告为门禁；构建后按顺序验证：确认开发栈确实在监听、执行真实价值路径的现实门禁、调用 render-sanity 做四项客观检查、调用 ux-review 做主观评审、进行代码与安全评审、如发布则执行 deployment-checklist；最后重读原计划逐项核对完成情况。

【运行时检测】 若 ultracode 开启或用户明确提及 workflow/dynamic workflow，进入 Workflow 模式（首选）：用 Workflow 工具驱动实现与验证阶段，设计/契约仍内联进行。否则若设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS，进入原生 Agent Teams（tmux、TeammateTool、收件箱、共享任务列表），外层驱动循环为 orchestrator-task-loop。否则若 Agent/Task 工具可用，使用 Task/Agent 工具并行子代理。否则进入顺序模式，逐个角色依次处理，由用户协调上下文切换。模型与 effort 按角色分别设置，遵循 model-adaptation 的分层策略，每次派发显式传入 model 和 effort，且在同一提供商的层级内选择。

【适用场景与限制】 适用于需要并行角色分工、明确契约与质量门禁的中大型构建。限制包括：偏重并行与显式交接，单智能体工作或快速迭代应改用直接提示；编排者不得亲自实现代码；所有智能体间通信经过编排者（契约与共享文件变更方面）；文件冲突需在派发前解决，无法解决时由人决定；所有验证技能在任务要求时都不是可选的；构建分支在用户明确要求前保持独立。

【暂未提供】 资料未提供具体收费、价格、平台兼容性细节，也未提供可直接运行的安装命令或代码示例。