From wakeflow
Use when Wakeflow total control starts or resumes Wakeflow Delivery Loop in Claude Code, reviews target result envelopes, creates dispatch packets, builds delivery envelopes, sends deliveries to tmux-resident window sessions with the wakeflow-claude-host helper, decides acceptance / rework / block / next wave, or stops unattended automation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/wakeflow:wakeflow-controllerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill only from the controller window. `CLAUDE.md` owns hard judgment;
Use this skill only from the controller window. CLAUDE.md owns hard judgment;
this skill owns the mechanical loop steps.
Wakeflow Delivery Loop lets the controller fan out work to target window sessions, receive compact result envelopes, review raw evidence, and decide the next package. It does not replace planning, scope control, or acceptance.
Direct-thread dispatch is the normal transport; on Claude Code a Wakeflow
thread id is the window's Claude Code session id, generated at launch and
stable across resumes. Every Wakeflow window (the controller included) is a
tmux-resident interactive claude session inside the workspace tmux server
session. In explicitly enabled unattended mode, keep reviewing results, pulling
evidence, deciding, planning next eligible packages, and dispatching until
final completion, a hard gate, explicit user stop, missing evidence that needs
human judgment, or no eligible TODO remains.
After a delivery is sent, read back, and recorded as status=sent with
readback.ok=true, the controller dispatch turn is complete. Do not keep the
turn open with sleep, repeated result review, repeated session reads, or
manual polling. The target returns later through a TargetResultEnvelope and,
if policy allows, a controller-return delivery sent to the controller's own
tmux window. As stall insurance, after dispatching a group the controller may
run wakeflow-claude-host.mjs wait-results --group <id> --target <windowA> --target <windowB> [--timeout-sec N] as a background task; it completes when
all expected target result envelopes exist (also releasing those windows'
delivery locks) and wakes the controller. A wait-results timeout means a
stalled delivery to review, not something to poll for.
Controller acceptance adapts these mature review and evidence practices:
code-reviewer: understand intent first, then review correctness, safety,
maintainability, performance, and tests; large changes start with entrypoints
and high-risk files; findings must be actionable with why and scope.senior-qa: optimize confidence per unit effort, choose test layers by risk,
and treat flakiness as evidence degradation rather than success.The controller must preserve these practices while applying Wakeflow's stricter authority boundary: target window sessions, Test, Design, scripts, Claude Code subagents (the Task/Agent tool), and MCP tools provide review inputs only. Only the controller can accept, request rework, block, wait, complete a demand, archive, or create the next package.
Controller return prompts should be compact:
Continue controller review: <windowA>, <windowB> backfill.
Variables:
- stateRoot: <path>
- dispatchGroup: <group>
- trigger: <window/task>
- blockedTargets: <only when non-empty>
- missingTargets: <only when non-empty>
- skill: skills/wakeflow-controller/SKILL.md
Do not expose empty blockedTargets or missingTargets; keep group details in
machine state.
CLAUDE.md, the active workspace index/status, and the current state
root or controller document.node <plugin>/scripts/lib/wakeflow-claude-host.mjs send --root <workspace> --window <targetWindow> --prompt-file <file> [--delivery-id <id>]. The
helper enforces the shared per-window delivery lock
(.workspace-local/wakeflow-delivery/locks/<window>.json, one in-flight
delivery per window across hosts), pastes the prompt into the target's tmux
pane via a tmux buffer (multiline-safe), and returns pane readback evidence
(readback.paneTail). If the target window is mid-turn, the pasted message
queues in its input and is processed next turn; that is fine. (Claude Code
desktop windows are not an automation transport.)wakeflow_record_delivery (default host method wakeflow-claude-host send).wait-results background
watcher for the dispatch group first.Recovery is not a delivery mode: when a target's tmux window is dead, finish or
recover the same session headless with claude -p --resume <registered session id> (the session id is stable), then relaunch the resident window with
launch-window --replace --session-id <same id> before the next delivery.
Use this shape when recording or reporting controller acceptance:
## Controller Acceptance
- User goal:
- Scope reviewed:
- Target/window:
- Evidence reviewed:
- Implementation reality:
- Validation result:
- Blockers:
- Missing evidence:
- Residual risks:
- TODO/backlog rollup:
- Decision:
- Next action:
Decision must be one of:
accept-target-resultrequest-reworkmark-blockedwait-for-missing-targetneeds-user-decisioncomplete-demandarchive-completed-workcreate-next-packageNever use accepted as a shorthand unless the evidence, scope, and TODO rollup
are already stated.
group-ready: wait until every expected target is ready or a blocker makes
the group impossible. Then return once to the controller.per-target: return when a target result arrives, still with group context.Stop instead of dispatching when:
wait-results watcher is the only allowed wait).Use the smallest verification that covers the changed surface. For Wakeflow total-control work in an installed workspace, use MCP tools instead of direct runtime scripts:
wakeflow_verify for overall Wakeflow verification. Use scriptTests: true
only when the change is Wakeflow source/plugin script maintenance.wakeflow_status for repository, state-root, and delivery-loop orientation.wakeflow_next_work for after-completion candidate scans.wakeflow_archive_workspace_docs and wakeflow_archive_todo for archive
dry-runs or applies.wakeflow_init_demand, wakeflow_add_task, wakeflow_complete_demand,
wakeflow_prepare_delivery, wakeflow_record_delivery,
wakeflow_record_target_result, wakeflow_review_pack,
wakeflow_reduce_results, and wakeflow_decide_review for state-root,
result review, and delivery mechanics.Do not run node .../plugins/cache/.../wakeflow/.../scripts/*.mjs, copy
installed runtime script paths, or infer script flags from old docs during
normal total control. If the Wakeflow MCP tool surface is unavailable, stop and
report that the plugin must be reloaded or reinstalled.
Only when the current repository is Wakeflow source and the user is maintaining Wakeflow scripts or automation, source-repo verification may use:
node scripts/wakeflow-verify.mjsnode scripts/wakeflow-verify.mjs --with-script-testsnode scripts/wakeflow-check-scripts.mjs --jsonnode scripts/wakeflow-smoke.mjsnpm testScript output is evidence, not acceptance.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub gxfn/wakeflow --plugin wakeflow