| name | delegate |
| description | Use when the user runs "/waystone:delegate" in Claude Code or "$waystone:delegate" in Codex, asks to delegate an implementation task, wants to inspect or independently verify a delegation result, or needs to apply or discard a reviewable delegated patch. |
waystone: delegate
Run one task in an isolated worktree, preserve provenance labels, and leave acceptance to the user.
Require an initialized project.
Host contract
- Claude Code: invoke
/waystone:delegate; assign $CLAUDE_PLUGIN_ROOT to
WAYSTONE_PLUGIN_ROOT, then run command examples with waystone from PATH.
- Codex: invoke
$waystone:delegate; from this skill's directory walk up two parents, assign that
absolute path to WAYSTONE_PLUGIN_ROOT, then run command examples with
$WAYSTONE_PLUGIN_ROOT/bin/waystone-codex.
- Resolve plugin resources from
$WAYSTONE_PLUGIN_ROOT. Ask required choices through the host's
native user-interaction mechanism (AskUserQuestion on Claude Code, or Codex's native mechanism);
never require one named tool across both hosts.
Step 1 — Select a delegable task
Use the task ID from the argument. Otherwise present the injected next-actionable tasks (or run
waystone task list .) and ask the user to select one.
Do not invent acceptance criteria. waystone delegate run refuses a task without an accept: YAML list
or explicit --accept. If criteria are missing, explain that the user must add them to the task in
tasks.yaml; do not synthesize a bar merely to make the command pass.
Step 2 — Run the delegation
waystone delegate run <task-id> --root <project-root>
Relay the stdout summary: immutable base, dirty-snapshot flag, worktree, env prep, runner binding,
and artifact path. Relay every waystone warn line from stderr unchanged; never hide a warning.
Step 3 — Summarize the contract without judging it
Read the bounded contract surface only:
waystone delegate show <delegation-id> --report --root <project-root>
Present harness-computed changed files/base/result as explicit evidence. Keep verification,
limitations, risks, and escalations labeled delegate-claimed.
HARD rules:
- Never promote delegate-claimed content to fact.
- Never generate a pass/fail or acceptance verdict. The contract intentionally has none.
- Never treat a missing delegate report as proof that verification did not happen; it is a reporting
absence.
Step 4 — Offer independent verification
Use the current host's data root (~/.claude/waystone for Claude Code,
~/.codex/waystone for Codex). If its profile.yml has a verifier binding, ask once through
the host-native interaction mechanism whether to run it. The binding's execution must be
codex-companion for Claude Code and codex-cli for Codex. If accepted:
waystone delegate verify <delegation-id> --root <project-root>
waystone delegate show <delegation-id> --verify --root <project-root>
Summarize the latest payload as independent-verifier evidence. Preserve that label and do not
turn the payload into an acceptance verdict. Verification leaves the state needs-review.
Step 5 — Ask the user to accept or discard
Ask once through the host-native interaction mechanism for the user's decision: apply or
discard. Do not choose on their behalf. Run exactly the selected command and report the result:
waystone delegate apply <delegation-id> --root <project-root>
waystone delegate discard <delegation-id> --root <project-root>
Again relay any stderr warning unchanged.
Context discipline
Use command stdout plus contract.yaml and the latest verify-<n>.json through the show surfaces.
Do not read runner.jsonl or traverse the preserved worktree wholesale. Inspect a specific file only
when the user asks or a bounded evidence item requires it.
