@enderfga/claw-orchestrator 7.2.0 → 7.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +4 -3
- package/dist/bin/mcp-server.js +1 -0
- package/dist/bin/mcp-server.js.map +1 -1
- package/dist/src/handoff.d.ts +80 -0
- package/dist/src/handoff.js +154 -0
- package/dist/src/handoff.js.map +1 -0
- package/dist/src/index.js +39 -0
- package/dist/src/index.js.map +1 -1
- package/dist/src/openai-compat.d.ts +1 -0
- package/dist/src/openai-compat.js +1 -1
- package/dist/src/openai-compat.js.map +1 -1
- package/dist/src/session-manager.d.ts +36 -0
- package/dist/src/session-manager.js +78 -1
- package/dist/src/session-manager.js.map +1 -1
- package/openclaw.plugin.json +1 -0
- package/package.json +1 -1
- package/skills/SKILL.md +3 -3
- package/skills/references/sessions.md +47 -0
- package/skills/references/tools.md +21 -1
package/skills/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: claw-orchestrator
|
|
3
|
-
description: Manage persistent coding sessions across Claude Code, Codex, Antigravity (agy), Grok Build, and OpenCode engines. Use when orchestrating multi-engine coding agents, starting/sending/stopping sessions, running multi-agent council collaborations, cross-session messaging, ultraplan deep planning, ultrareview parallel code review, autoloop autonomous workspace iteration, ultraapp building deployable web apps from a structured Q&A interview, switching models/tools at runtime, exposing the orchestrator's
|
|
3
|
+
description: Manage persistent coding sessions across Claude Code, Codex, Antigravity (agy), Grok Build, and OpenCode engines. Use when orchestrating multi-engine coding agents, starting/sending/stopping sessions, running multi-agent council collaborations, cross-session messaging, ultraplan deep planning, ultrareview parallel code review, autoloop autonomous workspace iteration, ultraapp building deployable web apps from a structured Q&A interview, switching models/tools at runtime, exposing the orchestrator's 78 tools as an MCP server to Hermes Agent / Claude Desktop / Cursor / Cline / Continue / Zed / Windsurf / Goose, or running as an Agent Client Protocol (ACP) agent that Zed / JetBrains / Neovim / Emacs / VS Code / dsh can drive directly. Triggers on "start a session", "send to session", "run council", "ultraplan", "ultrareview", "autoloop", "ultraapp", "Forge tab", "build a web app", "one-click app", "AppSpec", "autonomous iteration", "iterate until goal", "deep paper review", "auto research", "switch model", "hand off", "handoff", "switch engine", "continue on codex", "continue on claude", "move this session to another engine", "multi-agent", "coding session", "session inbox", "grok", "grok build", "opencode", "mcp server", "clawo-mcp", "hermes mcp", "model context protocol", "ultracode", "dynamic workflow", "fanout", "fan-out", "best-of-N", "steer turn", "interrupt turn", "fork thread", "rollback turns", "acp", "agent client protocol", "clawo acp", "zed agent", "jetbrains agent", "external agent", "dsh subagent", "deepseek harness", "clawo runs", "run ledger", "how much did it cost", "token usage", "spend cap", "budget limit", "maxBudgetUsd", "workflow", "durable workflow", "resume a run", "verify", "verification", "acceptance contract", "evidence", "evidence bundle", "did the tests actually pass", "prove it works", "human gate", "repair loop", "clawo workflow", "clawo verify".
|
|
4
4
|
metadata:
|
|
5
5
|
{
|
|
6
6
|
'openclaw':
|
|
@@ -36,7 +36,7 @@ metadata:
|
|
|
36
36
|
|
|
37
37
|
# Claw Orchestrator Skill
|
|
38
38
|
|
|
39
|
-
Claw Orchestrator — persistent multi-engine coding session manager for claw-style agent systems. Runs as a standalone CLI/server, with first-class OpenClaw plugin support. Wraps Claude Code, Codex, Antigravity, Grok Build, OpenCode, and custom CLIs into headless agentic engines with
|
|
39
|
+
Claw Orchestrator — persistent multi-engine coding session manager for claw-style agent systems. Runs as a standalone CLI/server, with first-class OpenClaw plugin support. Wraps Claude Code, Codex, Antigravity, Grok Build, OpenCode, and custom CLIs into headless agentic engines with 78 tools.
|
|
40
40
|
|
|
41
41
|
## Engine Quick Reference
|
|
42
42
|
|
|
@@ -188,7 +188,7 @@ For the full control protocol, registry/resume behavior, and ledger layout, see
|
|
|
188
188
|
|
|
189
189
|
| Category | Tools |
|
|
190
190
|
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
191
|
-
| Session Lifecycle | `session_start`, `session_send`, `session_stop`, `session_list`, `sessions_overview`
|
|
191
|
+
| Session Lifecycle | `session_start`, `session_send`, `session_handoff`, `session_stop`, `session_list`, `sessions_overview` |
|
|
192
192
|
| Session Ops | `coding_session_status`, `session_grep`, `session_compact`, `session_update_tools`, `session_switch_model` |
|
|
193
193
|
| Inbox | `session_send_to`, `session_inbox`, `session_deliver_inbox` |
|
|
194
194
|
| Teams | `coding_agents_list`, `team_list`, `team_send` |
|
|
@@ -77,6 +77,53 @@ await manager.startSession({
|
|
|
77
77
|
|
|
78
78
|
> `claude continue/respawn/stop/logs` are not headless subcommands — session continuation is via `resumeSessionId`/`forkSession`. Use the `claude_agents_list` tool (`claude agents --json`) to enumerate Claude Code background agent sessions.
|
|
79
79
|
|
|
80
|
+
### Handing off to another engine
|
|
81
|
+
|
|
82
|
+
`resumeSessionId` and `forkSession` continue a conversation on the engine that holds it. To continue
|
|
83
|
+
it somewhere else — a stuck Claude session into Codex, an expensive model into a cheaper one —
|
|
84
|
+
use `handoffSession` (tool: `session_handoff`):
|
|
85
|
+
|
|
86
|
+
```typescript
|
|
87
|
+
await manager.handoffSession('refactor', {
|
|
88
|
+
engine: 'codex',
|
|
89
|
+
message: 'Carry on from where we stopped.', // optional: send now and return the reply
|
|
90
|
+
});
|
|
91
|
+
// → new session 'refactor-codex', same cwd; 'refactor' keeps running untouched
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
**How the conversation travels.** No engine can resume another's session, and each keeps its
|
|
95
|
+
history in its own undocumented on-disk format. So the conversation is replayed as text: a
|
|
96
|
+
`<conversation_history>` block in front of the new session's first message, after which the new
|
|
97
|
+
engine holds it itself. Every turn in it is fenced, so a reply that contains the block's own tags
|
|
98
|
+
cannot close it early and speak as another role. Nothing is written into either engine's session
|
|
99
|
+
store.
|
|
100
|
+
|
|
101
|
+
**What carries across.** What was said: every message sent through `sendMessage` and every reply,
|
|
102
|
+
recorded per session as it happens. The session's own history buffer is not used for this — it is
|
|
103
|
+
capped by event count, and on a long session the opening request is the first thing it loses. The
|
|
104
|
+
new session inherits the source's working directory and its engine-neutral settings (permission and
|
|
105
|
+
sandbox mode, effort, spend cap, system prompts, extra directories). It does not inherit anything
|
|
106
|
+
written for the source engine — its model, tool allowlists in that engine's tool names, resume ids,
|
|
107
|
+
profiles.
|
|
108
|
+
|
|
109
|
+
**What does not.** The source engine's hidden reasoning, which no engine exposes, and the detail of
|
|
110
|
+
tool calls — the new agent sees the replies that described the work, and the workspace itself, which
|
|
111
|
+
the framing tells it to check before relying on anything the history describes.
|
|
112
|
+
|
|
113
|
+
**When it is too long.** Up to `maxChars` (default 240,000 characters, ~60k tokens) the whole
|
|
114
|
+
conversation is sent. Past that, the opening request is kept, the newest turns fill what is left,
|
|
115
|
+
and one line records how many turns in between were left out: the request says what the work is
|
|
116
|
+
for, the newest turns say where it stands, and the middle is what the workspace can answer.
|
|
117
|
+
|
|
118
|
+
**A fork, not a move.** The two sessions go their separate ways. The new one starts from the
|
|
119
|
+
source's record, so handing it off again carries the whole conversation rather than only its own
|
|
120
|
+
part. The history is cleared only after a first send succeeds, so a first turn that fails on the
|
|
121
|
+
new engine does not strand the conversation it was carrying.
|
|
122
|
+
|
|
123
|
+
Verified end to end over MCP against the installed engines: a fact planted in a Claude session was
|
|
124
|
+
recalled by Codex 0.154.0 after a handoff, and again by Claude after a second handoff back, which
|
|
125
|
+
also named Codex as the engine it had taken over from.
|
|
126
|
+
|
|
80
127
|
### ultracode (Claude dynamic workflows)
|
|
81
128
|
|
|
82
129
|
Set `ultracode: true` on a Claude `session_start` to have Claude orchestrate a JS workflow per substantive task and fan out to subagents. It is injected as the `ultracode: true` settings key merged into `--settings` (not a `--effort` value — the CLI rejects `--effort ultracode`):
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
All tools are registered as Claw Orchestrator plugin tools. In standalone mode, they're accessible via the embedded HTTP server.
|
|
4
4
|
|
|
5
|
-
## Session Lifecycle (
|
|
5
|
+
## Session Lifecycle (6)
|
|
6
6
|
|
|
7
7
|
### `session_start`
|
|
8
8
|
|
|
@@ -77,6 +77,26 @@ when there was at least one. Check it even when `error` is absent: a turn whose
|
|
|
77
77
|
denied still ends as a success. See [sessions.md](./sessions.md) on what "succeeded" does and does
|
|
78
78
|
not mean.
|
|
79
79
|
|
|
80
|
+
### `session_handoff`
|
|
81
|
+
|
|
82
|
+
Continue a session's conversation on another engine — or the same engine with another model. Starts
|
|
83
|
+
a new session in the source's working directory and carries the conversation into it; the source
|
|
84
|
+
keeps running untouched.
|
|
85
|
+
|
|
86
|
+
| Parameter | Type | Required | Description |
|
|
87
|
+
| -------------- | ------ | -------- | --------------------------------------------------------------------------- |
|
|
88
|
+
| `name` | string | yes | The session to hand off from |
|
|
89
|
+
| `engine` | string | yes | Engine for the new session |
|
|
90
|
+
| `model` | string | | Model for the new session (default: the engine's default) |
|
|
91
|
+
| `newName` | string | | Name for the new session (default `<name>-<engine>`) |
|
|
92
|
+
| `message` | string | | Send this now and return the reply; otherwise the history waits for `session_send` |
|
|
93
|
+
| `maxChars` | number | | Cap on the carried history, in characters (default 240000, minimum 4000) |
|
|
94
|
+
| `customEngine` | object | | As in `session_start`, when `engine` is `custom` |
|
|
95
|
+
|
|
96
|
+
Returns `{ ok, name, engine, from: { name, engine }, carried: { turns, omitted, chars }, result? }`.
|
|
97
|
+
`result` is the send result of `message`, when one was given. See [sessions.md](./sessions.md) for
|
|
98
|
+
what carries across, what does not, and what is kept when the conversation is too long to send whole.
|
|
99
|
+
|
|
80
100
|
### `session_stop`
|
|
81
101
|
|
|
82
102
|
Graceful shutdown (SIGTERM, then SIGKILL after 3s).
|