By name: stockai-orchestrator description: StockAI 的总编排器，按请求类型分诊到「审查 / 功能开发 / 发布」三个 Agent 团队。代码改完要审查、跨三层加新功能、发版出新版本、以及对这些结果的后续修改/重跑/补充/更新/部分重做时，都用此技能。简单单点问题或单文件小改可直接处理，无需起团队。
StockAI Orchestrator
StockAI 的总编排器，把请求分诊到三个专家 Agent 团队，协调多 Agent 协作产出。复用项目已有的审查员、生成技能与发布清单。
实行模式：混合（Hybrid）
| 工作流 | 模式 | 模式选择理由 |
|---|---|---|
| 审查（Review） | Agent 团队（fan-out/fan-in） | 4 个审查员并行，发现互通、避免重复报告，交叉验证提升质量 |
| 功能开发（Feature） | Agent 团队（pipeline + 并行实现） | 架构师→前后端并行实现→QA，工程师间实时对齐接口 shape |
| 发布（Release） | 顺序执行 + 门禁（单 Agent） | release-checklist 偏确定性顺序，CI 全绿是硬闸门，团队通信收益低 |
Phase 0：分诊（必做第一步）
判断请求属于哪类工作流，路由到对应 reference：
| 信号 | 工作流 | 加载 reference |
|---|---|---|
| 「审查这段/这个 PR」「改完了帮我看看」「能合并吗」「review」「提交前检查」 | 审查 | references/review-team.md |
| 「加个功能」「新增 X」「跨层实现 Y」「让它支持 Z」 | 功能开发 | references/feature-team.md |
| 「发版」「出 vx.y.z」「release」「打 tag」「更新版本」 | 发布 | references/release-team.md |
| 「加 provider / 大师 / 抓取策略」 | 直接技能（无需团队） | 触发 /add-provider、/new-master-agent、/new-strategy |
| 单点事实问题、单文件 typo/注释小改 | 直接处理 | 不起团队 |
分诊不明确时，向用户澄清属于哪类，而非默认起最大的团队。
Phase 1：上下文确认（后续作业支持）
起团队前确认是初次还是续作：
- 检查
_workspace/是否存在。 - 决定执行模式：
_workspace/不存在 → 初次执行，建_workspace/，进入对应工作流。- 存在 + 用户要求部分修改/补充/重跑某部分 → 部分重执行：只重启相关 Agent，读取旧产物增量更新。
- 存在 + 提供了新输入（新的审查对象/新功能/新版本） → 新执行：把旧
_workspace/移到_workspace_prev/，再建新的。
- 部分重执行时，把旧产物路径写进 Agent 提示，让其读取并基于反馈改进。
Phase 2：加载工作流 reference 并执行
读取 Phase 0 选定的 reference 文件，按其中的团队构成、TeamCreate/TaskCreate 配置、数据流与门禁执行。各 reference 自带：
- 审查：
references/review-team.md— 4 审查员 fan-out（api-key-security / i18n-consistency / layer-boundary / code-quality），leader 汇总去重成统一报告。 - 功能开发：
references/feature-team.md— feature-architect 出蓝图 → backend-engineer + frontend-engineer 并行实现（实时对齐 shape）→ integration-qa 增量验证。 - 发布：
references/release-team.md— release-manager 按 7 步清单执行，CI 全绿硬门禁，双语 Notes 覆盖。
数据传递协议
- 文件基（跨 Phase/Agent 产物）：统一写
_workspace/，命名{workflow}_{agent}_{artifact}.md；最终报告/产物输出到用户指定处或仓库，_workspace/保留供审计。 - 消息基（团队内实时）：
SendMessage用于审查员互通发现、前后端对齐接口 shape、QA 反馈。 - 任务基（团队协调）：
TaskCreate/TaskUpdate管理依赖与认领，每团队成员 4~6 个任务为宜。
错误处理
| 情况 | 策略 |
|---|---|
| 某 Agent 失败/中止 | 1 次重试；再失败则在报告中标注该维度缺失并继续，不阻塞其余 |
| 过半 Agent 失败 | 停下，告知用户并确认是否继续 |
| 团队成员数据冲突 | 标注出处后并列保留，不删除 |
| 发布 CI 未绿 | 硬停，报告失败 job，不强推 tag |
| 高风险 git 操作（force/reset --hard/--no-verify） | 需用户显式授权，不擅自执行 |
测试场景
正常流（审查）：用户「改完了，审一下」→ Phase 0 判为审查 → Phase 1 建 _workspace/ → 读 review-team.md → TeamCreate 4 审查员 + TaskCreate → 并行审查写各自 review_*.md → leader Read 汇总去重 → 输出统一报告（按严重度排序）→ 保留 _workspace/。
错误流（功能开发）：integration-qa 发现前后端 DTO shape 不一致 → SendMessage 通知 backend-engineer 字段:行号 → backend 修正并重发 shape → frontend 对齐 → QA 复验转 PASS → 若三次仍 FAIL，报告中标注该模块未通过并交还用户决策。
完成后
执行完一个工作流后，简要询问用户是否需要调整团队构成/流程（Phase 7 进化）；有反复出现的反馈（同类 ≥2 次）则主动提议改对应 Agent/技能，并在 CLAUDE.md 变更历史登记。