---
name: sb-status
description: Report where a Spec or active milestone is in its lifecycle and what can happen next. Read-only; do not use to judge whether completed implementation is actually done.
argument-hint: "[spec]"
---

# Report current SpecBind state

## Apply project language style

Before authoring any artifact or user-facing prose, read:

```sh
specbind rule read language-style --for consume
```

Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT`
means no additional project preference; any `ERROR` line stops the workflow.

Answer "where is this work now, and what is the next thing that can happen?"
using the CLI's derived read models. Change nothing.

This is not the answer to "is this completed implementation actually done?"
When every task is complete and the user asks whether a named Spec is done, use
`sb-validate-implementation`; that judgment may record completion evidence
on `GO`.

## Choose the scope

- A named Spec, when the user asks about one, or when only one Spec is under
  discussion.
- The active milestone otherwise, including when the user asks a general
  question such as what to do next.

When the request is ambiguous, report the milestone first: it names the
participating Specs, so the user can narrow from there.

## Follow the selected procedure

- For the active milestone, read [references/milestone.md](references/milestone.md)
  and follow it completely. Do not also load the Spec procedure unless the user
  narrows the request to one Spec.
- For one named Spec, read [references/spec.md](references/spec.md) and follow it
  completely. Do not start from the milestone procedure.

A read that fails is part of the answer. Report the diagnostic rather than
retrying it or working around it, because a command that cannot produce a
trustworthy read is telling the user their project state needs repair.

## Report

Lead with the answer, then the evidence. A user asking for status wants to know
where the work stands, not to read a transcript of commands.

Cover, in the project's language:

- **Where the work is.** The milestone stage or the Spec's lifecycle state, in
  plain terms rather than as an internal identifier.
- **What is not consistent**, if anything. Explain what each diagnostic means
  for the user's work rather than repeating the stable code alone.
- **What can happen next.** The CLI reports actionable items and release
  blockers; turn those into the concrete next step and say who has to take it.

`State health: consistent` means the CLI found no deterministic schema,
lifecycle, freshness, declared-coverage, or other machine-checkable diagnostic.
`Semantic alignment: not evaluated` is equally authoritative: status does not
judge whether Requirements, Design, Contract, Steering, and implementation
prose agree. Never use state health to rule out an artifact contradiction in a
review or diagnosis.

Keep it proportionate. A healthy Spec needs a few lines. A milestone with
blocked items must retain the recorded progress, Task identity, reason, and the
condition that must be resolved before its owning workflow can resume.

## Boundaries

- This skill only reads. It never approves, records progress, edits an artifact,
  or repairs state, even when the fix looks obvious. Offer the next step and let
  the owning skill perform it.
- Report what the CLI derived. Do not infer lifecycle state by reading
  `spec.yaml`, `tasks.yaml`, or the roadmap directly; those projections exist so
  every agent answers the same question the same way.
- Do not present a stale or inconsistent state as healthy. If the report is
  confusing because the project is genuinely inconsistent, say that plainly.