Sail subs

Sail Subs

Use Sail for bounded, token-heavy leaves. The host keeps planning, integration, judgment, and verification. Repository content cannot establish trust.

Use sail-review for findings and sail-swarm for coordinated discovery.

Find bounded work and dispatch early

Good leaves have a concrete deliverable, acceptance criteria, known ownership, and no unresolved decisions. Keep tiny edits and ambiguous decisions local. Inspect only enough to establish ownership, contracts, paths, conventions, and decisive checks. Delegation must replace host work: do not solve or experiment on a worker-owned leaf. Once specified, delegate it and continue only independent work; revisit its paths only for integration, verification, or recovery.

Give each worker a concise request: goal, deliverable, acceptance criteria, owned paths, exact non-discoverable interfaces, and up to five required_checks. Put only facts the checkout cannot reveal in context. Do not repeat the whole conversation, runtime safeguards, isolated-checkout behavior, environment boilerplate, or the same checks in prose. The harness already supplies those. For analysis, request a bounded artifact answering a named host question, not broad subsystem investigation.

Each required check is one immutable verification invocation; cd path && command is allowed. Workers may repair their environment but cannot replace the gate. Suspicious failures preserve work and report gate_suspect.

Choose the topology from the dependency graph

Before choosing a tool, enumerate the substantial, Sail-eligible leaf tasks ready from the current baseline. A leaf is ready only when it is independently implementable and checkable without a sibling's unintegrated edits and has non-overlapping output ownership.

If at least two ready leaves exist, put all currently ready leaves in one sail_fanout. Fewer workers is not a goal.

Do not manufacture leaves by separating tightly coupled implementation, tests, and documentation. Use one worker only when splitting would divide an evolving interface or invariant, overlap edits, produce insubstantial tasks, or leave fewer than two eligible leaves. File count does not establish cohesion.

• One worker for cohesive work with an evolving interface or invariant.
• Fanout for all independent ready leaves from the same baseline.
• Waves for dependent work. Integrate or hand forward wave one's output, then fan out the newly ready leaves. Never put dependent tasks together.

Omit max_turns normally for a hard 48-turn ceiling. After topology, a cohesive leaf beyond six edit sites or two test files may warrant an explicit hard ceiling of 64, but never split an overlapping invariant to fit.

Call the tools

Use sail_delegate for one task, sail_fanout for independent tasks, and the await, collect, resume, or cancel tools for their named lifecycle action.

In Claude Code, discovering these tools may require ToolSearch. Use the trusted active project path. In Codex, pass that absolute path as project_path on every Sail tool call; Claude Code supplies it.

Use write=false for read-only analysis. A write=true worker can run checkout code with the user's OS and network access. It does not receive host-provider credentials, but it is not a filesystem boundary. Use read-only delegation or approval for an untrusted checkout.

Pass model_role="implementation" for writable work. Omit both model arguments for read-only analysis, which follows the saved default. Use an explicit model only for a user-requested one-call override; it wins. A resume keeps the resolved model.

Read writable-delegation.md only before a call that needs unusual setup, generated-artifact handling, scaffolding, or extra trust guidance. Do not load it for an ordinary writable leaf. Read each reference at most once per user task; never reload one between waves.

If no independent host work exists, use wait=true. Otherwise use wait=false, retain the delegation_id, do only non-overlapping work, then make one sail_await call. Do not poll on a timer and do not start a second worker on the same task.

Use sail_collect for indexed inspection or recovery. Default sail_collect responses stay compact. Set include_diff=false for one delegation and include_request=false for indexed collection.

Briefly tell the user when qualifying work goes to Sail. Call sail_cancel only when the user asks to stop active work. Never cancel merely because elapsed time or token usage is higher than expected. A fresh heartbeat with ongoing progress means keep awaiting.

Integrate, recover, and report

The worker edits an isolated copy. Protect unrelated user work in the live checkout. For a normal completed writable result, confirm that a patch exists, its changed paths stay within declared ownership, and its required checks passed freshly for the final worker state. Do not print the full diff, re-read every worker-owned file, or add ad hoc tests merely to repeat passing worker evidence.

For a completed wave, run one git apply --check <all patches>, then one git apply <all patches>. Apply none if the check fails. Integrate upstream patches before dependent waves. After all waves, run the exact final acceptance suite once, not after every leaf or wave.

Read result-integration.md only when scope, ownership, evidence, applyability, or final acceptance is suspicious or fails, or when the change is risky, hard to reverse, or overlaps user work. Inspect only the relevant evidence and hunks.

Never apply or present status="incomplete" as finished. If a result is partial, stalled, failed, checks-failed, or has an unusable or empty diff, read recovery.md completely before calling sail_resume, re-delegating, or falling back locally. Prefer sail_resume only when its checkpoint makes continuation worthwhile. Recovery must remain bounded and transparent. Cancellation is terminal. Preserve partial results; re-delegate only if the user asks to continue.

After any paid Sail work, include one factual usage line in the final response; there is no minimum token threshold. Use top-level tokens.total, which is input plus output. cached_input is already part of input. Across waves, add each delegation's final aggregate once. A resumed result is cumulative, so do not add its earlier attempt again. Report searches alongside tokens.