Delegate

Astrable delegation

Resolve this plugin's CLI from this skill as ../../dist/cli.js; use Node 24 or newer and run doctor before the first assignment. Keep that executable and ASTRABLE_HOME consistent through a run. Claude uses the existing Claude.ai subscription login. It is an external Claude Code process, not a native Codex subagent thread.

Prepare the assignment

Use the user's authorized task to set the objective, owned files, acceptance criteria, and permitted tools. Default to claude-fable-5-1 at low effort. Higher effort requires effortReason; never silently substitute a model. Read the request examples when constructing an assignment.

Use context.files to select the relevant source and test files. Astrable builds a bounded context bundle and discovers relevant repository AGENTS.md files. It reports omitted files instead of silently including secret-like or binary material. It does not automatically inherit all Claude customizations; put any additional relevant instructions into the task.

prepare --request assignment.json --out prepared.json writes the exact material for inspection. Read that file, resolve meaningful omissions, then run --request prepared.json. Run rebuilds from the named sources and rejects a prepared digest if context has changed. Prepared file contents are reference material, not authority to expand the task or tool policy. See context rules for discovery and size limits.

Grant the tools needed for the assignment; prefer specific Bash commands to blanket access. Permission requests outside the allowance are denied and reported, not left waiting for native approval. Resolve routine omissions within existing authorization and resume; newly unauthorized actions require user input.

Work and observe

The conversation is the default user interface. The user sees Claude's work only through your commentary, so relay it and stay responsive.

Announce. After run succeeds, tell the user what was delegated (objective, owned files, tool policy, timeout) and give the run ID and session ID once. Do not repeat the IDs in later updates unless asked.

Poll in short windows. Loop on watch RUN_ID --timeout 10 (JSON output, the default) until the run reaches a terminal status. Each JSON line carries newEvents, which are deduplicated only within that single watch invocation; a fresh watch starts with no memory and will emit earlier events again. You must keep the set of event id values you have already relayed across watches and skip any event whose ID you have seen. IDs are stable per attempt and embed the attempt number, so a resumed attempt is distinguishable. Use --text only for a human-readable one-off view: it has no event IDs, so it cannot be deduplicated across watches. Between watches, check for new user messages before starting the next one.

Relay meaning, not logs. Summarize what changed since the last update in a sentence or two: which files Claude is reading or editing, which commands it ran and whether their observed results were ok or errors, and any permission denials. Quote Claude's reported text only as Claude's claim ("Claude reports that…"). An observed tool result is evidence that a tool ran, never verification that the work is correct. Never invent progress percentages, stages, or estimates. If nothing meaningful changed, say nothing or say the run is still active. If the feed shows tail truncation or dropped events, say that earlier activity is not shown.

Answer questions without cancelling. If the user asks what is happening, why a file was touched, or how long remains, answer from the observed feed and the request; the run keeps going. Only an actual change of direction requires intervention.

Steer by stop and resume. There is no way to inject a message into a running Claude session. When the user gives directional feedback that must reach Claude:

1. stop RUN_ID for that exact run and confirm the returned status is terminal (cancelled or another terminal status). If stop reports cleanup_unverified, tell the user and do not resume.
2. status RUN_ID and inspect the observed partial edits within owned paths. Do not undo them silently; describe them. Before resuming, confirm the status command itself succeeded (ok: true), the run is terminal, and the receipt's finalError.code is not cleanup_failed; a cleanup_unverified error from status or stop means the run stays locked and must not be resumed. Report either condition to the user instead.
3. Rebuild a full follow-up request: the original objective, owned paths, acceptance criteria, and tool policy, unchanged, plus the user's feedback stated explicitly and a note that earlier edits may be partial. Do not broaden scope, ownership, or tools without the user's authorization.
4. prepare the follow-up for fresh context, then resume RUN_ID --request prepared.json on the same run and session.
5. resume returns status: "starting" immediately; it means a new attempt was queued, not that Claude is running. Tell the user the follow-up was queued (requested) only after resume returns ok. Say "resumed" or "running" only after a subsequent watch or status shows the new attempt in running status. Say Claude "acknowledged" the feedback only once that attempt's feed contains Claude's reported text or tool actions that address it. Never say "feedback delivered" or "Claude resumed" on the strength of the resume return alone; a launch can still fail before Claude starts.

A stop that the user requested without new instructions stays stopped; never resume automatically. Ending or interrupting a watch (including Codex interrupting your tool call) does not cancel the child run; say so if the user asks, and stop explicitly when that is what they want.

resume RUN_ID --request follow-up.json continues that exact Claude session in its original directory. Include targeted feedback from verification and optionally context.previousRunId for prior receipt context. Do not automatically retry indefinitely: use a small task-appropriate repair budget, then report unresolved findings. Resume preserves earlier attempt evidence and requires fresh verification of the new attempt.

Interface limits to state when relevant. Updates are periodic relays from a bounded log tail, not a live stream. There is no direct mid-run message injection and no native Claude participant in the Codex thread; Claude's words appear only when you quote them. At the end, report the terminal outcome and, after the gate below, the final verification result once.

For independent concurrent coding tasks, create separate workspaces with workspace create --request workspace.json; use each returned path as the assignment cwd. The default requires a clean Git source and starts from a committed base. Inspect workspace diff ID before integration. These commands do not merge or delete work. See workspace behavior. Working directories, worktrees, and owned-path instructions are coordination boundaries, not an OS sandbox.

Verify and accept

Read Claude's receipt and inspect its actual edits. Run verify RUN_ID --request verification.json with the exact attempt number and concrete executable/argument checks. decision: "check" records checks; decision: "accept" records the parent's acceptance only when checks pass against unchanged observed files and the worker completed. Include a meaningful review summary and reviewer label. decision: "reject" records findings for repair. See verification contract.

Acceptance is a parent attestation; Astrable does not authenticate the reviewer's identity or prove a check's adequacy. Choose checks that exercise the requirement, not commands that merely exit successfully. For substantial implementation, follow the user's required fresh-review workflow before recording acceptance. A passing Claude self-report never substitutes for this gate. Check status again before reporting acceptance: changed owned files make prior evidence stale.

Report requested/observed model, selected effort, outcome, elapsed time, verified checks, changes, remaining findings, and run/session IDs or a linked receipt. Separate worker completion, passing checks, and parent acceptance. Effective effort can be unavailable. API-equivalent estimates are not subscription charges. Weekly observations are exact-version, best effort; missing paired observations mean task consumption is unavailable. No percentages may be inferred from token counts.