SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场orca-implement

orca-implement

编程与开发

查看项目

更新于 10-16 06:07

技能介绍

用途

Orca implement 是一个编排技能，用于把一批 GitHub issue 或一个 GitHub 里程碑整体实现出来。它把协调者（Coordinator）作为核心角色：由协调者规划波次、为每个 issue 创建独立的 Orca worktree、启动受监督的 Orca worker，并维护看板状态、提交、推送和拉取请求。每个 worker 只负责自己那一个 issue 的代码改动。

主要能力

  • 批量规划：读取每个 issue 的标题、正文、评论、验收标准和关联说明，结合仓库的 agent 指令（AGENTS.md、CLAUDE.md、贡献文档）定位涉及的代码，判断 issue 之间的依赖关系。
  • 波次并行：把 issue 分组为波次，第一波无依赖，后续波次只依赖更早的波次；默认最多同时运行四个 worker，除非用户另行设定上限。
  • 独立工作区：为每个 issue 创建一个 Orca worktree，并可通过 --parent-worktree 将其归组到父 worktree 下（整批交付时为集成 worktree，逐 issue 交付时为所依赖 issue 的 worktree）。
  • 受监督执行：每个实现都在用 worker-start 启动的 Orca worker 中运行；协调者负责规划、读仓库和写规格，worker 只做代码改动。
  • 看板状态维护：通过 ORCA worktree set --workspace-status 在 todo、in-progress、in-review、completed 之间流转，并用 --comment 记录 PR 链接或阻塞原因。
  • 交付方式：支持整批一个功能分支加一个 PR，或每个 issue 一个功能分支加一个 PR。

使用方式

  1. 加载 Orca：调用编排技能，解析其描述的 Orca 可执行文件，并加载与版本匹配的指南；该指南是命令语法、check --wait 循环、settlement、release 和恢复的唯一事实来源。运行本技能即表示用户明确请求监督，因此由你担任 Coordinator。
  2. 前置检查：必须先成功执行 ORCA status --json。如果编排命令被拒绝为禁用，提示用户在 Orca Settings → Experimental 中启用后停止。
  3. 选择 agent 与交付方式：默认每个 worker 运行与你相同的 agent（Claude Code 用 claude，Codex 用 codex 等），并在已知模型 id 时通过 --model 传入；用户可为所有 issue 指定其他 agent，或按 issue、按工作类型分配。交付方式需询问用户：整批一个功能分支加一个 PR，或每个 issue 一个功能分支加一个 PR；在得到答复前不要触碰仓库。
  4. 规划波次：完整读取 issue 列表，判断依赖（B 需要 A 的代码，或两者改动同一文件/同一契约足以冲突时，B 依赖 A），分组为波次，向用户展示每行一个 issue 的波次计划（含 agent 与依赖）后开始。
  5. 建立看板：用 run-create 为整批创建一个 Run；整批交付时先创建集成 worktree（ORCA worktree create --repo path:<repo root> --name <batch-slug> --no-parent --setup skip --json），再为每个 issue 创建 worktree（ORCA worktree create --repo path:<repo root> --name issue-<number>-<slug> --issue <number> --setup run --json，随后 ORCA worktree set --worktree id:<worktree_id> --workspace-status todo --json），并用 task-create 为每个 issue 创建 Task。
  6. 启动 worker：当 issue 就绪（依赖已提交且有空闲 worker 槽位）时，先更新分支（整批交付用 git -C <path> merge --ff-only <integration branch>；逐 issue 交付合并依赖分支），设为 in-progress，再执行 ORCA orchestration worker-start --task <task_id> --worktree id:<worktree_id> --agent <agent> [--model <id>] --json。同一波次的所有就绪 issue 应在第一次等待前全部启动。
  7. 监督：运行编排指南的等待循环直到所有 Task 结束。用 worker-read 仅在诊断卡住或失败的 worker 时读取输出。对成功者，对照验收清单审查 git diff，提交并引用 issue，释放 worker，然后按交付方式合并到集成分支或推送并开 PR；对失败或升级，若因缺少上下文则补充后重试（worker-start --task <task_id> --retry-of <dispatch_id> --worktree id:<worktree_id> --agent <agent>），否则设为 todo 并记录阻塞，暂缓依赖它的 issue。
  8. 交付：整批交付时，在所有能落地的 issue 落地后推送集成分支，开一个覆盖整批的 PR（每个已合并 issue 一行 Closes #<number>），并把集成 worktree 设为 in-review；逐 issue 交付时每个 PR 已开好。最后按 issue 给出状态、agent、PR 链接和未解决阻塞的简明列表。

Worker 规格

Task 规格是 worker 的全部世界：worker 在自己的 worktree 中全新启动，对本对话、整批和其他 worker 一无所知。规格需让有能力的工程师无需提问即可完成 issue。Orca 会前置生命周期前言（Task 与 Dispatch ID、ask、check、worker_done 命令），规格承载其余内容，包含：Workspace（worktree 路径、分支、基线、仓库、构建/测试/lint 命令、依赖的已完成 issue、并行 issue 及其负责区域）、Issue（issue 正文逐字、细化或改变范围的评论逐字并注明作者）、Target（范围内的文件、模块、组件）、Change（要产出的具体结果）、Constraints（不变量、兼容规则、非目标、不得触碰的区域）、Acceptance（每条验收标准作为可勾选项、要运行的验证命令、UI 工作需在本 worktree 的 Orca 浏览器标签中验证）、Git and reporting（留在分支上、改动不提交，由协调者审查、提交、推送和开 PR；未决问题用前言的 ask 命令并等待回答；结束时用前言的 worker_done 一次，带 --outcome succeeded 或 --outcome failed、--files-modified 列出所有改动文件，以及简短亮点、验证结果和协调者需要的说明）。

适用场景

  • 需要一次性实现多个相互关联的 GitHub issue 或一个里程碑。
  • 希望并行推进、但又要控制冲突和依赖顺序的团队。
  • 需要每个 issue 独立工作区、独立 PR，或整批一个 PR 的交付流程。
  • 需要看板状态真实反映每个 issue 所处阶段（待办、进行中、评审中、已完成）。

限制

  • 必须先成功执行 ORCA status --json；若编排命令被禁用，需在 Orca Settings → Experimental 中启用。
  • 默认最多同时运行四个 worker，除非用户设定其他上限。
  • 每个 worker 只负责一个 issue 的代码改动，不负责提交、推送和 PR。
  • 依赖判断基于代码、文件或契约冲突；无法确定依赖时按并行处理。
  • 关于具体命令的语法、check --wait 循环、settlement、release 和恢复，以版本匹配的 Orca 编排指南为准；本技能只在其上增加批量形态。
  • 资料未提供收费、价格、平台支持范围等具体信息。