sb-statuslisted

# 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. ## Gather For the active milestone: ```sh specbind milestone status ``` For one Spec: ```sh specbind spec status <spec> ``` Add these only when the answer needs them: - `specbind tasks list <spec>` when the Spec is implementing and the user needs to see individual tasks, their progress, or which are blocked. - `specbind milestone review status` when the milestone report shows a contract review that is absent, stale, or inva