awb-status

Report workbench status

Run this skill's commands through the awb MCP tools when the host offers them, as the project's AGENTS.md Commands maps them; the command lines below are the fallback.

The status report is read-only: report what the records say, and turn every fix it finds into a next request. Carry out the message's other requests, such as edits, through their own skills after the report.

Collect

Use the user-named project, otherwise the current directory. Run the helper without reading it:

python3 <skill-directory>/scripts/collect_status.py <project-root>

Add --probe-upstream only when the user asks whether landed sources changed upstream.

When workbench is false, stop and suggest awb-init. Treat null, unknown, and each uncertainties entry as a targeted lookup: read only the named record or field. Report missing records as missing. When git.available is false, report its reason with what it means for the user: status cannot tell what is uncommitted or whether the state is out of date, and evidence records file checksums instead of a commit SHA; say whether they must act, such as by installing Git or putting the project in a repository. Leave history, source data, and other investigations' conclusions unread.

Report

Keep the report to one screen, in this order. Report the collector's values without its keys or their question and result IDs, in the investigation's wording shortened, and omit empty items.

• Question and state. active.question and active.last_updated, then git.state_status: for out of date, add latest_change, with days_after_state when above zero; for any other status but up to date and no newer dated change found, run read command stale for the investigation (python3 <project-root>/src/awb.py stale --investigation <name>) and give the status in plain words beside how many checked results it finds current, as "saved the same day as the latest change; evidence checks show 11 of 11 current". Add git.commit_comparison when present. When git.uncommitted_evidence lists results, say in one plain line that they were run before the first commit, so their evidence names no commit until they are rerun. When active.question is a ledger ID, report that question's text and status from its questions.open, questions.awaiting_recheck or questions.provisional entry, falling back to its line from python3 <project-root>/src/awb.py questions list --all. A missing ID or failed lookup leaves the question unsettled; report the uncertainty.
• Findings. active.counts, then each questions.by_question entry, one of the user's questions, by its text with its findings by status, as "Which zones grew fastest: 2 findings, 1 supported", labelling one whose origin is brainstorm, eda, or analysis as added while brainstorming, exploring, or analysing; then findings_without_question as findings no question names. Then every active.findings reason, flagged findings first; while one remains, never say nothing is open. Read a foundation/quality.md correction row only when a caveat cites one that needs explaining.
• Open work. unresolved_issues and next_steps. Report an open decision only when the brief or state records it as one. From questions, lead with roots, the questions the user asked, in the user's terms: how many are answered, answered (awaiting recheck) included, of those not superseded ("Your five questions: 5 of 5 answered"), and how many await recheck, are open, parked, or declined. Count answered (provisional) and answered (provisional, awaiting recheck), an answered data question none of whose answering findings is promoted yet, as provisional, not answered, and list each provisional question by its text. Then must_subquestions, the questions under them the decision needs, the same way. Then each open question grouped by answerer, and each awaiting_recheck entry by its status: an answered data question with at least one flagged or superseded answering finding. The stored status remains answered; even another settled answering finding does not remove the recheck. Report questions.counts, the totals with every sub-question, only on request. A null questions with an uncertainties entry for the ledger means it could not be read: report that entry. Otherwise a null questions means the investigation has no ledger yet; then list material_unknowns as unknowns.
• Other investigations. Each name and last_updated.
• Packages. For each whose draft_stage is set, that stage alone, such as "headline preview written, not yet exported". For each other: revised_at, latest_release with released_at, draft_vs_release, and latest_release_in_storage, whether release storage holds that release: null when release storage is not a reachable path or no release exists, as Storage and latest_release already report; otherwise its null is a targeted lookup. Then what blocks its next release: confirmed_without_disposition, flags the manifest records whose disposition is still none or revalidate; unmatched_flags, flagged findings the manifest does not record with the same finding and reason, which awb-package resolves; and rerun_since_draft, represented results rerun after the draft was last revised, so the package still shows their earlier run.
• Storage. landed_data_storage and release_storage by availability, and acquisitions.without_retained_copy as acquisitions held only in this checkout. unrecorded or unreachable is a risk once acquisitions or releases exist. none chosen is the user's recorded decision: report that this checkout holds the only copy. For unknown, check through the project's established access method or say "not verified".
• Sources. Each sources.documentation_without_reference entry with its reason: a source assessed from documentation whose Notes record no reference in a form foundation/sources.md states; the awb-init skill's references/landing.md (Source references) gives their exact grammar. Report sources.documentation_access_notes and upstream.not_checkable once each, as known limitations, not risks: documentation read but not kept, and sources whose server sends no ETag or Last-Modified, so upstream changes go undetected.
• Upstream, only when probed. Each upstream.files entry whose result is changed as "<path>: upstream changed since acquisition <acquisitionid>", then each `unknown` with its `reason` and no lookup, then the count unchanged. Name `notprobeable files with their reasons and the withoutupstream` count as not checked. A null `probeablefiles` means an acquisition could not be read: name the directories and provenance files under uncertainties as not checked.
• Friction. open_product_friction, if above zero, as workbench problems to share upstream.
• Uncertainties the targeted lookups left unresolved.

You can ask for

Finish with up to five requests whose state applies, risk rows first, then progress. Phrase each as a sentence the user could type, with its handler in parentheses so hosts without a skill menu still route it.