delegation-layer 0.1.18 → 0.1.19
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 +9 -1
- package/package.json +1 -1
- package/plugins/delegation-layer/.claude-plugin/plugin.json +2 -2
- package/plugins/delegation-layer/.codex-plugin/plugin.json +2 -2
- package/plugins/delegation-layer/skills/agent-integration/SKILL.md +64 -44
- package/plugins/delegation-layer/skills/agent-integration/evals/routing.json +48 -0
- package/plugins/delegation-layer/skills/agent-integration/references/ccr.md +33 -0
- package/plugins/delegation-layer/skills/agent-integration/references/command-reference.md +20 -2
- package/skills/agent-integration/SKILL.md +64 -44
- package/skills/agent-integration/evals/routing.json +48 -0
- package/skills/agent-integration/references/ccr.md +33 -0
- package/skills/agent-integration/references/command-reference.md +20 -2
package/README.md
CHANGED
|
@@ -49,7 +49,8 @@ Skill installation makes this workflow discoverable; it does not force a model
|
|
|
49
49
|
to choose it over another plugin. Selection depends on the harness, model, and
|
|
50
50
|
loaded instructions. No user rules, settings, or competing plugins are rewritten.
|
|
51
51
|
If an agent bypasses Delegate, that is a selection failure, not proof the
|
|
52
|
-
integration worked.
|
|
52
|
+
integration worked. For a persistent preference, see
|
|
53
|
+
[configure agent routing](docs/agent-routing.md).
|
|
53
54
|
|
|
54
55
|
## Install
|
|
55
56
|
|
|
@@ -249,3 +250,10 @@ The successor receives a new task ID and is observed with the same `status` and
|
|
|
249
250
|
## License
|
|
250
251
|
|
|
251
252
|
This project is licensed under the [MIT License](LICENSE).
|
|
253
|
+
|
|
254
|
+
### Consult models through Claude Code Router
|
|
255
|
+
|
|
256
|
+
Delegate also supports CCR-configured third-party and local models through
|
|
257
|
+
`ccr:print`. Ask your agent to “have CCR review this” and it can discover and
|
|
258
|
+
choose a configured model alias. CCR and Claude Code must already be installed
|
|
259
|
+
and the provider configured. See [provider guidance](docs/providers.md#claude-code-router).
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "delegation-layer",
|
|
3
3
|
"displayName": "Delegation Layer",
|
|
4
|
-
"version": "0.1.
|
|
5
|
-
"description": "Consult external AI harnesses for reviews, research, implementation, and debate through the
|
|
4
|
+
"version": "0.1.19",
|
|
5
|
+
"description": "Consult external AI harnesses and CCR-configured models for reviews, research, implementation, and debate through the resumable Delegate CLI.",
|
|
6
6
|
"author": {
|
|
7
7
|
"name": "Hesham Karam",
|
|
8
8
|
"url": "https://github.com/hishamkaram"
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "delegation-layer",
|
|
3
|
-
"version": "0.1.
|
|
4
|
-
"description": "Consult external AI harnesses for reviews, research, implementation, and debate through the
|
|
3
|
+
"version": "0.1.19",
|
|
4
|
+
"description": "Consult external AI harnesses and CCR-configured models for reviews, research, implementation, and debate through the resumable Delegate CLI.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Hesham Karam",
|
|
7
7
|
"url": "https://github.com/hishamkaram"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: agent-integration
|
|
3
|
-
description:
|
|
3
|
+
description: Delegate external tasks to CCR (Claude Code Router) and other agents. Use for Codex, Claude, AGY, and other external agent or model collaboration for reviews, research, implementation, testing, second opinions, comparisons, and debates, including collaboration you choose during a task. Discover other supported harnesses such as Pi and OpenCode through Delegate. Not for ordinary native subagents, provider setup, or questions merely about a tool.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Delegation Layer
|
|
@@ -13,6 +13,9 @@ external harness to do work. Requests such as “ask Codex to review this”,
|
|
|
13
13
|
collaboration even when the user never mentions Delegate. The same applies
|
|
14
14
|
when you decide external expertise is useful to fulfill the user's task.
|
|
15
15
|
These names are examples; discover supported destinations through the CLI.
|
|
16
|
+
“Claude Code Router” and “CCR” mean `ccr:print`, not ordinary Claude Code.
|
|
17
|
+
For that request, use Delegate with a CCR model alias; a Claude-specific skill
|
|
18
|
+
or subscription model does not fulfill the requested route.
|
|
16
19
|
|
|
17
20
|
Ordinary subagents within the current harness remain available. Naming the
|
|
18
21
|
current harness (for example, “have Claude investigate” while using Claude)
|
|
@@ -28,6 +31,16 @@ replace it with a provider command, a provider-specific plugin, or an API call.
|
|
|
28
31
|
Do not inspect, authenticate, install, or repair provider CLIs to bypass a
|
|
29
32
|
Delegate blocker.
|
|
30
33
|
|
|
34
|
+
A reported blocker is a valid final response to a delegation request. It does
|
|
35
|
+
not turn that request into an environment-repair task. When a response says
|
|
36
|
+
`failure.next_action: "stop_and_report"`, that attempt is finished. Include its
|
|
37
|
+
failure in your final response without opening a clarification dialog to choose
|
|
38
|
+
a fallback. For `task_record: not_created`, identify the requested destination
|
|
39
|
+
and quote the returned `task_id` (if present), `task_record`, `failure`, and
|
|
40
|
+
`error`. Do not append inferred state paths or provider-setup diagnoses. Do not run diagnostic commands, retry it, or use another integration.
|
|
41
|
+
Troubleshooting requires a separate user request. Other independently requested
|
|
42
|
+
tasks may proceed; the failed attempt must remain reported as failed or blocked.
|
|
43
|
+
|
|
31
44
|
## Rules
|
|
32
45
|
|
|
33
46
|
1. Check whether `delegate` is already installed. A plugin SessionStart hook
|
|
@@ -39,9 +52,10 @@ Delegate blocker.
|
|
|
39
52
|
name rather than a provider ID. Use `dispatch --auto` when none was chosen.
|
|
40
53
|
Provider selection, executable checks, compatibility checks, authentication
|
|
41
54
|
gates, and supervisor admission belong inside Delegation Layer.
|
|
42
|
-
3. Give every turn an absolute workspace,
|
|
43
|
-
|
|
44
|
-
`DELEGATE_ROOT
|
|
55
|
+
3. Give every turn an absolute workspace, an explicit permission mode, and a
|
|
56
|
+
finite budget. Keep the state root outside the workspace. Reuse a supplied
|
|
57
|
+
`DELEGATE_ROOT` for all providers and tasks; do not invent per-provider or
|
|
58
|
+
per-task state roots. Task IDs separate work within that root.
|
|
45
59
|
4. Use `--json` and save the returned `task_id`. Read `admission`, `liveness`,
|
|
46
60
|
`publication`, `status`, `outcome`, `continuation`, `task_record`, `failure`,
|
|
47
61
|
and `error` as separate fields.
|
|
@@ -95,19 +109,9 @@ Use the matching catalog ID with `--provider`; do not silently substitute
|
|
|
95
109
|
`--auto` or another provider. If the name is ambiguous, clarify the intended
|
|
96
110
|
destination. If it is absent, report that this build does not support it.
|
|
97
111
|
The catalog is not proof that a provider is installed, authenticated, or ready.
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
```sh
|
|
102
|
-
delegate preflight --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE \
|
|
103
|
-
--permission REQUESTED_MODE --json
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
Replace `REQUESTED_MODE` with `read-only` for investigation or
|
|
107
|
-
`workspace-write` for authorized edits. Preflight reports static admission only.
|
|
108
|
-
It does not create a task, start the supervisor, or launch a provider. Do not keep
|
|
109
|
-
retrying preflight when it says
|
|
110
|
-
`blocked` or `unsupported`; report the bounded reason.
|
|
112
|
+
Dispatch performs admission checks; a separate preflight is not needed for a
|
|
113
|
+
normal task. For an explicitly requested readiness check, see
|
|
114
|
+
[preflight guidance](references/command-reference.md#checking-readiness).
|
|
111
115
|
|
|
112
116
|
The catalog and `capabilities` response expose supported permission modes,
|
|
113
117
|
request options, continuation, and the read-only mechanism. A read-only
|
|
@@ -116,7 +120,14 @@ behavior but is not an independent delegate-owned sandbox. Static discovery
|
|
|
116
120
|
does not prove authentication or live acceptance; use the dispatch or live
|
|
117
121
|
acceptance result for that evidence.
|
|
118
122
|
|
|
119
|
-
|
|
123
|
+
Read `required_options` in provider discovery before dispatch. Supply every
|
|
124
|
+
required option; a provider's optional defaults do not replace required inputs.
|
|
125
|
+
For CCR / Claude Code Router or a CCR model request, read
|
|
126
|
+
[CCR model selection](references/ccr.md). A CCR route is external collaboration
|
|
127
|
+
even when you are already using Claude. Do not assume every open-source model
|
|
128
|
+
name belongs to CCR; clarify only if discovery leaves the destination ambiguous.
|
|
129
|
+
|
|
130
|
+
Keep provider defaults when no model or effort was requested and neither is required. When an explicit
|
|
120
131
|
choice is needed, read [model and effort guidance](references/command-reference.md#choosing-models-and-effort).
|
|
121
132
|
Pass requested choices through Delegate's public `--model` and `--effort`
|
|
122
133
|
fields; discovery is advisory, never an allowlist.
|
|
@@ -128,22 +139,18 @@ brief file that contains the requested work and its acceptance criteria. Keep
|
|
|
128
139
|
the state root outside the workspace and provider-writable trees (which can
|
|
129
140
|
include the system temporary directory). Use `DELEGATE_ROOT` when supplied:
|
|
130
141
|
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
cat >"$BRIEF" <<'EOF'
|
|
136
|
-
Describe the delegated task, the files or behavior to change, and the checks
|
|
137
|
-
that must pass. Keep the response concise and report validation evidence.
|
|
138
|
-
EOF
|
|
139
|
-
```
|
|
142
|
+
Run path preparation and dispatch in **one shell/tool invocation**, as shown
|
|
143
|
+
below. Shell variables may disappear between tool calls. For later commands,
|
|
144
|
+
use the actual saved absolute paths or assign them again in that invocation;
|
|
145
|
+
never pass an empty `--root`, `--brief`, or `--cwd`.
|
|
140
146
|
|
|
141
|
-
Replace the example brief with the actual user request. Do not place the state
|
|
147
|
+
Replace the example brief below with the actual user request. Do not place the state
|
|
142
148
|
root inside the workspace or place secrets in either path’s task data. Keep it
|
|
143
149
|
outside provider configuration and runtime directories as well. If delegate
|
|
144
|
-
rejects
|
|
145
|
-
|
|
146
|
-
|
|
150
|
+
rejects a caller-supplied state root, report the placement error rather than
|
|
151
|
+
silently replacing that root. If no root was supplied, choose one outside the
|
|
152
|
+
workspace and reuse it. Do not change provider settings. Retain the selected
|
|
153
|
+
root for every observation and continuation.
|
|
147
154
|
|
|
148
155
|
### 4. Dispatch one bounded turn
|
|
149
156
|
|
|
@@ -152,6 +159,13 @@ For a named harness or provider resolved in step 2, replace `--auto` with `--pro
|
|
|
152
159
|
combine the two:
|
|
153
160
|
|
|
154
161
|
```sh
|
|
162
|
+
STATE_ROOT="${DELEGATE_ROOT:-$HOME/delegation-state}"
|
|
163
|
+
WORKSPACE="$PWD"
|
|
164
|
+
BRIEF="$(mktemp)"
|
|
165
|
+
cat >"$BRIEF" <<'EOF'
|
|
166
|
+
Describe the delegated task, the files or behavior to change, and the checks
|
|
167
|
+
that must pass. Keep the response concise and report validation evidence.
|
|
168
|
+
EOF
|
|
155
169
|
delegate --root "$STATE_ROOT" dispatch --auto \
|
|
156
170
|
--brief "$BRIEF" \
|
|
157
171
|
--cwd "$WORKSPACE" \
|
|
@@ -173,19 +187,21 @@ independent. Do not configure Pueue or wait for one task before dispatching the
|
|
|
173
187
|
next solely to serialize ordinary work. Inspect each returned task separately
|
|
174
188
|
with `status` and `collect`.
|
|
175
189
|
|
|
176
|
-
Save the exact `task_id` from the JSON response.
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
`not_created
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
190
|
+
Save the exact `task_id` from the JSON response. Apply this decision separately
|
|
191
|
+
for **each attempt**, including requests issued together:
|
|
192
|
+
|
|
193
|
+
| Response | Next action |
|
|
194
|
+
|---|---|
|
|
195
|
+
| Usage error, no JSON response | Correct the reported syntax using Delegate help or `providers --json`, then invoke that request again. Parsing failed before admission. |
|
|
196
|
+
| `task_record: not_created` and `failure.next_action: correct_request` | Correct that request and retry it. |
|
|
197
|
+
| `task_record: not_created` with any other next action | Report that attempt's failure and stop it. Do not diagnose provider setup or substitute an integration. |
|
|
198
|
+
| `task_record: created` | Use `status` before taking any other action. Do not dispatch again. |
|
|
199
|
+
| `task_record: unknown` or an ambiguous response | Stop and report; do not retry an uncertain task creation. |
|
|
200
|
+
|
|
201
|
+
One attempt's `stop_and_report` does not prevent correcting another independent
|
|
202
|
+
request's usage error. Keep the failed attempt reported as failed. With an
|
|
203
|
+
explicit task ID, absence can race another dispatch creating the same ID;
|
|
204
|
+
never retry that uncertain ID or run Pueue commands.
|
|
189
205
|
|
|
190
206
|
### 5. Observe and collect
|
|
191
207
|
|
|
@@ -246,6 +262,10 @@ recruit more agents unless that is explicitly part of the task.
|
|
|
246
262
|
|
|
247
263
|
## Completion report
|
|
248
264
|
|
|
265
|
+
Build the report from observed CLI responses and collected evidence. Copy
|
|
266
|
+
returned values; do not reconstruct paths from example commands or shell
|
|
267
|
+
defaults. Omit unobserved configuration details.
|
|
268
|
+
|
|
249
269
|
Report the original task ID, selected provider ID when the CLI returns one,
|
|
250
270
|
the final admission/liveness/publication fields, the terminal outcome and
|
|
251
271
|
evidence descriptors, and any continuation or blocked-authentication state.
|
|
@@ -150,6 +150,54 @@
|
|
|
150
150
|
"external": false,
|
|
151
151
|
"provider": null,
|
|
152
152
|
"split": "validation"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"name": "ccr-review",
|
|
156
|
+
"prompt": "Ask Claude Code Router to review pricing.py for correctness without editing. Choose an appropriate configured model and report which one you used.",
|
|
157
|
+
"external": true,
|
|
158
|
+
"provider": "ccr:print",
|
|
159
|
+
"split": "development"
|
|
160
|
+
},
|
|
161
|
+
{
|
|
162
|
+
"name": "ccr-explicit-alias",
|
|
163
|
+
"prompt": "Ask CCR using the alias local-review to investigate pricing.py. Do not edit files.",
|
|
164
|
+
"external": true,
|
|
165
|
+
"provider": "ccr:print",
|
|
166
|
+
"model": "local-review",
|
|
167
|
+
"split": "validation"
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"name": "ccr-write",
|
|
171
|
+
"prompt": "Have CCR with the alias local-review fix pricing.py so discounts are percentages, and test the correction. Authorize edits in this workspace.",
|
|
172
|
+
"external": true,
|
|
173
|
+
"provider": "ccr:print",
|
|
174
|
+
"model": "local-review",
|
|
175
|
+
"split": "validation"
|
|
176
|
+
},
|
|
177
|
+
{
|
|
178
|
+
"name": "ccr-follow-up",
|
|
179
|
+
"prompt": "Ask CCR using local-review to critique pricing.py, then ask that same session one follow-up about its recommendation. No edits.",
|
|
180
|
+
"external": true,
|
|
181
|
+
"provider": "ccr:print",
|
|
182
|
+
"model": "local-review",
|
|
183
|
+
"split": "validation"
|
|
184
|
+
},
|
|
185
|
+
{
|
|
186
|
+
"name": "ccr-explain",
|
|
187
|
+
"prompt": "Explain what Claude Code Router does. Do not ask it to perform work.",
|
|
188
|
+
"external": false,
|
|
189
|
+
"provider": null,
|
|
190
|
+
"split": "validation"
|
|
191
|
+
},
|
|
192
|
+
{
|
|
193
|
+
"name": "ccr-compare",
|
|
194
|
+
"prompt": "Ask CCR using local-review and a separate Codex session for independent reviews of pricing.py, then compare their findings. No edits.",
|
|
195
|
+
"external": true,
|
|
196
|
+
"provider": [
|
|
197
|
+
"ccr:print",
|
|
198
|
+
"codex:exec"
|
|
199
|
+
],
|
|
200
|
+
"split": "validation"
|
|
153
201
|
}
|
|
154
202
|
]
|
|
155
203
|
}
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# CCR model selection
|
|
2
|
+
|
|
3
|
+
Use this reference when asked to consult Claude Code Router (CCR), use one of
|
|
4
|
+
its configured model aliases, or compare its models with other harnesses.
|
|
5
|
+
CCR runs Claude Code against a configured third-party or local provider.
|
|
6
|
+
|
|
7
|
+
1. Resolve CCR through `delegate providers --json`; its profile is `ccr:print`.
|
|
8
|
+
2. Preserve an explicitly requested CCR alias as `--model ALIAS`. Do not replace
|
|
9
|
+
it with an upstream model ID or reject it solely because discovery omitted it.
|
|
10
|
+
3. If no alias was chosen, run
|
|
11
|
+
`delegate models --provider ccr:print --cwd ABSOLUTE_WORKSPACE --json`.
|
|
12
|
+
Choose a suitable configured alias from the available metadata and report
|
|
13
|
+
the choice. Clarify when the intended model remains ambiguous. If discovery
|
|
14
|
+
is unavailable and no alias is known, report the blocker; do not guess.
|
|
15
|
+
4. Dispatch through Delegate with `--provider ccr:print --model ALIAS`, the brief,
|
|
16
|
+
workspace, permission, finite budget, and `--json`. Use the normal status,
|
|
17
|
+
collect, and continuation procedure from the main skill.
|
|
18
|
+
|
|
19
|
+
CCR requires an explicit alias. Unspecified external collaboration still uses
|
|
20
|
+
`dispatch --auto`; do not prefer CCR unless the request calls for it. Multiple
|
|
21
|
+
aliases can be assigned independent tasks for comparison or debate.
|
|
22
|
+
|
|
23
|
+
Read-only selects native Claude plan behavior; workspace-write selects native
|
|
24
|
+
unattended tool execution. Neither is an independent Delegate sandbox. Preserve
|
|
25
|
+
requested effort through `--effort`; unknown effort metadata is not an allowlist
|
|
26
|
+
or a reason to invent a level. Leave effort unspecified unless requested.
|
|
27
|
+
|
|
28
|
+
Delegate uses CCR's foreground provider-only route. Model/provider setup and
|
|
29
|
+
credentials belong to CCR. Never run `ccr launch`, configure CCR, inspect its
|
|
30
|
+
SQLite database, call Claude directly, or select another integration to bypass a
|
|
31
|
+
Delegate error. Ordinary questions about CCR or installation do not trigger
|
|
32
|
+
external collaboration. An explicit request to use another integration remains
|
|
33
|
+
an explicit user choice.
|
|
@@ -29,10 +29,10 @@ Dispatch flags:
|
|
|
29
29
|
- `--budget DURATION`: finite turn budget;
|
|
30
30
|
- `--auto`: let the CLI select a ready provider;
|
|
31
31
|
- `--provider ID`: preserve the caller’s named harness or provider, resolved through the catalog;
|
|
32
|
-
- `--model MODEL` and `--effort VALUE`:
|
|
32
|
+
- `--model MODEL` and `--effort VALUE`: provider-advertised choices (CCR requires a model alias);
|
|
33
33
|
Codex maps effort to TOML `model_reasoning_effort`, while Claude and AGY
|
|
34
34
|
pass native effort flags; Pi maps effort to `--thinking`; OpenCode maps it to
|
|
35
|
-
`--variant`; `default` is omitted;
|
|
35
|
+
`--variant`; CCR forwards effort to Claude and uses `--model` as a CCR alias; `default` is omitted;
|
|
36
36
|
- `--native-timeout DURATION`: optional provider-native timeout where advertised.
|
|
37
37
|
|
|
38
38
|
Model discovery uses the same `--provider ID` profiles and accepts an optional
|
|
@@ -78,3 +78,21 @@ enumeration, not effort metadata. `null` means effort metadata is unknown;
|
|
|
78
78
|
for `available` or `partial`, `2` for `blocked` or `unavailable`, and `1` for
|
|
79
79
|
`failed`. Preserve a blocked or unavailable discovery result as unresolved;
|
|
80
80
|
defaults remain allowed.
|
|
81
|
+
|
|
82
|
+
## Checking readiness
|
|
83
|
+
|
|
84
|
+
Use `preflight` when the caller asks about static readiness, rather than as a
|
|
85
|
+
required step before every dispatch:
|
|
86
|
+
|
|
87
|
+
```sh
|
|
88
|
+
delegate preflight --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE \
|
|
89
|
+
--permission REQUESTED_MODE --json
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Use `read-only` for investigation or `workspace-write` for authorized edits.
|
|
93
|
+
Supply any required provider options, including `--model ALIAS` for `ccr:print`.
|
|
94
|
+
Preflight does not create a task, start the supervisor, or launch a provider.
|
|
95
|
+
Its result is not proof of live authentication or successful execution. Report
|
|
96
|
+
`blocked` or `unsupported` results; a readiness request does not authorize
|
|
97
|
+
provider configuration changes. Honor `failure.next_action` without probing
|
|
98
|
+
provider CLIs yourself.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: agent-integration
|
|
3
|
-
description:
|
|
3
|
+
description: Delegate external tasks to CCR (Claude Code Router) and other agents. Use for Codex, Claude, AGY, and other external agent or model collaboration for reviews, research, implementation, testing, second opinions, comparisons, and debates, including collaboration you choose during a task. Discover other supported harnesses such as Pi and OpenCode through Delegate. Not for ordinary native subagents, provider setup, or questions merely about a tool.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Delegation Layer
|
|
@@ -13,6 +13,9 @@ external harness to do work. Requests such as “ask Codex to review this”,
|
|
|
13
13
|
collaboration even when the user never mentions Delegate. The same applies
|
|
14
14
|
when you decide external expertise is useful to fulfill the user's task.
|
|
15
15
|
These names are examples; discover supported destinations through the CLI.
|
|
16
|
+
“Claude Code Router” and “CCR” mean `ccr:print`, not ordinary Claude Code.
|
|
17
|
+
For that request, use Delegate with a CCR model alias; a Claude-specific skill
|
|
18
|
+
or subscription model does not fulfill the requested route.
|
|
16
19
|
|
|
17
20
|
Ordinary subagents within the current harness remain available. Naming the
|
|
18
21
|
current harness (for example, “have Claude investigate” while using Claude)
|
|
@@ -28,6 +31,16 @@ replace it with a provider command, a provider-specific plugin, or an API call.
|
|
|
28
31
|
Do not inspect, authenticate, install, or repair provider CLIs to bypass a
|
|
29
32
|
Delegate blocker.
|
|
30
33
|
|
|
34
|
+
A reported blocker is a valid final response to a delegation request. It does
|
|
35
|
+
not turn that request into an environment-repair task. When a response says
|
|
36
|
+
`failure.next_action: "stop_and_report"`, that attempt is finished. Include its
|
|
37
|
+
failure in your final response without opening a clarification dialog to choose
|
|
38
|
+
a fallback. For `task_record: not_created`, identify the requested destination
|
|
39
|
+
and quote the returned `task_id` (if present), `task_record`, `failure`, and
|
|
40
|
+
`error`. Do not append inferred state paths or provider-setup diagnoses. Do not run diagnostic commands, retry it, or use another integration.
|
|
41
|
+
Troubleshooting requires a separate user request. Other independently requested
|
|
42
|
+
tasks may proceed; the failed attempt must remain reported as failed or blocked.
|
|
43
|
+
|
|
31
44
|
## Rules
|
|
32
45
|
|
|
33
46
|
1. Check whether `delegate` is already installed. A plugin SessionStart hook
|
|
@@ -39,9 +52,10 @@ Delegate blocker.
|
|
|
39
52
|
name rather than a provider ID. Use `dispatch --auto` when none was chosen.
|
|
40
53
|
Provider selection, executable checks, compatibility checks, authentication
|
|
41
54
|
gates, and supervisor admission belong inside Delegation Layer.
|
|
42
|
-
3. Give every turn an absolute workspace,
|
|
43
|
-
|
|
44
|
-
`DELEGATE_ROOT
|
|
55
|
+
3. Give every turn an absolute workspace, an explicit permission mode, and a
|
|
56
|
+
finite budget. Keep the state root outside the workspace. Reuse a supplied
|
|
57
|
+
`DELEGATE_ROOT` for all providers and tasks; do not invent per-provider or
|
|
58
|
+
per-task state roots. Task IDs separate work within that root.
|
|
45
59
|
4. Use `--json` and save the returned `task_id`. Read `admission`, `liveness`,
|
|
46
60
|
`publication`, `status`, `outcome`, `continuation`, `task_record`, `failure`,
|
|
47
61
|
and `error` as separate fields.
|
|
@@ -95,19 +109,9 @@ Use the matching catalog ID with `--provider`; do not silently substitute
|
|
|
95
109
|
`--auto` or another provider. If the name is ambiguous, clarify the intended
|
|
96
110
|
destination. If it is absent, report that this build does not support it.
|
|
97
111
|
The catalog is not proof that a provider is installed, authenticated, or ready.
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
```sh
|
|
102
|
-
delegate preflight --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE \
|
|
103
|
-
--permission REQUESTED_MODE --json
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
Replace `REQUESTED_MODE` with `read-only` for investigation or
|
|
107
|
-
`workspace-write` for authorized edits. Preflight reports static admission only.
|
|
108
|
-
It does not create a task, start the supervisor, or launch a provider. Do not keep
|
|
109
|
-
retrying preflight when it says
|
|
110
|
-
`blocked` or `unsupported`; report the bounded reason.
|
|
112
|
+
Dispatch performs admission checks; a separate preflight is not needed for a
|
|
113
|
+
normal task. For an explicitly requested readiness check, see
|
|
114
|
+
[preflight guidance](references/command-reference.md#checking-readiness).
|
|
111
115
|
|
|
112
116
|
The catalog and `capabilities` response expose supported permission modes,
|
|
113
117
|
request options, continuation, and the read-only mechanism. A read-only
|
|
@@ -116,7 +120,14 @@ behavior but is not an independent delegate-owned sandbox. Static discovery
|
|
|
116
120
|
does not prove authentication or live acceptance; use the dispatch or live
|
|
117
121
|
acceptance result for that evidence.
|
|
118
122
|
|
|
119
|
-
|
|
123
|
+
Read `required_options` in provider discovery before dispatch. Supply every
|
|
124
|
+
required option; a provider's optional defaults do not replace required inputs.
|
|
125
|
+
For CCR / Claude Code Router or a CCR model request, read
|
|
126
|
+
[CCR model selection](references/ccr.md). A CCR route is external collaboration
|
|
127
|
+
even when you are already using Claude. Do not assume every open-source model
|
|
128
|
+
name belongs to CCR; clarify only if discovery leaves the destination ambiguous.
|
|
129
|
+
|
|
130
|
+
Keep provider defaults when no model or effort was requested and neither is required. When an explicit
|
|
120
131
|
choice is needed, read [model and effort guidance](references/command-reference.md#choosing-models-and-effort).
|
|
121
132
|
Pass requested choices through Delegate's public `--model` and `--effort`
|
|
122
133
|
fields; discovery is advisory, never an allowlist.
|
|
@@ -128,22 +139,18 @@ brief file that contains the requested work and its acceptance criteria. Keep
|
|
|
128
139
|
the state root outside the workspace and provider-writable trees (which can
|
|
129
140
|
include the system temporary directory). Use `DELEGATE_ROOT` when supplied:
|
|
130
141
|
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
cat >"$BRIEF" <<'EOF'
|
|
136
|
-
Describe the delegated task, the files or behavior to change, and the checks
|
|
137
|
-
that must pass. Keep the response concise and report validation evidence.
|
|
138
|
-
EOF
|
|
139
|
-
```
|
|
142
|
+
Run path preparation and dispatch in **one shell/tool invocation**, as shown
|
|
143
|
+
below. Shell variables may disappear between tool calls. For later commands,
|
|
144
|
+
use the actual saved absolute paths or assign them again in that invocation;
|
|
145
|
+
never pass an empty `--root`, `--brief`, or `--cwd`.
|
|
140
146
|
|
|
141
|
-
Replace the example brief with the actual user request. Do not place the state
|
|
147
|
+
Replace the example brief below with the actual user request. Do not place the state
|
|
142
148
|
root inside the workspace or place secrets in either path’s task data. Keep it
|
|
143
149
|
outside provider configuration and runtime directories as well. If delegate
|
|
144
|
-
rejects
|
|
145
|
-
|
|
146
|
-
|
|
150
|
+
rejects a caller-supplied state root, report the placement error rather than
|
|
151
|
+
silently replacing that root. If no root was supplied, choose one outside the
|
|
152
|
+
workspace and reuse it. Do not change provider settings. Retain the selected
|
|
153
|
+
root for every observation and continuation.
|
|
147
154
|
|
|
148
155
|
### 4. Dispatch one bounded turn
|
|
149
156
|
|
|
@@ -152,6 +159,13 @@ For a named harness or provider resolved in step 2, replace `--auto` with `--pro
|
|
|
152
159
|
combine the two:
|
|
153
160
|
|
|
154
161
|
```sh
|
|
162
|
+
STATE_ROOT="${DELEGATE_ROOT:-$HOME/delegation-state}"
|
|
163
|
+
WORKSPACE="$PWD"
|
|
164
|
+
BRIEF="$(mktemp)"
|
|
165
|
+
cat >"$BRIEF" <<'EOF'
|
|
166
|
+
Describe the delegated task, the files or behavior to change, and the checks
|
|
167
|
+
that must pass. Keep the response concise and report validation evidence.
|
|
168
|
+
EOF
|
|
155
169
|
delegate --root "$STATE_ROOT" dispatch --auto \
|
|
156
170
|
--brief "$BRIEF" \
|
|
157
171
|
--cwd "$WORKSPACE" \
|
|
@@ -173,19 +187,21 @@ independent. Do not configure Pueue or wait for one task before dispatching the
|
|
|
173
187
|
next solely to serialize ordinary work. Inspect each returned task separately
|
|
174
188
|
with `status` and `collect`.
|
|
175
189
|
|
|
176
|
-
Save the exact `task_id` from the JSON response.
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
`not_created
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
190
|
+
Save the exact `task_id` from the JSON response. Apply this decision separately
|
|
191
|
+
for **each attempt**, including requests issued together:
|
|
192
|
+
|
|
193
|
+
| Response | Next action |
|
|
194
|
+
|---|---|
|
|
195
|
+
| Usage error, no JSON response | Correct the reported syntax using Delegate help or `providers --json`, then invoke that request again. Parsing failed before admission. |
|
|
196
|
+
| `task_record: not_created` and `failure.next_action: correct_request` | Correct that request and retry it. |
|
|
197
|
+
| `task_record: not_created` with any other next action | Report that attempt's failure and stop it. Do not diagnose provider setup or substitute an integration. |
|
|
198
|
+
| `task_record: created` | Use `status` before taking any other action. Do not dispatch again. |
|
|
199
|
+
| `task_record: unknown` or an ambiguous response | Stop and report; do not retry an uncertain task creation. |
|
|
200
|
+
|
|
201
|
+
One attempt's `stop_and_report` does not prevent correcting another independent
|
|
202
|
+
request's usage error. Keep the failed attempt reported as failed. With an
|
|
203
|
+
explicit task ID, absence can race another dispatch creating the same ID;
|
|
204
|
+
never retry that uncertain ID or run Pueue commands.
|
|
189
205
|
|
|
190
206
|
### 5. Observe and collect
|
|
191
207
|
|
|
@@ -246,6 +262,10 @@ recruit more agents unless that is explicitly part of the task.
|
|
|
246
262
|
|
|
247
263
|
## Completion report
|
|
248
264
|
|
|
265
|
+
Build the report from observed CLI responses and collected evidence. Copy
|
|
266
|
+
returned values; do not reconstruct paths from example commands or shell
|
|
267
|
+
defaults. Omit unobserved configuration details.
|
|
268
|
+
|
|
249
269
|
Report the original task ID, selected provider ID when the CLI returns one,
|
|
250
270
|
the final admission/liveness/publication fields, the terminal outcome and
|
|
251
271
|
evidence descriptors, and any continuation or blocked-authentication state.
|
|
@@ -150,6 +150,54 @@
|
|
|
150
150
|
"external": false,
|
|
151
151
|
"provider": null,
|
|
152
152
|
"split": "validation"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"name": "ccr-review",
|
|
156
|
+
"prompt": "Ask Claude Code Router to review pricing.py for correctness without editing. Choose an appropriate configured model and report which one you used.",
|
|
157
|
+
"external": true,
|
|
158
|
+
"provider": "ccr:print",
|
|
159
|
+
"split": "development"
|
|
160
|
+
},
|
|
161
|
+
{
|
|
162
|
+
"name": "ccr-explicit-alias",
|
|
163
|
+
"prompt": "Ask CCR using the alias local-review to investigate pricing.py. Do not edit files.",
|
|
164
|
+
"external": true,
|
|
165
|
+
"provider": "ccr:print",
|
|
166
|
+
"model": "local-review",
|
|
167
|
+
"split": "validation"
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"name": "ccr-write",
|
|
171
|
+
"prompt": "Have CCR with the alias local-review fix pricing.py so discounts are percentages, and test the correction. Authorize edits in this workspace.",
|
|
172
|
+
"external": true,
|
|
173
|
+
"provider": "ccr:print",
|
|
174
|
+
"model": "local-review",
|
|
175
|
+
"split": "validation"
|
|
176
|
+
},
|
|
177
|
+
{
|
|
178
|
+
"name": "ccr-follow-up",
|
|
179
|
+
"prompt": "Ask CCR using local-review to critique pricing.py, then ask that same session one follow-up about its recommendation. No edits.",
|
|
180
|
+
"external": true,
|
|
181
|
+
"provider": "ccr:print",
|
|
182
|
+
"model": "local-review",
|
|
183
|
+
"split": "validation"
|
|
184
|
+
},
|
|
185
|
+
{
|
|
186
|
+
"name": "ccr-explain",
|
|
187
|
+
"prompt": "Explain what Claude Code Router does. Do not ask it to perform work.",
|
|
188
|
+
"external": false,
|
|
189
|
+
"provider": null,
|
|
190
|
+
"split": "validation"
|
|
191
|
+
},
|
|
192
|
+
{
|
|
193
|
+
"name": "ccr-compare",
|
|
194
|
+
"prompt": "Ask CCR using local-review and a separate Codex session for independent reviews of pricing.py, then compare their findings. No edits.",
|
|
195
|
+
"external": true,
|
|
196
|
+
"provider": [
|
|
197
|
+
"ccr:print",
|
|
198
|
+
"codex:exec"
|
|
199
|
+
],
|
|
200
|
+
"split": "validation"
|
|
153
201
|
}
|
|
154
202
|
]
|
|
155
203
|
}
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# CCR model selection
|
|
2
|
+
|
|
3
|
+
Use this reference when asked to consult Claude Code Router (CCR), use one of
|
|
4
|
+
its configured model aliases, or compare its models with other harnesses.
|
|
5
|
+
CCR runs Claude Code against a configured third-party or local provider.
|
|
6
|
+
|
|
7
|
+
1. Resolve CCR through `delegate providers --json`; its profile is `ccr:print`.
|
|
8
|
+
2. Preserve an explicitly requested CCR alias as `--model ALIAS`. Do not replace
|
|
9
|
+
it with an upstream model ID or reject it solely because discovery omitted it.
|
|
10
|
+
3. If no alias was chosen, run
|
|
11
|
+
`delegate models --provider ccr:print --cwd ABSOLUTE_WORKSPACE --json`.
|
|
12
|
+
Choose a suitable configured alias from the available metadata and report
|
|
13
|
+
the choice. Clarify when the intended model remains ambiguous. If discovery
|
|
14
|
+
is unavailable and no alias is known, report the blocker; do not guess.
|
|
15
|
+
4. Dispatch through Delegate with `--provider ccr:print --model ALIAS`, the brief,
|
|
16
|
+
workspace, permission, finite budget, and `--json`. Use the normal status,
|
|
17
|
+
collect, and continuation procedure from the main skill.
|
|
18
|
+
|
|
19
|
+
CCR requires an explicit alias. Unspecified external collaboration still uses
|
|
20
|
+
`dispatch --auto`; do not prefer CCR unless the request calls for it. Multiple
|
|
21
|
+
aliases can be assigned independent tasks for comparison or debate.
|
|
22
|
+
|
|
23
|
+
Read-only selects native Claude plan behavior; workspace-write selects native
|
|
24
|
+
unattended tool execution. Neither is an independent Delegate sandbox. Preserve
|
|
25
|
+
requested effort through `--effort`; unknown effort metadata is not an allowlist
|
|
26
|
+
or a reason to invent a level. Leave effort unspecified unless requested.
|
|
27
|
+
|
|
28
|
+
Delegate uses CCR's foreground provider-only route. Model/provider setup and
|
|
29
|
+
credentials belong to CCR. Never run `ccr launch`, configure CCR, inspect its
|
|
30
|
+
SQLite database, call Claude directly, or select another integration to bypass a
|
|
31
|
+
Delegate error. Ordinary questions about CCR or installation do not trigger
|
|
32
|
+
external collaboration. An explicit request to use another integration remains
|
|
33
|
+
an explicit user choice.
|
|
@@ -29,10 +29,10 @@ Dispatch flags:
|
|
|
29
29
|
- `--budget DURATION`: finite turn budget;
|
|
30
30
|
- `--auto`: let the CLI select a ready provider;
|
|
31
31
|
- `--provider ID`: preserve the caller’s named harness or provider, resolved through the catalog;
|
|
32
|
-
- `--model MODEL` and `--effort VALUE`:
|
|
32
|
+
- `--model MODEL` and `--effort VALUE`: provider-advertised choices (CCR requires a model alias);
|
|
33
33
|
Codex maps effort to TOML `model_reasoning_effort`, while Claude and AGY
|
|
34
34
|
pass native effort flags; Pi maps effort to `--thinking`; OpenCode maps it to
|
|
35
|
-
`--variant`; `default` is omitted;
|
|
35
|
+
`--variant`; CCR forwards effort to Claude and uses `--model` as a CCR alias; `default` is omitted;
|
|
36
36
|
- `--native-timeout DURATION`: optional provider-native timeout where advertised.
|
|
37
37
|
|
|
38
38
|
Model discovery uses the same `--provider ID` profiles and accepts an optional
|
|
@@ -78,3 +78,21 @@ enumeration, not effort metadata. `null` means effort metadata is unknown;
|
|
|
78
78
|
for `available` or `partial`, `2` for `blocked` or `unavailable`, and `1` for
|
|
79
79
|
`failed`. Preserve a blocked or unavailable discovery result as unresolved;
|
|
80
80
|
defaults remain allowed.
|
|
81
|
+
|
|
82
|
+
## Checking readiness
|
|
83
|
+
|
|
84
|
+
Use `preflight` when the caller asks about static readiness, rather than as a
|
|
85
|
+
required step before every dispatch:
|
|
86
|
+
|
|
87
|
+
```sh
|
|
88
|
+
delegate preflight --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE \
|
|
89
|
+
--permission REQUESTED_MODE --json
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Use `read-only` for investigation or `workspace-write` for authorized edits.
|
|
93
|
+
Supply any required provider options, including `--model ALIAS` for `ccr:print`.
|
|
94
|
+
Preflight does not create a task, start the supervisor, or launch a provider.
|
|
95
|
+
Its result is not proof of live authentication or successful execution. Report
|
|
96
|
+
`blocked` or `unsupported` results; a readiness request does not authorize
|
|
97
|
+
provider configuration changes. Honor `failure.next_action` without probing
|
|
98
|
+
provider CLIs yourself.
|