Status

status - where the project stands right now

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

Where this sits in the workflow:

any time  ->  [status]  ->  reads build-plan + current-feature + git
              (read-only)   prints a short "you are here"

This skill answers one question: where am I? It reads the files that already track progress and prints a short orientation. It is the fast way back in after a break, a context clear, or a day away. It never changes anything: no edits, no commits, no installs, no builds, no branch changes.

Progress in this workflow lives in files, not the chat, so everything this skill reports comes from disk and git. That is the point: a fresh session can run /status and know exactly as much as the last one did.

For setup problems, missing files, placeholder plans, adapter drift, or questions about whether the Blueprint is installed correctly, run /doctor instead.

Input

None. /status takes no argument.

What it reads

Gather these, then summarize. Don't dump file contents; report the distilled state.

1. Project configuration - read blueprint/config.json when present. Report project settings, built-in defaults, or invalid, using defaults. A missing file is healthy and means defaults. Invalid JSON, schema versions, keys, values, non-file paths, or symbolic links are a warning and make /doctor the next action before any mutating workflow command. Report the effective regular and Continuous audit, independent-review, check, and try-guide policies, plus review.independentExecution. Explain that independent review defaults to when-sensitive for both workflows and execution defaults to automatic, which uses an isolated reviewer only when the current adapter supports it. Audit, check, and try guide default to manual. Before recommending /overview, check whether AGENTS.md still contains the shipped For a standard Next.js project command marker. When it does, onboarding is incomplete and /onboard is the next action.
2. Build plan - blueprint/build-plan.md. Count checked vs unchecked leaf items. Name the next unchecked leaf, the same target /feature would pick, and note if a parent item was split into sub-items (4a, 4b, ...).
3. Current work - blueprint/context/current-feature.md. Is something in progress, or is it the reset stub? If a feature, fix, or rollback spec is present, report its type and name, which build steps are checked, and the first unchecked step where /implement resumes.
4. Findings - blueprint/context/findings.md. Count findings by status and report open and fixed counts next to build-plan progress. Call out any P0 or P1 still open or fixed by ID, since those block /complete. A missing file means no findings.
5. Independent review - blueprint/context/review.md. Report none, pending, changes-requested, passed, malformed, or stale. For an active record, name the requested or actual reviewer adapter and model. A selected or explicitly initiated independent review blocks /complete until a passing receipt matches the exact current checkpoint and spec.
6. Overview freshness - if blueprint/context/project-overview.md is missing or has no blueprint:source-hash, mention that /overview should run before new feature work. Otherwise use /overview's hash contract: exact project-plan bytes, one zero byte, then build-plan bytes with line-start - [x] and - [X] markers normalized to - [ ]. Treat a matching legacy exact-byte hash as current for backward compatibility. Recommend /overview only when the recorded hash matches neither value. Do not use filesystem timestamps; /complete legitimately makes build-plan.md newer when it checks off work.
7. Git - current branch, whether the working tree is clean or has uncommitted changes, roughly how many files changed, last commit subject, and whether the branch is ahead of its remote. If the directory is not a git repo, say so and skip this part rather than failing.
8. Progress drift - flag active spec on main, a spec in progress but no branch matching the configured feature, fix, or rollback prefix, all spec steps checked but not completed, or disagreement between build-plan.md and current-feature.md. With git.landing: "pull-request", an active feature may differ from the next unchecked item because parallel branches can be active. A rollback legitimately targets a checked build-plan item until /complete unchecks it, so do not compare it to the next unchecked feature.
9. Dashboard activity - read blueprint/.state/run.json when it exists. Report the command, mode, status, progress, boundary, and safe resume command. A missing file simply means no activity has been recorded. Invalid activity state is a warning, not a blocker for the underlying workflow; point to /doctor to inspect and offer the approved generated-state reset.

Before choosing the next action, use the read-only candidate screen in the installed Complete skill (../complete/reference/completion-recovery.md). Inspect branch, working-tree changes, live state, relevant archives, and matching local work refs. Route a completion candidate to /complete for full phase proof; do not write Git objects or claim recovery has been verified from Status. On a clean local default branch with consistent live state and no matching work ref or pending completion evidence, the archive is settled history. Continue normal routing without requiring historical transient objects lost in a clone or prune. A reset stub alone does not establish this state. Actual candidates with missing or conflicting evidence need identification/repair before new work.