/status
Report the Wakeflow workspace state, what is next and who owns it, and verify it strictly when something looks wrong
> /plugin marketplace add GxFn/Wakeflow> /plugin install wakeflow@gxfn
Command definition
status.mddescription: Report the Wakeflow workspace state, what is next and who owns it, and verify it strictly when something looks wrong
argument-hint: "[demand id]"
Report where this Wakeflow workspace stands.
Load the `wakeflow-controller` skill and follow its "Checking the workspace" section. `runtime-artifact-outdated` / `server-outdated` describe this serving MCP process; its `next` owner follows the host - `controller` where this Controller restarts its own window in place, `user` where only an application restart reloads the server. `window-runtime-unverified` describes missing peer runtime evidence, not a proven stale process. Load the current skill and follow "After a plugin update"; do not infer MCP readiness from SessionStart or Stop records.
First tool call: `wakeflow_status`, passing a Demand id if the user named one, to attach that Demand's route or its archive receipt.
Report in the user's terms: the overall state, what is on the board, the active Demand and its frontier, any window that is not registered, any window whose `attention` is `needed` (the host is waiting for the user there - a permission prompt, an idle prompt, a login or usage limit - so name it before waiting on that window), any registered window whose `launchIntent` is `drifted` (it was launched or last resumed under an older launch intent; a replacing handshake renews the record, nothing fails on it), any `legacyResidue` item (old-plugin content the user removes by hand - name its root, file and line), any `hostAssets` entry that is not `current`, any work claim that is held, and the next actions the result named - with who owns each one.
An idle workspace - no Demand, nothing pending - names `requirement-authoring` with the user as owner: say in one sentence that the next step is theirs, in the Design window; no tutorial.
Run `wakeflow_verify` as well when the status contradicts itself, when a delivery looked sent but no evidence arrived, or when the user asks whether the workspace is sound. It repairs nothing; report each gate that did not pass, and report an unavailable gate as unchecked rather than as passing.
Read more
description: Report the Wakeflow workspace state, what is next and who owns it, and verify it strictly when something looks wrong argument-hint: "[demand id]"
Report where this Wakeflow workspace stands.
Load the `wakeflow-controller` skill and follow its "Checking the workspace" section. `runtime-artifact-outdated` / `server-outdated` describe this serving MCP process; its `next` owner follows the host - `controller` where this Controller restarts its own window in place, `user` where only an application restart reloads the server. `window-runtime-unverified` describes missing peer runtime evidence, not a proven stale process. Load the current skill and follow "After a plugin update"; do not infer MCP readiness from SessionStart or Stop records.
First tool call: `wakeflow_status`, passing a Demand id if the user named one, to attach that Demand's route or its archive receipt.
Report in the user's terms: the overall state, what is on the board, the active Demand and its frontier, any window that is not registered, any window whose `attention` is `needed` (the host is waiting for the user there - a permission prompt, an idle prompt, a login or usage limit - so name it before waiting on that window), any registered window whose `launchIntent` is `drifted` (it was launched or last resumed under an older launch intent; a replacing handshake renews the record, nothing fails on it), any `legacyResidue` item (old-plugin content the user removes by hand - name its root, file and line), any `hostAssets` entry that is not `current`, any work claim that is held, and the next actions the result named - with who owns each one.
An idle workspace - no Demand, nothing pending - names `requirement-authoring` with the user as owner: say in one sentence that the next step is theirs, in the Design window; no tutorial.
Run `wakeflow_verify` as well when the status contradicts itself, when a delivery looked sent but no evidence arrived, or when the user asks whether the workspace is sound. It repairs nothing; report each gate that did not pass, and report an unavailable gate as unchecked rather than as passing.
A disciplined control loop for multi-window agent work — every step traced, every result reviewable.
Other commands on wakeflow.
More commands from other plugins.
build
CommandImplement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass.

