Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/gitpcl/openorchestrator/open-orchestratornpx skills add gitpcl/openorchestrator --skill open-orchestratorgit clone --depth 1 https://github.com/gitpcl/openorchestratorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/gitpcl/openorchestrator/open-orchestrator)<a href="https://agentmods.dev/skills/gitpcl/openorchestrator/open-orchestrator"><img src="https://agentmods.dev/badge/skills/gitpcl/openorchestrator/open-orchestrator.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00608 | $0.04509 |
| Opus 5 | $0.00304 | $0.02254 |
| Sonnet 5 | $0.00122 | $0.00902 |
| Haiku 4.5 | $0.00061 | $0.00451 |
Grade A, and why
open-orchestrator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 300 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Open Orchestrator — the multi-provider cockpit for parallel AI coding
Open Orchestrator (owt) supervises parallel AI coding sessions across isolated git worktrees. It does not try to be the agent — it hosts whatever AI coding tool you point it at (Claude Code, Pi, Droid, OpenCode, or a custom tool) and gives you one place to watch and steer them all.
Two things make it worth using, and native tooling lacks both:
- A persistent cross-worktree control plane — a standing board across long-lived worktrees, three lanes deep (NEEDS YOU / READY TO SHIP / IN FLIGHT), driven entirely from the keyboard.
- Conflict Guard — real-time file-overlap detection that warns you the moment two agents start editing the same files, long before they collide at merge.
The primary interface is one command: owt — it launches the control plane. Press n to start work (type a task, pick one worktree or a native plan-first workflow, confirm), a to attach, s to ship, f to fix conflicts, m to merge. Every row carries verb actions and the footer shows only the keys that apply to the focused row.
You own the cockpit; the AI tools own the engine.
Commands (scripting / CI reference)
Humans drive the control plane with owt and the keys above; the verbs below are the same actions exposed for scripts, pipelines, and automation.
| Command | Alias | Description |
|---|---|---|
owt |
Launch the Control Plane — prioritized lanes, row verbs | |
owt new "task" |
owt n |
Create worktree + session + deps + AI agent. One command. |
owt new "task" --workflow |
Launch a native plan-first Claude Code workflow in the worktree | |
owt new "task" --ai-tool <name> |
Pick the provider (claude/pi/droid/opencode/custom) | |
owt new "task" --herdr |
Use the herdr multiplexer backend instead of tmux | |
owt new "task" --tmux |
Force tmux backend (default; useful to override config) | |
owt new "task" --headless |
Create worktree without tmux (CI/script use) | |
owt branch "task" |
Create branch in current checkout instead of worktree (faster, zero disk) | |
owt list |
owt ls |
Quick text list of worktrees (non-interactive, for scripts/pipes) |
owt switch <name> |
owt s |
Jump to a worktree's session |
owt attach <name> |
Hand off to the worktree's session via the active backend (--herdr / --tmux to override) |
|
owt send <name> "msg" |
Send command to a worktree's AI agent | |
owt send --all "msg" |
Broadcast to ALL worktrees | |
owt send --working "msg" |
Broadcast to WORKING worktrees only | |
owt merge <name> |
owt m |
Two-phase merge + Conflict Guard + auto-cleanup (--rebase, --strategy, --leave-conflicts) |
owt ship <name> |
Commit + merge + delete in one shot | |
owt delete <name> |
owt rm |
Delete worktree + session + status |
owt queue |
Show optimal merge order (with overlap counts) for completed worktrees | |
owt queue --ship |
Ship all completed worktrees in optimal order | |
owt wait <name> |
Poll until agent finishes (for CI/scripts) | |
owt note "msg" |
Share context across all agent sessions | |
owt sync [--all] |
Sync worktree(s) with upstream | |
owt cleanup [--force] |
Remove stale worktrees (dry-run by default) | |
owt config validate |
Validate configuration file | |
owt config show |
Display effective config as TOML | |
owt db purge [--days N] |
Delete messages older than N days (default 30) | |
owt db vacuum |
Optimize and compact the database | |
owt db health [--check] |
Database health diagnostics with CI thresholds | |
owt doctor [--fix] |
Diagnose and fix orphaned resources | |
owt usage [--days N] |
Local usage counts (cockpit launches, worktrees started) | |
owt --theme <name> |
Override UI theme (auto, dark, light, dark-ansi, light-ansi) | |
owt --json <cmd> |
Machine-readable JSON output for list, queue, doctor, db health |
|
owt version |
Show version |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 300 lines · 608 tokens per session scan A fefaee976572
open-orchestrator is a skill published in the GitHub repository gitpcl/openorchestrator (5 stars, last pushed 1mo ago), licensed MIT. It adds 608 tokens to every session and 4,509 once invoked, about $0.0030 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
flow
Orchestrator for Ticket-Flow — default is --local (all phases in this session with user checkpoints). --parallel works multiple ready tickets at once via worktree-isolated subagents in this session; --serial (one subagent at a time, merge+deploy+cleanup per ticket) and --loop (re-query the ready queue after every…
task-ledger
Ledger development tasks to Feishu Base via dev-task-ledger.sh. Write roots from /.openclaw/tasks-allowlist.json (per agent). Use on accept/confirm/close of coding/ops work; not for pure Q&A.
init
Scaffold a ticket-flow project — one-time setup; trigger on "setz ticket-flow auf", "richte das Projekt für ticket-flow ein", "set up ticket-flow here". Runs bd init with tf's agents template (keeps Claude Code's own memory system), scaffolds spec dirs and worktree settings, migrates an existing KANBAN.md into beads.…
pickup
Internal phase 1 of ticket-flow, normally invoked by ticket-flow:flow — validate Definition of Ready, create (or adopt) the ticket's isolated worktree, set the branch lock, claim the item atomically → In Progress. Invoke directly only for recovery, or when the user explicitly wants just the claim+worktree step. Args…
implement
Internal phase 2 of ticket-flow, normally invoked by ticket-flow:flow — execute the plan for the claimed ticket inside its worktree: incremental commits, typecheck/test after each major step. Invoke directly only to continue implementing a ticket that is already picked up.
kanban
Use when a prompt contains a new bug/feature/change not yet tracked, or when an item's status changes — capture and maintain it in the project's beads tracker (Inbox→Backlog with Definition of Ready, priorities, the pipe-separated note format).