constellation-works/orbit/tree/agent-main/plugin
orbit
為 AI 程式代理提供持久任務、沙盒平行執行與 PR 閘門交付。將 Orbit 的 MCP 工具與工作流程 skill 加入 Claude Code。
關於這個 mod
<p align="center"> <a href="https://orbit-cli.com"> <picture> <source media="(prefers-color-scheme: dark)" srcset="docs/assets/orbit-lockup-on-dark.svg" /> <img src="docs/assets/orbit-lockup-on-light.svg" alt="Orbit" width="340" /> </picture> </a> </p> <h3 align="center">代理撰寫。Orbit 交付。</h3> <p align="center"> <a href="https://github.com/constellation-works/orbit/releases"><img src="https://img.shields.io/github/v/release/constellation-works/orbit" alt="Release" /></a> <a href="https://www.npmjs.com/package/@orbit-tools/cli"><img src="https://img.shields.io/npm/v/@orbit-tools/cli" alt="npm" /></a> <a href="LICENSE.md"><img src="https://img.shields.io/badge/license-MIT-blue" alt="License: MIT" /></a> <a href="https://orbit-cli.com"><img src="https://img.shields.io/badge/docs-orbit--cli.com-informational" alt="Docs" /></a> </p> <p align="center"> <img src="docs/assets/orbit-demo.gif" alt="Animated tour of the real Orbit dashboard on a live workspace: proposed tasks waiting for your approval, an auto-drain running tasks in parallel while overlapping work waits on file locks, a task's durable record, the run list, a pull-request pipeline run stepping from isolated worktree through implement, commit, review gate, and push to pr_open, the audit log of every tool call, and a scoreboard comparing Codex, Claude, Grok, and Gemini." width="880" /> </p>Orbit 是以本機優先為設計的程式代理執行階段。你可以繼續使用 Claude Code、Codex、Cursor、Copilot 或其他受支援的 CLI。Orbit 提供持久任務佇列、隔離的沙盒工作樹、平行執行的檔案層級鎖定、以拉取請求結束的閘門流程,以及記錄每一步的稽核記錄。
原因: 代理已經夠快,規劃、審查與可追溯性反而最先被犧牲。六個月後,沒人說得清楚某一行為什麼這樣寫。Orbit 讓這些規範的成本很低,也讓你不用再處理文書工作。代理建立任務,Orbit 執行任務,每個提交都帶有任務 ID,可以追溯到提示、計畫與審查。
- 單一二進位檔,不上雲。 狀態位於
~/.orbit與.orbit/。不會向外連線。 - 帶上你自己的代理。 Orbit 驅動你已完成驗證的供應商 CLI,從不索取 API 金鑰。
- MIT 授權。 沒有付費方案,也不提供代管服務。
運作方式
$ orbit init # one-time, per machine
$ cd my-repo && orbit workspace init --mcp # per repo; wires Orbit into your agent CLIs
$ orbit web serve # open the Orbit dashboard in your browser
You: The fsProfile lookup is undocumented. Get that fixed.
Agent: orbit.task.add → ORB-1042 · proposed
Filed with acceptance criteria. Approve it and ship?
You: Yes.
Agent: orbit.task.update → ORB-1042 · backlog
orbit.workflow.ship → worktree isolated · file scope locked · plan → execute → review
Pull request opened. ORB-1042 is in review. The diff and the merge are yours.
$ orbit task update ORB-1042 --approve # after you merge: review → done
<sub>示意工作階段。工具名稱是真實的,ID 是佔位符。</sub>
如果有多個任務,把規格交給代理並請它負責編排。隨附的 orbit-orchestrate skill 會把規格拆成任務,在你核准後排入佇列,使用 orbit run auto 平行執行,並診斷失敗的執行。
- 沒有你的核准,任何任務都不會開始。 新任務會進入
proposed,只有你核准後才會移到backlog。 - 每次執行都會以拉取請求結束。 Orbit 不會自行合併。合併 PR 與完成任務是兩個獨立決定,除非你明確傳入
--complete。 - 所有事情都有記錄。
orbit task show ORB-1042會重建提示、計畫、執行軌跡與審查討論串,即使幾個月後也一樣。
快速開始
你需要: macOS 或 Linux(x64 或 arm64;Windows 上請在 WSL2 中執行 Orbit,因為沒有原生 Windows 建置:參見 Windows WSL2 指南)、Node 18+、至少一個已完成驗證的代理 CLI;如果要使用拉取請求,還需要完成驗證的 gh。
npm install -g @orbit-tools/cli
orbit init # asks for a machine name and a task-ID prefix, links Orbit's skills into your agents, and on Linux prepares the sandbox
接著讓代理設定儲存庫。 在儲存庫中開啟代理,請它*「為這個儲存庫設定 Orbit」*。隨附的 orbit-setup skill 會註冊儲存庫,透過 MCP 連接代理,並執行 orbit doctor,只詢問它無法推斷的內容,例如拉取請求應該指向哪個分支。完成後啟動新的代理工作階段,讓 Orbit 工具載入,再交代一件事:它會建立任務、請求核准、交付任務並回報 PR。使用 orbit web serve 查看全部過程。
cd <repo> && orbit workspace init --mcp # add --ship-mode local to skip PRs
orbit doctor
orbit web serve
在第一次交付前,審查並提交 workspace init 列出的檢出檔案。本機交付要求基礎檢出乾淨;清單包含 MCP 使用者端檔案。
orbit doctor 會回報預設路由、系統路由或複雜度路由所選團隊缺少哪些 CLI,並在這個工作區沒有註冊 Orbit MCP 使用者端時提出警告。它只檢查 CLI 是否存在以及註冊檔案;不會檢查供應商登入與 MCP 連線。使用 orbit doctor providers 檢視所有執行器定義,包括未被工作流程路由選取的供應商。在 Linux 上,參見 沙盒就緒狀態與發行版涵蓋範圍。
| 操作 | 執行 |
|---|---|
| 檢查任務或執行 | orbit task show <ID> · orbit run show <RUN_ID> |
| 開啟控制面板 | orbit web serve(遠端:orbit web connect <host>) |
| 選擇預設團隊(供應商與模型) | orbit config set workflow.default_crew <crew> |
| 升級 | npm install -g @orbit-tools/cli@latest(orbit update --check 會顯示新內容) |
每個 MCP 工具都有對應的 CLI。
TASK_ID=$(orbit task add --title "..." --description "..." \
--acceptance-criteria "..." --complexity medium --workspace .)
orbit task update "$TASK_ID" --approve # proposed → backlog
orbit run ship "$TASK_ID" # async; prints a run ID
orbit run show <RUN_ID> # progress and outcome
orbit task update "$TASK_ID" --approve # after merging the PR: review → done
</details>
功能
規劃與治理
- 帶有意圖的持久任務。 任務包含驗收條件、檔案範圍、相依性與具類型的關聯。它們會在
proposed → backlog → in-progress → review → done之間移動,而且狀態會跨工作階段與分支保留。 - 結構化稽核記錄。 每次工具呼叫、供應商交換與狀態轉換都會記錄成可追加、可查詢的事件,並標記產生它的代理與模型(
orbit audit)。 - 摩擦帳本。 工作若因令人困惑的錯誤、缺少旗標或未記錄的慣例而比應有的更困難,代理會使用
orbit friction add記錄,而不是悄悄繞過問題。解決摩擦的任務完成時,也會關閉這項摩擦。 - 本機搜尋。
orbit search會在任務與摩擦上執行快速字彙搜尋(SQLite FTS5),不需要下載模型。
安全地平行執行
- 隔離的沙盒執行。 每次執行都有自己的 git 工作樹,並在 macOS 上透過
sandbox-exec、Linux 上透過 Bubblewrap 執行代理 CLI。在 Linux 上,工作程序也會受 cgroup 的記憶體限制。 - 感知衝突的排程。 執行開始前會把任務檔案保留為鎖定,因此重疊工作會排隊等待,而不是稍後產生合併衝突。
- 閘門流程。 每次執行會經過 plan → execute → review,並具備修復額度與失敗復原。相依性控制進入條件;你只需宣告一次順序,佇列會強制執行。
- 九個由團隊路由的代理 CLI。 Claude Code、Codex、Cursor、Copilot、Grok、Gemini、Antigravity、OpenCode 與 Pi。團隊會固定供應商、模型與工作強度。按複雜度分級的加權團隊池會在這些代理間分配工作。
無人值守執行
- 有界排空。
orbit run auto --for 4h --concurrency 8會在時間視窗結束前交付待辦工作。orbit run readiness會預覽將會執行的內容而不啟動任何工作。也可以請代理執行一次:orbit-orchestrateskill 會準備待辦、啟動排空,並處理失敗的執行。 - 選擇性完成。 GitHub 允許後,
--complete會合併 PR,並在確認合併後關閉任務。沒有其他設定會啟用這項功能。 - 持續審查。 隨附的
code-review、qa-sweep與security-review自動任務會讀取上次執行後落地的所有內容,根據即時程式碼核實發現,並以file:line證據將確認的問題建立為任務。 - 把週期工作當成資料。 排程任務範本位於
.orbit/auto_tasks/*.yaml,一個機器排程器(orbit clock)會執行例行工作與自動任務。 - 多機器。 分散式排空透過持久宣告把待辦工作分散到多台機器。聯邦 MCP 伺服器會把本機與 SSH 遠端工作區放在同一個命名空間。
觀察與延伸
- 控制面板(
orbit web serve)。顯示待辦工作、即時稽核串流、各代理計分板、工作、摩擦與生效設定,並支援行內編輯。 - 外掛(
orbit plugin)。外掛可以加入自己的工具、工作、例行工作、自動任務、skill 與 CLI 命令。外掛會在明確授予權限下以沙盒方式執行,orbit plugin scaffold會產生起始範本。 - 代理 skill。 Orbit 隨附三個 skill:
orbit(日常任務工作)、orbit-orchestrate(待辦與派工)以及orbit-setup(機器與儲存庫設定)。orbit init會將它們連結到你的代理。
你可以一次採用一項。任務層與稽核記錄從第一天就能運作;平行排空、自動任務與外掛則在你需要時啟用。
代理外掛
如果不把 CLI 安裝到 PATH,仍想讓單一代理使用 Orbit 的 MCP 工具與 skill,可以加入外掛。它會啟動固定版本的 npm CLI。控制面板與跨代理工作區設定仍需要安裝 CLI。
# Claude Code
/plugin marketplace add constellation-works/orbit
/plugin install orbit
# Codex CLI
codex plugin marketplace add constellation-works/orbit --ref agent-main
codex plugin add orbit@orbit
# Cursor (local plugin from a checkout)
mkdir -p ~/.cursor/plugins/local && ln -sfn "$(pwd)/plugin" ~/.cursor/plugins/local/orbit
想要有人帶你完成設定?請代理*「為這個儲存庫設定 Orbit」*,隨附的 orbit-setup skill 會接手後續工作。
Claude Code 桌面版
在 Claude Code 中,外掛也會帶來 Orbit mod:提示列上方的一條帶狀區域,顯示工作區執行中、阻塞與審查的數量;Orbit 面板則提供任務板、會預檢並追蹤 orbit run ship 的交付檢視,以及軌道地圖。使用 /orbit-board、/orbit-ship 與 /orbit-map 開啟它們。檢出目錄是副本時,將外掛的 ownerHost 選項設定為擁有者的 SSH 主機。參見 plugin/hooks/mod。
Codex 桌面版
你需要 Node.js 18+(包括 npx)以及位於 PATH 上的 Codex CLI。
-
從終端機註冊 Orbit marketplace:
codex plugin marketplace add constellation-works/orbit --ref agent-main -
重新啟動桌面應用程式。開啟 Plugins Directory,選擇 Orbit marketplace,然後安裝 Orbit。
-
在儲存庫中開始新的聊天,並詢問:「為這個儲存庫設定 Orbit」。
參見 [官方 marketplace 設定指南](https://developers.openai.com/plugins/build/plugins#add-a-marketplace-from-th
安裝
請先查看作者 README,確認 marketplace 與外掛名稱;指令可能隨儲存庫結構而變動。
claude plugin marketplace add constellation-works/orbit claude plugin install orbit
原文 / README
Orbit is a local-first runtime for coding agents. You keep using Claude Code, Codex, Cursor, Copilot, or any of the other supported CLIs. Orbit gives them a durable task queue, isolated sandboxed worktrees, file-level locks for parallel runs, a gated pipeline that ends in a pull request, and an audit log of every step.
Why: agents are fast enough that planning, review, and traceability are the first things to go. Six months later nobody can say why a line was written. Orbit makes those disciplines cheap and keeps you out of the clerical work. The agent files the task, Orbit runs it, and every commit carries a task ID you can trace back to the prompt, the plan, and the review.
- Single binary, no cloud. State lives in
~/.orbitand.orbit/. Nothing phones home. - Bring your own agents. Orbit drives the provider CLIs you already have authenticated, and never asks for API keys.
- MIT licensed. No paid tier, no hosted offering.
How it works
$ orbit init # one-time, per machine
$ cd my-repo && orbit workspace init --mcp # per repo; wires Orbit into your agent CLIs
$ orbit web serve # open the Orbit dashboard in your browser
You: The fsProfile lookup is undocumented. Get that fixed.
Agent: orbit.task.add → ORB-1042 · proposed
Filed with acceptance criteria. Approve it and ship?
You: Yes.
Agent: orbit.task.update → ORB-1042 · backlog
orbit.workflow.ship → worktree isolated · file scope locked · plan → execute → review
Pull request opened. ORB-1042 is in review. The diff and the merge are yours.
$ orbit task update ORB-1042 --approve # after you merge: review → done
<sub>Illustrative session. The tool names are real, and the IDs are placeholders.</sub>
For more than one task, hand your agent a spec and ask it to orchestrate. The bundled orbit-orchestrate skill splits the spec into tasks, queues them once you approve, runs them in parallel with orbit run auto, and diagnoses any run that fails.
- Nothing starts without you. New tasks land in
proposed, and only your approval moves them tobacklog. - Every run ends at a pull request. Orbit never merges on its own. Merging the PR and completing the task are separate decisions, unless you explicitly pass
--complete. - Everything is on the record.
orbit task show ORB-1042reconstructs the prompt, plan, execution trace, and review thread, even months later.
Quick start
You need: macOS or Linux (x64 or arm64; on Windows, run Orbit inside WSL2, as there is no native Windows build: see the Windows WSL2 guide), Node 18+, at least one authenticated agent CLI, plus gh authenticated if you want pull requests.
npm install -g @orbit-tools/cli
orbit init # asks for a machine name and a task-ID prefix, links Orbit's skills into your agents, and on Linux prepares the sandbox
Then let your agent set up the repo. Open your agent in the repository and ask it to "set up Orbit for this repo". The bundled orbit-setup skill registers the repo, connects your agent over MCP, and runs orbit doctor, asking only for what it can't infer, such as the branch pull requests should target. Start a fresh agent session when it finishes so the Orbit tools load, then ask for something: it files the task, asks for approval, ships it, and reports the PR. Watch it all with orbit web serve.
cd <repo> && orbit workspace init --mcp # add --ship-mode local to skip PRs
orbit doctor
orbit web serve
Review and commit the checkout files listed by workspace init before the first ship. Local delivery requires a clean base checkout; the list includes MCP client files.
orbit doctor reports missing CLIs for crews selected by the default, system,
or complexity routing and warns when no Orbit MCP client is registered for this
workspace. It checks CLI presence and registration files only; provider sign-in
and MCP connectivity are not checked. Use orbit doctor providers to inspect
all executor definitions, including providers not selected by workflow routing.
On Linux, see sandbox readiness and distro coverage.
| To… | Run |
|---|---|
| Inspect a task or run | orbit task show <ID> · orbit run show <RUN_ID> |
| Open the dashboard | orbit web serve (remote: orbit web connect <host>) |
| Pick the default crew (provider and model) | orbit config set workflow.default_crew <crew> |
| Upgrade | npm install -g @orbit-tools/cli@latest (orbit update --check shows what's new) |
Every MCP tool has a CLI twin.
TASK_ID=$(orbit task add --title "..." --description "..." \
--acceptance-criteria "..." --complexity medium --workspace .)
orbit task update "$TASK_ID" --approve # proposed → backlog
orbit run ship "$TASK_ID" # async; prints a run ID
orbit run show <RUN_ID> # progress and outcome
orbit task update "$TASK_ID" --approve # after merging the PR: review → done
</details>
Features
Plan and govern
- Durable tasks with intent. Tasks carry acceptance criteria, a file scope, dependencies, and typed relations. They move through
proposed → backlog → in-progress → review → done, and that state survives sessions and branches. - Structured audit log. Every tool call, provider exchange, and state transition is recorded as an append-only, queryable event tagged with the agent and model that produced it (
orbit audit). - Friction ledger. When the work was harder than it should have been, whether from a confusing error, a missing flag, or an undocumented convention, the agent records it with
orbit friction addinstead of quietly working around it. A task that resolves the friction closes it on completion. - Local search.
orbit searchruns fast lexical search (SQLite FTS5) over tasks and frictions. It needs no model download.
Execute safely in parallel
- Isolated, sandboxed runs. Each run gets its own git worktree and runs its agent CLI under
sandbox-execon macOS or Bubblewrap on Linux. On Linux, worker runs are also memory-bounded in a cgroup. - Conflict-aware scheduling. Runs reserve their task's files as locks before starting, so overlapping work waits in line instead of producing merge conflicts later.
- Gated pipeline. Each run goes plan → execute → review, with repair budgets and failure recovery. Dependencies gate admission, so you declare the order once and the queue enforces it.
- Nine agent CLIs, routed by crews. Claude Code, Codex, Cursor, Copilot, Grok, Gemini, Antigravity, OpenCode, and Pi. Crews pin a provider, model, and effort level. Complexity-tiered, weighted crew pools spread the work across them.
Run unattended
- Bounded drains.
orbit run auto --for 4h --concurrency 8ships the backlog until the time window closes.orbit run readinesspreviews what would run without starting anything. Or ask your agent to run one: theorbit-orchestrateskill prepares the backlog, starts the drain, and works through failed runs. - Opt-in completion.
--completemerges PRs once GitHub allows it and closes tasks after the merge is verified. Nothing else turns this on. - Continuous review. The shipped
code-review,qa-sweep, andsecurity-reviewauto-tasks read everything that landed since their last run, verify findings against live code, and file confirmed ones as tasks withfile:lineevidence. - Recurring work as data. Scheduled task templates live in
.orbit/auto_tasks/*.yaml, and one machine scheduler (orbit clock) runs routines and auto-tasks. - Multi-machine. A distributed drain spreads a backlog across machines through durable claims. A federated MCP server puts local and SSH-remote workspaces under one namespace.
Observe and extend
- Dashboard (
orbit web serve). Shows the task backlog, live audit feed, per-agent scoreboard, jobs, frictions, and effective config, with inline editing. - Plugins (
orbit plugin). A plugin can add its own tools, jobs, routines, auto-tasks, skills, and CLI commands. Plugins run sandboxed under explicit permission grants, andorbit plugin scaffoldgenerates a starter. - Agent skills. Three skills ship with Orbit:
orbit(everyday task work),orbit-orchestrate(backlog and dispatch), andorbit-setup(machine and repo configuration).orbit initlinks them into your agents.
You can adopt these one at a time. The task layer and audit log work from day one. Parallel drains, auto-tasks, and plugins switch on when you want them.
Agent plugins
To give a single agent Orbit's MCP tools and skills without installing the CLI on PATH, add the plugin. It launches the pinned npm CLI. The dashboard and cross-agent workspace setup still need the CLI install.
# Claude Code
/plugin marketplace add constellation-works/orbit
/plugin install orbit
# Codex CLI
codex plugin marketplace add constellation-works/orbit --ref agent-main
codex plugin add orbit@orbit
# Cursor (local plugin from a checkout)
mkdir -p ~/.cursor/plugins/local && ln -sfn "$(pwd)/plugin" ~/.cursor/plugins/local/orbit
Want to be walked through setup? Ask your agent to "set up Orbit for this repo", and the bundled orbit-setup skill takes it from there.
Claude Code desktop
In Claude Code the plugin also brings the Orbit mod: a band above the prompt with the workspace's running, blocked, and review counts, and an Orbit pane with a task board, a ship view that preflights and tracks orbit run ship, and an orbital map. Open them with /orbit-board, /orbit-ship, and /orbit-map. When the checkout is a replica, set the plugin's ownerHost option to the owner's SSH host. See plugin/hooks/mod.
Codex desktop
You need Node.js 18+ (including npx) and the Codex CLI on PATH.
-
Register the Orbit marketplace from a terminal:
codex plugin marketplace add constellation-works/orbit --ref agent-main -
Restart the desktop app. Open the Plugins Directory, choose the Orbit marketplace, and install Orbit.
-
Start a new chat in your repo and ask: "set up Orbit for this repo".
See the official marketplace setup guide.
MCP and authority
orbit workspace init --mcp registers orbit mcp serve --operator with your agent CLIs. That operator session is the only one that can dispatch workflows, resume runs, or run commands. Agents launched by Orbit get an agent-only surface. Authority is enforced when a tool is called, not by hiding tools, so every session sees the same tools/list. Use orbit mcp init alone for an agent-only registration, or orbit mcp init --federated to put several machines under one namespace (details).
Where state lives
| Path | Holds |
|---|---|
| ~/.orbit/ | Machine state: task bundles, orbit.db (audit, runs, routines, frictions), workspace registry, shipped resources, skills, config.toml |
| <repo>/.orbit/ | Workspace state: identity, local config overrides, auto-tasks, routines, worktrees, and logs. Gitignored, and safe to delete for a clean slate. |
Backups, stuck runs, database recovery, and upgrades are covered in the runbooks.
Learn more
- orbit-cli.com: guides, concepts, and the full CLI and config reference
- docs/CONFIG.md: crews, pools, base branch, sandbox
- docs/POSITIONING.md: what Orbit is for, and what it deliberately isn't
- ARCHITECTURE.md and design docs
- CHANGELOG.md: Orbit is pre-1.0, and breaking changes ship in minor releases
Contributing
Pull requests are welcome, from typo fixes to new executors. Small fixes can go straight to a PR, and bigger changes start with an issue. See CONTRIBUTING.md to get set up.
License
其他同名作品
- orbitjamubc · ★ 0

