Status

---
name: status
description: "Show flow status: current step, open issues, and the next command to run"
---

# Flow status

Read-only command; performs no step work; runnable in any session. Respond in the user's language.

1. Read `docs/flow-state.md`. Missing → tell the user this project hasn't entered the flow; the entry point is **step1-onboard** (Claude Code: `/boardless-pcb:step1-onboard`) (in a fresh session). Present but **without the canonical header line** `flow-state — process state` → it belongs to something else; treat the project as not-in-flow and say so.
2. Spot-check consistency: for every step marked `done`, confirm that the deliverables which look like file paths actually exist (non-file deliverables — sign-offs, tool lists, inspection records — are not checked and not drift). Call out real gaps (a `done` status whose files are missing = state drift; suggest the user correct the status or restore the deliverables).
3. Report (one short paragraph + one small table, no deep dives):
   - Current step and each step's status. Token semantics matter here: `in-progress` = running or aborted mid-flight (say which is likelier); `waiting` = blocked on other steps, resumes automatically once they clear — not an abort; `parked` = **the flow is deliberately stopped by a user decision and the board is NOT fab-ready** — say this plainly and name the parking decision (the deferred issue holds it); `rework` = needs redoing
   - Open issues: how many, each one's target, severity, and status
   - Verification rounds: report **any** pending-verdict row in the whole table (not just the last one) — each is an aborted or unreconciled verification session
   - **Next action** — normalize everything actionable to a target step and recommend the **earliest**: steps marked `rework` and issues `open` with target 2–5 both map to their step number (multiple items on one step merge into a single recommendation — fixing the earliest step first avoids re-reworking later ones); issues `fixed-pending-verify` and `open` with target `step6` map to step 6, which participates only when no earlier step is actionable; a `parked` step is NOT a recommendation — state that resuming it is the user's call (re-run its command to un-park); nothing actionable → the EARLIEST step not marked `done` — unless that step is `parked`, in which case make NO recommendation: say plainly that the flow is stopped where the user chose to stop it, and that re-running that step's command un-parks it (never skip past a `parked` step to a later one — the later step's own gate would reject it anyway); every step `done` → the flow is complete
4. If the user then asks to execute a step, remind them: steps run in a **fresh session** (= `/clear` or restart your agent in this project) via their command; if this session has already done other work, don't run a step here.