@humwick/runner 0.130.5 → 0.130.6

package/plugins/claude/skills/slice-first/references/plan-recipe.md

@@ -1,46 +1,47 @@
 # Plan recipe (coordinator only)
 
-1. **Frame.** `relay_plan_create { title:"<feature>", acceptance:[{ id, text, check?:{ path }|{ command } }] }`.
+1. **Frame.** `humwick_plan_create { title:"<feature>", acceptance:[{ id, text, check?:{ path }|{ command } }] }`.
    Acceptance is required: the plan's own bar (the design doc's deliverables, deletions and
    acceptance commands), one checkable item each. Then create and bind the spec Task:
-   `relay_task_create { intent, issueRefs:["#<feature>"] }` →
-   `relay_plan_add_node { planId, node:{ id:"spec", label:"Slice spec", lane:"frame", refs:{ taskId:<spec> } } }`.
+   `humwick_task_create { intent, issueRefs:["#<feature>"] }` →
+   `humwick_plan_add_node { planId, node:{ id:"spec", label:"Slice spec", lane:"frame", refs:{ taskId:<spec> } } }`.
    Record the fixed v1 bar and budget on this Task; spawn `software-design` on it.
-2. **Slice.** Create the build Task (normal landing Task) and the proof Task. The proof
-   Task must not land: `relay_task_create { intent:"Independent slice proof",
-   doneWhen:"delivered", dispatch:{ type:"review" }, context:"<proof command>; <instance>" }`.
-   Add both as nodes (lane `slice`, `refs:{ taskId }`) and edges `spec→build`, `build→proof`
-   (`relay_plan_add_edge { planId, from, to }`: `to` depends on `from`; edges between bound
-   nodes become Task dependencies). Spawn a `worker` on `build`; when its project delivery/deployment
-   gates pass, spawn `QA` on `proof`.
-3. **Gate.** The prover delivers the proof Task; that closes it `done` with no land attempt
-   because it is a delivered review Task. `relay_task_record_gate` alone does not finish it,
-   so its harden dependents stay on an open upstream.
-   - Pass: `relay_task_deliver { disposition:"complete", summary, gates:{ other:[{ name:"slice-proof", status:"pass", detail:"<command> @ <sha> on <instance>" }] } }`
-   - Fail: `relay_task_deliver { disposition:"failed", summary, reason:"<blocker>", gates:{ other:[{ name:"slice-proof", status:"fail", detail }] } }`
-
-   Fail → frame again (new spec revision, same plan). Pass → verify the proof Task is
-   `done` with `slice-proof: pass`, then record the stage on the spec Task:
-   `relay_task_memory_append_decision { taskId:<spec>, decision:"stage: harden" }`.
+2. **Slice.** Create one slice Task, a normal landing Task whose execution is the
+   `slice-proof` workflow: `humwick_task_create { intent, doneWhen, execution:{ workflow:"slice-proof",
+   inputs:{ command:"<proof command>", instance:"<dev or ephemeral instance>" } } }`. There is no
+   proof Task. Add it as a node (lane `slice`, `refs:{ taskId }`) with the edge `spec→slice`
+   (`humwick_plan_add_edge { planId, from, to }`: `to` depends on `from`; edges between bound
+   nodes become Task dependencies). Plan autopilot starts its run; by hand:
+   `humwick_workflow_start { workflow:"slice-proof", taskId:<slice>, inputs:{ command, instance } }`.
+   The run builds and reviews the slice, lands it, then a fresh `slice-qa` agent reproduces
+   the proof on the slice Task itself.
+3. **Gate.** The QA agent records the `slice-proof` verdict on the slice Task with
+   `humwick_task_verdict` (pass or fail, the landed commit, command, instance and evidence).
+   Until it passes, the slice Task stays `validating` (failed: in progress) and its dependents
+   wait for the proof verdict. Fail → the run escalates to you → frame again (new spec
+   revision, same plan). Pass → the slice Task is `done`; confirm with
+   `humwick_task_get { taskId:<slice>, verbose:true }` (`status:"done"`, gate `slice-proof`
+   with `status:"pass"`), then record the stage on the spec Task:
+   `humwick_task_memory_append_decision { taskId:<spec>, decision:"stage: harden" }`.
 4. **Harden.** Only now add harden nodes (lane `harden`, bound to their Tasks), each with
-   an edge `proof→<node>`, up to the budget. Each harden builder delivers normally and adds
-   the proof re-run: `relay_task_deliver { disposition:"complete", summary, commits,
+   an edge `slice→<node>`, up to the budget. Each harden builder delivers normally and adds
+   the proof re-run: `humwick_task_deliver { disposition:"complete", summary, commits,
    idempotencyKey, gates:{ test:{ status:"pass" }, other:[{ name:"slice-proof", status:"pass" }] } }`.
 5. **Conformance.** When every node lands the plan reads `completion:"conformance-pending"`,
    not done, and you get a `plan.conformance-pending` notice. Fetch, check each acceptance item
    on the main tip (or spawn a fresh agent to audit it), then
-   `relay_plan_conformance { planId, mainSha:<origin/main tip>, items:[{ id, status:"met"|"unmet", note? }] }`.
+   `humwick_plan_conformance { planId, mainSha:<origin/main tip>, items:[{ id, status:"met"|"unmet", note? }] }`.
    A gap files one bound Task per unmet item and reopens the plan; repeat after they land.
    Only a pass makes the plan `done`.
 6. **v1/closed.** Bar met → flag on, file "future" issues, record `stage: v1`;
    after closure, record `stage: closed` and archive the plan.
 
-Before spawning a harden builder, read `relay_task_get { taskId:<harden>, verbose:true }`
-for `dependsOn`, then `relay_task_get { taskId:<proof>, verbose:true }`; require
-`status:"done"` and `slice-proof` with `status:"pass"`. Relay records dependencies;
-the coordinator enforces dispatch order. Validate with the project's own commands
+Before spawning a harden builder by hand, read `humwick_task_get { taskId:<harden>, verbose:true }`
+for `dependsOn`, then the slice Task: require `status:"done"` and gate `slice-proof` with
+`status:"pass"`. Plan autopilot and Task dependencies already hold dependents of a slice whose
+proof is open or failed; a hand spawn is not held. Validate with the project's own commands
 from its spawn brief/config; the proof is an additional gate.
 
-Check gate order any time with `relay_plan_get { planId, mode:"lean" }`: every
-`harden` node must have `proof` upstream, and no harden node may exist while the proof
-Task is not complete with a passing `slice-proof` gate.
+Check gate order any time with `humwick_plan_get { planId, mode:"lean" }`: every
+`harden` node must have `slice` upstream, and no harden node may exist while the slice
+Task is not `done` with a passing `slice-proof` verdict.

package/plugins/claude/skills/status/SKILL.md

@@ -10,7 +10,7 @@ allowed-tools: [Bash]
 Run:
 
 ```bash
-agent-relay /status $ARGUMENTS
+humwick /status $ARGUMENTS
 ```
 
 Summarize the current relay connection, agent identity, label, and tags.

package/plugins/claude/skills/tags/SKILL.md

@@ -10,16 +10,16 @@ allowed-tools: [Bash]
 Run:
 
 ```bash
-agent-relay /tags $ARGUMENTS
+humwick /tags $ARGUMENTS
 ```
 
 Examples:
 
 ```bash
-agent-relay /tags
-agent-relay /tags backend tests urgent
-agent-relay /tags --add backend,tests
-agent-relay /tags --remove urgent
+humwick /tags
+humwick /tags backend tests urgent
+humwick /tags --add backend,tests
+humwick /tags --remove urgent
 ```
 
 Report the resulting tags briefly.

package/plugins/claude/skills/task/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: agent-relay-task
+name: humwick-task
 description: Use Humwick Task tools to create, update, and document durable work records. Use when coordinating multi-step work or when your brief was spawned from a Task.
 ---
 
@@ -9,20 +9,20 @@ Use Relay Task tools for durable work tracking instead of burying state in chat.
 
 Coordinators:
 
-- Create a Task before multi-step work with `relay_task_create`.
+- Create a Task before multi-step work with `humwick_task_create`.
 - Set `intent`, `complexity`, and useful `context`; add `doneWhen`, `dispatch`, refs, or dependencies when they clarify routing.
 - Spawn workers from the Task so they inherit the Task context.
 
 Workers:
 
-- Use `relay_task_set_status` as work moves through `in_progress`, `blocked`, `done`, `failed`, or `canceled`.
-- Use `relay_task_memory_replace_working_state` for current progress a retry agent needs.
-- Use `relay_task_memory_append_decision` for durable choices and rationale.
-- Use `relay_task_memory_append_ruled_out` for dead ends, failed approaches, and why they were rejected.
+- Use `humwick_task_set_status` as work moves through `in_progress`, `blocked`, `done`, `failed`, or `canceled`.
+- Use `humwick_task_memory_replace_working_state` for current progress a retry agent needs.
+- Use `humwick_task_memory_append_decision` for durable choices and rationale.
+- Use `humwick_task_memory_append_ruled_out` for dead ends, failed approaches, and why they were rejected.
 
 Useful reads and updates:
 
-- `relay_task_get` and `relay_task_history` inspect the Task and audit timeline.
-- `relay_task_update` refreshes intent, context, latest steer, doneWhen, complexity, or dispatch.
-- `relay_task_record_gate` records tests, typecheck, docs, smoke, and other quality gates.
-- `relay_task_dispatch` maps Task shape to a concrete spawn and launches it bound to the Task (shared spawn path). Idempotent retry needs a caller-supplied spawnRequestId, as with relay_spawn_agent.
+- `humwick_task_get` and `humwick_task_history` inspect the Task and audit timeline.
+- `humwick_task_update` refreshes intent, context, latest steer, doneWhen, complexity, or dispatch.
+- `humwick_task_record_gate` records tests, typecheck, docs, smoke, and other quality gates.
+- `humwick_task_dispatch` maps Task shape to a concrete spawn and launches it bound to the Task (shared spawn path). Idempotent retry needs a caller-supplied spawnRequestId, as with humwick_spawn_agent.

package/plugins/claude-output-style/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
-  "name": "agent-relay-output-style",
+  "name": "humwick-output-style",
   "description": "Suppress Claude Code's redundant default output-style instructions for Relay-managed sessions",
   "version": "0.129.23"
 }

package/plugins/claude-output-style/output-styles/{agent-relay.md → humwick.md}

@@ -1,5 +1,5 @@
 ---
-name: Agent Relay
+name: Humwick
 description: Relay-managed sessions provide their communication rules through the agent profile.
 force-for-plugin: true
 ---

package/plugins/codex/skills/guide/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: ""
 Run:
 
 ```bash
-agent-relay /guide
+humwick /guide
 ```
 
 Use this before guessing Relay commands. The guide explains reply, message, status, label, tag, target, and claimable-work commands.

package/plugins/codex/skills/label/SKILL.md

@@ -9,14 +9,14 @@ argument-hint: "[LABEL|--clear]"
 Run:
 
 ```bash
-agent-relay /label $ARGUMENTS
+humwick /label $ARGUMENTS
 ```
 
 Examples:
 
 ```bash
-agent-relay /label backend-fixer
-agent-relay /label --clear
+humwick /label backend-fixer
+humwick /label --clear
 ```
 
 Report the new label or current label briefly.

package/plugins/codex/skills/message/SKILL.md

@@ -9,12 +9,12 @@ allowed-tools: [Bash]
 
 ⚠️ **SECURITY — never inline the message body in the shell command.** A body with
 markdown backticks `` `like this` `` or `$(...)` would be shell-executed (command
-substitution) before `agent-relay` sees it — a command-injection vector (#1262),
+substitution) before `humwick` sees it — a command-injection vector,
 since the body may quote another agent's or a user's text. **Feed the body through
 stdin via a quoted heredoc** (the `'RELAY_EOF'` quotes disable all expansion):
 
 ```bash
-agent-relay /message <target> --stdin <<'RELAY_EOF'
+humwick /message <target> --stdin <<'RELAY_EOF'
 Your message text. Backticks `bun run release` and $(anything) are delivered
 verbatim and are NOT executed.
 RELAY_EOF
@@ -24,17 +24,17 @@ Targets (the `<target>` positional) can be an agent id, `tag:`, `policy:`, `cap:
 `broadcast`:
 
 ```bash
-agent-relay /message codex --stdin <<'RELAY_EOF'
+humwick /message codex --stdin <<'RELAY_EOF'
 Can you look at that failing action?
 RELAY_EOF
 
-agent-relay /message tag:backend --stdin <<'RELAY_EOF'
+humwick /message tag:backend --stdin <<'RELAY_EOF'
 Does anyone see the regression?
 RELAY_EOF
 ```
 
 For a message you have already staged in a file, use `--body-file PATH` instead.
 
-**Do NOT** build `agent-relay /message <target> "…body…"` with the body inside quotes.
+**Do NOT** build `humwick /message <target> "…body…"` with the body inside quotes.
 
 Report the sent message id briefly.

package/plugins/codex/skills/react/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: "<messageId> <emoji> [--remove]"
 Run:
 
 ```bash
-agent-relay /react $ARGUMENTS
+humwick /react $ARGUMENTS
 ```
 
 Use reactions instead of text when the message only needs lightweight acknowledgement, approval, thanks, or "good job".

package/plugins/codex/skills/read-message/SKILL.md

@@ -9,15 +9,15 @@ argument-hint: "<messageId> [--json|--body]"
 Run:
 
 ```bash
-agent-relay get-message $ARGUMENTS
+humwick get-message $ARGUMENTS
 ```
 
 Useful forms:
 
 ```bash
-agent-relay get-message 206
-agent-relay get-message 206 --json
-agent-relay get-message 206 --body
+humwick get-message 206
+humwick get-message 206 --json
+humwick get-message 206 --body
 ```
 
 Use `--body` when you only need the complete message text. Use `--json` when attachments, metadata, or thread context matter.

package/plugins/codex/skills/reply/SKILL.md

@@ -9,15 +9,15 @@ allowed-tools: [Bash]
 
 ⚠️ **SECURITY — never inline the reply body in the shell command.** Your shell runs
 the command you type, so a body containing markdown backticks `` `like this` `` or
-`$(...)` would be executed as a shell command *before* `agent-relay` ever sees it
-(command substitution). This is a real command-injection vector (#1262): the body may
+`$(...)` would be executed as a shell command *before* `humwick` ever sees it
+(command substitution). This is a real command-injection vector: the body may
 quote another agent's or a user's text. **Always feed the body through stdin via a
 quoted heredoc**, which disables all shell expansion and delivers the body verbatim.
 
 Run (safe — quoted `'RELAY_EOF'` delimiter means no expansion, no substitution):
 
 ```bash
-agent-relay /reply <messageId> --stdin <<'RELAY_EOF'
+humwick /reply <messageId> --stdin <<'RELAY_EOF'
 Your reply text here. Backticks `bun run release` and $(anything) are delivered
 verbatim and are NOT executed.
 RELAY_EOF
@@ -29,7 +29,7 @@ The server auto-routes the reply to the original sender and inherits the channel
 For a reply you have already staged in a file, use `--body-file` instead:
 
 ```bash
-agent-relay /reply <messageId> --body-file .agent-relay/sessions/$AGENT_RELAY_ID/tmp/reply.md
+humwick /reply <messageId> --body-file $TMPDIR/reply.md
 ```
 
 The relay creates that per-session scratch dir for you (git-ignored locally), so
@@ -37,7 +37,7 @@ staging there never pollutes the working tree and never collides with other agen
 No cleanup needed — the dir is reaped when your session ends. Oversized replies are
 automatically uploaded as an Humwick artifact and sent as an attached concise reply.
 
-**Do NOT** build `agent-relay /reply <id> "…body…"` with the body inside quotes — the
+**Do NOT** build `humwick /reply <id> "…body…"` with the body inside quotes — the
 heredoc `--stdin` form above is the only safe way to pass free text.
 
 Do not send a separate Relay follow-up that only confirms the reply was sent. The CLI

package/plugins/codex/skills/send-claimable/SKILL.md

@@ -9,12 +9,12 @@ allowed-tools: [Bash]
 
 ⚠️ **SECURITY — never inline the work-item body in the shell command.** A body with
 markdown backticks `` `like this` `` or `$(...)` would be shell-executed (command
-substitution) before `agent-relay` sees it — a command-injection vector (#1262).
+substitution) before `humwick` sees it — a command-injection vector.
 **Feed the body through stdin via a quoted heredoc** (the `'RELAY_EOF'` quotes disable
 all expansion, delivering the body verbatim):
 
 ```bash
-agent-relay /send-claimable <target> --stdin <<'RELAY_EOF'
+humwick /send-claimable <target> --stdin <<'RELAY_EOF'
 Describe the work item here. Backticks `bun run release` and $(anything) are
 delivered verbatim and are NOT executed.
 RELAY_EOF
@@ -23,17 +23,17 @@ RELAY_EOF
 Targets can be an agent id, `tag:`, `cap:`, or `policy:`:
 
 ```bash
-agent-relay /send-claimable tag:backend --stdin <<'RELAY_EOF'
+humwick /send-claimable tag:backend --stdin <<'RELAY_EOF'
 Fix the failing API test
 RELAY_EOF
 
-agent-relay /send-claimable cap:review --stdin <<'RELAY_EOF'
+humwick /send-claimable cap:review --stdin <<'RELAY_EOF'
 Review the migration patch
 RELAY_EOF
 ```
 
 For a work item you have already staged in a file, use `--body-file PATH` instead.
 
-**Do NOT** build `agent-relay /send-claimable <target> "…body…"` with the body inside quotes.
+**Do NOT** build `humwick /send-claimable <target> "…body…"` with the body inside quotes.
 
 Report the sent claimable message id briefly.

package/plugins/codex/skills/slice-first/SKILL.md

@@ -6,7 +6,7 @@ description: Frame and prove a thin end-to-end feature slice before planning har
 # Slice first
 
 Use the current project's instructions and configured validation/deployment gates,
-including its “How to validate in THIS project” brief or `.agent-relay/land-gates.json`.
+including its “How to validate in THIS project” brief or the project’s `land-gates.json`.
 Choose the proof's location and runtime in that project; no particular repo is required.
 
 | Stage | Required result |
@@ -19,8 +19,10 @@ Choose the proof's location and runtime in that project; no particular repo is r
 
 Coordinator owns stages, scope ledger and budget; record stage decisions on the spec
 Task. Changing the bar or exceeding the budget needs operator approval. A blocked
-slice returns to frame. Never create or spawn harden Tasks before the proof Task is
-done with `slice-proof: pass`; dependencies alone do not prevent dispatch.
+slice returns to frame. Never spawn harden builders before the slice Task is `done`
+with a passing `slice-proof` verdict. Relay holds the slice Task's dependents (plan
+nodes, Task dependencies) while its proof is open or failed; a builder you spawn by
+hand is not held.
 
 Design writes proof then spec, no full design. Builder declares each slice shortcut
 in delivery risks. QA reproduces independently. Review blocks only on the stage's

package/plugins/codex/skills/slice-first/references/plan-recipe.md

@@ -1,46 +1,47 @@
 # Plan recipe (coordinator only)
 
-1. **Frame.** `relay_plan_create { title:"<feature>", acceptance:[{ id, text, check?:{ path }|{ command } }] }`.
+1. **Frame.** `humwick_plan_create { title:"<feature>", acceptance:[{ id, text, check?:{ path }|{ command } }] }`.
    Acceptance is required: the plan's own bar (the design doc's deliverables, deletions and
    acceptance commands), one checkable item each. Then create and bind the spec Task:
-   `relay_task_create { intent, issueRefs:["#<feature>"] }` →
-   `relay_plan_add_node { planId, node:{ id:"spec", label:"Slice spec", lane:"frame", refs:{ taskId:<spec> } } }`.
+   `humwick_task_create { intent, issueRefs:["#<feature>"] }` →
+   `humwick_plan_add_node { planId, node:{ id:"spec", label:"Slice spec", lane:"frame", refs:{ taskId:<spec> } } }`.
    Record the fixed v1 bar and budget on this Task; spawn `software-design` on it.
-2. **Slice.** Create the build Task (normal landing Task) and the proof Task. The proof
-   Task must not land: `relay_task_create { intent:"Independent slice proof",
-   doneWhen:"delivered", dispatch:{ type:"review" }, context:"<proof command>; <instance>" }`.
-   Add both as nodes (lane `slice`, `refs:{ taskId }`) and edges `spec→build`, `build→proof`
-   (`relay_plan_add_edge { planId, from, to }`: `to` depends on `from`; edges between bound
-   nodes become Task dependencies). Spawn a `worker` on `build`; when its project delivery/deployment
-   gates pass, spawn `QA` on `proof`.
-3. **Gate.** The prover delivers the proof Task; that closes it `done` with no land attempt
-   because it is a delivered review Task. `relay_task_record_gate` alone does not finish it,
-   so its harden dependents stay on an open upstream.
-   - Pass: `relay_task_deliver { disposition:"complete", summary, gates:{ other:[{ name:"slice-proof", status:"pass", detail:"<command> @ <sha> on <instance>" }] } }`
-   - Fail: `relay_task_deliver { disposition:"failed", summary, reason:"<blocker>", gates:{ other:[{ name:"slice-proof", status:"fail", detail }] } }`
-
-   Fail → frame again (new spec revision, same plan). Pass → verify the proof Task is
-   `done` with `slice-proof: pass`, then record the stage on the spec Task:
-   `relay_task_memory_append_decision { taskId:<spec>, decision:"stage: harden" }`.
+2. **Slice.** Create one slice Task, a normal landing Task whose execution is the
+   `slice-proof` workflow: `humwick_task_create { intent, doneWhen, execution:{ workflow:"slice-proof",
+   inputs:{ command:"<proof command>", instance:"<dev or ephemeral instance>" } } }`. There is no
+   proof Task. Add it as a node (lane `slice`, `refs:{ taskId }`) with the edge `spec→slice`
+   (`humwick_plan_add_edge { planId, from, to }`: `to` depends on `from`; edges between bound
+   nodes become Task dependencies). Plan autopilot starts its run; by hand:
+   `humwick_workflow_start { workflow:"slice-proof", taskId:<slice>, inputs:{ command, instance } }`.
+   The run builds and reviews the slice, lands it, then a fresh `slice-qa` agent reproduces
+   the proof on the slice Task itself.
+3. **Gate.** The QA agent records the `slice-proof` verdict on the slice Task with
+   `humwick_task_verdict` (pass or fail, the landed commit, command, instance and evidence).
+   Until it passes, the slice Task stays `validating` (failed: in progress) and its dependents
+   wait for the proof verdict. Fail → the run escalates to you → frame again (new spec
+   revision, same plan). Pass → the slice Task is `done`; confirm with
+   `humwick_task_get { taskId:<slice>, verbose:true }` (`status:"done"`, gate `slice-proof`
+   with `status:"pass"`), then record the stage on the spec Task:
+   `humwick_task_memory_append_decision { taskId:<spec>, decision:"stage: harden" }`.
 4. **Harden.** Only now add harden nodes (lane `harden`, bound to their Tasks), each with
-   an edge `proof→<node>`, up to the budget. Each harden builder delivers normally and adds
-   the proof re-run: `relay_task_deliver { disposition:"complete", summary, commits,
+   an edge `slice→<node>`, up to the budget. Each harden builder delivers normally and adds
+   the proof re-run: `humwick_task_deliver { disposition:"complete", summary, commits,
    idempotencyKey, gates:{ test:{ status:"pass" }, other:[{ name:"slice-proof", status:"pass" }] } }`.
 5. **Conformance.** When every node lands the plan reads `completion:"conformance-pending"`,
    not done, and you get a `plan.conformance-pending` notice. Fetch, check each acceptance item
    on the main tip (or spawn a fresh agent to audit it), then
-   `relay_plan_conformance { planId, mainSha:<origin/main tip>, items:[{ id, status:"met"|"unmet", note? }] }`.
+   `humwick_plan_conformance { planId, mainSha:<origin/main tip>, items:[{ id, status:"met"|"unmet", note? }] }`.
    A gap files one bound Task per unmet item and reopens the plan; repeat after they land.
    Only a pass makes the plan `done`.
 6. **v1/closed.** Bar met → flag on, file "future" issues, record `stage: v1`;
    after closure, record `stage: closed` and archive the plan.
 
-Before spawning a harden builder, read `relay_task_get { taskId:<harden>, verbose:true }`
-for `dependsOn`, then `relay_task_get { taskId:<proof>, verbose:true }`; require
-`status:"done"` and `slice-proof` with `status:"pass"`. Relay records dependencies;
-the coordinator enforces dispatch order. Validate with the project's own commands
+Before spawning a harden builder by hand, read `humwick_task_get { taskId:<harden>, verbose:true }`
+for `dependsOn`, then the slice Task: require `status:"done"` and gate `slice-proof` with
+`status:"pass"`. Plan autopilot and Task dependencies already hold dependents of a slice whose
+proof is open or failed; a hand spawn is not held. Validate with the project's own commands
 from its spawn brief/config; the proof is an additional gate.
 
-Check gate order any time with `relay_plan_get { planId, mode:"lean" }`: every
-`harden` node must have `proof` upstream, and no harden node may exist while the proof
-Task is not complete with a passing `slice-proof` gate.
+Check gate order any time with `humwick_plan_get { planId, mode:"lean" }`: every
+`harden` node must have `slice` upstream, and no harden node may exist while the slice
+Task is not `done` with a passing `slice-proof` verdict.

package/plugins/codex/skills/status/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: "[--json]"
 Run:
 
 ```bash
-agent-relay /status $ARGUMENTS
+humwick /status $ARGUMENTS
 ```
 
 Summarize the current relay connection, agent identity, label, and tags.

package/plugins/codex/skills/tags/SKILL.md

@@ -9,16 +9,16 @@ argument-hint: "[TAG ...|--list|--add TAGS|--remove TAGS]"
 Run:
 
 ```bash
-agent-relay /tags $ARGUMENTS
+humwick /tags $ARGUMENTS
 ```
 
 Examples:
 
 ```bash
-agent-relay /tags
-agent-relay /tags backend tests urgent
-agent-relay /tags --add backend,tests
-agent-relay /tags --remove urgent
+humwick /tags
+humwick /tags backend tests urgent
+humwick /tags --add backend,tests
+humwick /tags --remove urgent
 ```
 
 Report the resulting tags briefly.

package/plugins/codex/skills/task/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: agent-relay-task
+name: humwick-task
 description: Use Humwick Task tools to create, update, and document durable work records. Use when coordinating multi-step work or when your brief was spawned from a Task.
 ---
 
@@ -9,20 +9,21 @@ Use Relay Task tools for durable work tracking instead of burying state in chat.
 
 Coordinators:
 
-- Create a Task before multi-step work with `relay_task_create`.
+- Create a Task before multi-step work with `humwick_task_create`.
 - Set `intent`, `complexity`, and useful `context`; add `doneWhen`, `dispatch`, refs, or dependencies when they clarify routing.
 - Spawn workers from the Task so they inherit the Task context.
 
 Workers:
 
-- Use `relay_task_set_status` as work moves through `in_progress`, `blocked`, `done`, `failed`, or `canceled`.
-- Use `relay_task_memory_replace_working_state` for current progress a retry agent needs.
-- Use `relay_task_memory_append_decision` for durable choices and rationale.
-- Use `relay_task_memory_append_ruled_out` for dead ends, failed approaches, and why they were rejected.
+- Deliver with `humwick_task_deliver` after code, committed tests and the project's delivery gate pass. Checks explicitly marked post-deploy/onDeploy are verified after landing; name them in delivery risks and deliver `complete`, rather than blocking on a deployment the builder does not own.
+- Use `humwick_task_set_status` as work moves through `in_progress`, `blocked`, `done`, `failed`, or `canceled`.
+- Use `humwick_task_memory_replace_working_state` for current progress a retry agent needs.
+- Use `humwick_task_memory_append_decision` for durable choices and rationale.
+- Use `humwick_task_memory_append_ruled_out` for dead ends, failed approaches, and why they were rejected.
 
 Useful reads and updates:
 
-- `relay_task_get` and `relay_task_history` inspect the Task and audit timeline.
-- `relay_task_update` refreshes intent, context, latest steer, doneWhen, complexity, or dispatch.
-- `relay_task_record_gate` records tests, typecheck, docs, smoke, and other quality gates.
-- `relay_task_dispatch` maps Task shape to a concrete spawn and launches it bound to the Task (shared spawn path). Idempotent retry needs a caller-supplied spawnRequestId, as with relay_spawn_agent.
+- `humwick_task_get` and `humwick_task_history` inspect the Task and audit timeline.
+- `humwick_task_update` refreshes intent, context, latest steer, doneWhen, complexity, or dispatch.
+- `humwick_task_record_gate` records tests, typecheck, docs, smoke, and other quality gates.
+- `humwick_task_dispatch` maps Task shape to a concrete spawn and launches it bound to the Task (shared spawn path). Idempotent retry needs a caller-supplied spawnRequestId, as with humwick_spawn_agent.