Use a goal to keep a continuing task understandable. This guide is for the person responsible for reviewing the result and integrating any delegated work. Complete the local session setup first. Controls were exercised with Sonny 0.12.7 on Linux and a controlled model fixture; that does not certify a live model’s reasoning or an arbitrary worker deployment.
Write an objective you can check
For the fictional support-pilot notes, use this objective:
Prepare a two-sentence comparison of Note A (30 of 40 requests within one day) and Note B (35 of 50). Cite both counts, check 75% and 70%, and say that no satisfaction survey was supplied. Return a reviewed draft; do not contact a service or change source data.
The check is concrete: both counts and rates are present, the five-percentage-point decrease is not mistaken for a cause, and missing satisfaction evidence stays visible. The research and analysis guides supply the source notes and independent arithmetic.
Set and clear a goal deliberately
In the TUI, /goal opens the goal editor. To submit the objective directly, type
/goal followed by the complete text in the composer.
Setting a goal in an idle session starts work on it. It is not merely renaming or bookmarking the task. Review the intended workspace, Recipe/tool policy and provider before submitting. An active turn receives the changed objective rather than starting a second concurrent turn. That behavior is source-tested; the executed local fixture set a goal while idle, observed its persisted value and provider request, then cleared it.
/goal Compare Note A: 30/40 and Note B: 35/50; cite both and flag missing survey.
Check the result against the evidence. A goal label or the model saying “done” is not an acceptance check. Keep uncertain results and failed checks visible.
/goal clear
Clearing removes the standing user goal; it does not retract an external action, erase history or delete artifacts. Cancel an active turn separately when needed. A saved session can restore its goal, so inspect the displayed objective when returning to old work. Do not put credentials or private information in a goal simply to label a task; it can be persisted and sent as model context.
Give a child a narrower contract
Delegation is a separate capability from saving a goal or opening another tab. The pinned runtime’s native worker is Sonny. Older material advertising external agent CLIs as spawnable workers does not establish their availability in this release. Your admitted Recipe, worker definition, host trust, provider account and execution boundary must permit the actual worker launch.
Use this child assignment for a review of the example:
| Contract field | Reviewed assignment |
|---|---|
| Objective | Check the pilot comparison’s arithmetic and citations |
| Inputs | Only Notes A/B and the proposed two-sentence draft |
| Allowed result | A review in the conversation; no edits, publication or service writes |
| Completion evidence | 30/40 = 75%, 35/50 = 70%; source labels resolve; missing survey stated |
| Failure report | Identify the exact unsupported number or claim; retain unresolved items |
| Integration owner | You review the child report and decide whether to revise the parent draft |
A worker’s allowed tools and received context must match this contract. A textual
“read-only” instruction alone does not enforce it. Inspect the resolved Recipe and
current worker/tool surface before launch. Discovery names such as spawn_agent
and get_agent_output are model tools, not shell commands to paste into a terminal.
A product exposing them must apply its own admission and supervision controls.
The parent keeps responsibility for the complete brief. Accept a child report only when the requested evidence is present. If the child returns 72.5% as the combined rate, reject that finding: the weighted result is 65/90, about 72.2%. Revise the narrow assignment to show the formula and ask for the specific missing check; restarting the entire parent task is unnecessary unless its scope changed.
Actual end-to-end worker launch/integration is not certified by the local TUI control fixture. If the current client or deployment cannot admit a worker, stop at the reviewed contract and use its supported task workflow. Do not claim that a worker ran, or bypass isolation/trust to make the example appear successful.
Preserve a worker’s work
A delegated Git worker can own a separate branch/worktree, while a non-Git task can have different execution placement. Inspect the actual reported location and lifecycle; do not infer it from the parent’s visible directory. Child work can include uncommitted edits even when the worker exited or failed.
Before integration, inspect the child’s output, changed files, base/head and verification evidence. Supported integration can preview a patch and bind an apply to its digest. A conflict, changed parent, uncertain ownership or an in-flight worker requires inspection and a fresh preview rather than overwriting the parent. Pinned source tests cover preserved dirty/staged/untracked/ignored content, conflicts and concurrent integration/cleanup; they are not a live deployment claim.
For a first inspection, the following previews cleanup for the current checkout. It requests no worktree removals and is not session deletion:
sonny worktrees prune --dry-run --json
Review the exact paths and keep reasons. Do not remove integration-owned worktrees as generic cache. The real prune is a separate removal operation, and this guide does not ask you to run it on existing work. Preserve evidence and ask the owning workflow to finish or recover uncertain integration first.
Review completion and recover
Keep the parent objective, each child contract, actual results and remaining checks together. A finished process, a stored session, a partial response or a successful schema check does not establish completion of the parent deliverable.
If a response is interrupted, inspect its retained partial text and any actual effects before retrying. If a worker exits without its evidence, keep its worktree and report the missing result; do not relabel it as successful. Narrow a retry to the unresolved check and inspect uncertain writes before repeating them.
Continue with exports and split boundaries . A branch copy, a delegated worker and a live split peer have different ownership and recovery semantics.