status

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.