/status-truth

name: status-truth
description: Use when work is leaving the desk — findings, a status, or a number that must hold up in the room. The state of the WORK itself is being reported - a status report or weekly/steering update - and the truth must survive the pull to look green: every claim carries provenance, every green names what would turn it red, slipped is slipped with the delta, risks stay open until their owner closes them, verdicts travel with their age. Detects: "status report", "weekly update for steering", "are we on track", "RAG status". Within this family: analysis FINDINGS are brief-my-findings; rehearsing under attack is defend-my-number. Boundary: auditing the record is kb-reconcile. Never invents progress; never recolors to please the room.
allowed-tools: Read, Write

status-truth

The program lead's conscience at reporting time: composes the status from the record and what you can actually attribute, keeps the reds red, and makes every green earn its color.

When to use

Fire when the deliverable is the **state of the work** — a status report, a weekly/steering/sponsor update, "are we on track," a RAG slide's content. Works from a `knowledge-base/` when one exists and from your attributed answers when it doesn't. Do NOT fire to communicate what the analysis FOUND (`brief-my-findings`), to audit whether the record itself is still true (`kb-reconcile`), to catch YOURSELF up after time away (`groundwork` resume), or to rehearse defending a number (`defend-my-number`). This reports delivery state to others; it does not analyze, audit, or rehearse.

The trap this exists to beat

Asked for "a tight, positive update for leadership," a capable model produces a confident green — and that is the failure. It **green-washes**: re-words a slipped milestone as "progressing" (or silently re-bases the plan so nothing ever slips), lets a blocker age out of the narrative, closes risks nobody closed, launders an expired or overridden verdict clean, rounds 60% to "nearly done," and books other teams' unconfirmed promises as progress. Watermelon status — green outside, red inside — reads fine every week until the week it detonates in a steering meeting. This skill composes the same update, but every claim has a source, every green has a stated red-condition, and the pressure to look good is recorded, not obeyed.

The loop

1. **Warm start + harvest the record.** If a `knowledge-base/` exists, read `timeline.md` (what actually happened, `by:` whom), `open-questions.md` (ages and owners of opens), `decisions.md` (incl. OVERRIDE entries), the artifact verdicts (`*-audit.md`, `query-review.md`, `defense-sheet.md` — each with its date and `Re-audit when:` condition), and `catches.md` (what the harness stopped this period). Honor `house-rules.md`. 2. **Elicit this period's updates — with attribution.** What moved, what slipped, what's blocked, what's risky — each item carries who reported it (`by:`). An update you can't attribute is `Unknown — asked`, never assumed. Never fabricate a stakeholder's or another team's progress. 3. **Build the status ledger (the engine — `references/status-engine.md`).** Every line: claim · source · status — **Done (evidenced)** / **In-progress (attributed)** / **Slipped (delta stated; a re-base is named as a re-base)** / **Blocked (age + owner)** / **Risk (open until its owner closes it)** / **Unknown — asked**. Carried verdicts travel with their age: a verdict whose `Re-audit when:` condition has been met is **expired** — it routes back to its audit, it is not reported as standing; an overridden gate rides visibly ("shipped over an open Blocking — owner, date"). 4. **Color it honestly.** RAG only against pinned criteria (from `house-rules.md` or stated in the report). The **watermelon test**: if any ledger line inside is red, the outside cannot be green — it is amber-or-red with the line named. A green names what would turn it red by next period. 5. **Compose `status-report.md`** (template: `references/status-report.md`) — period, audience, RAG + criteria, the ledger, next-period commitments (owner-attributed), and the asks. A pressure instruction ("keep it positive") is met with the honest version plus a recorded note of the ask. 6. **Emit + thread.** Append newly surfaced blockers/risks to `open-questions.md` (with owner + age), append `timeline.md`, offer the `kb(status-truth): <period> status — <RAG>` commit. Then stop.

The signature output: the provenance-graded status

A status report where every line answers "says who, as of when" — the analog of `brief-my-findings`' claim ledger, pointed at delivery state instead of findings. A polished update reads well; this one survives the follow-up question. Engine, taxonomy, and a worked example live in `references/status-engine.md`.

Bright lines (non-negotiable; inherits groundwork's read-only line)

• **Never invent or upgrade progress.** No status without a source; "should be done soon" is In-progress (attributed), not Done. Percent-done theater is the disease, not a style.
• **A slip is a slip.** State the delta against the last reported plan; a re-base is reported AS a re-base, never as on-track-by-definition.
• **Risks and blockers close only by their owner.** Quietly dropping an aging item is the green-wash; age is part of the status.
• **Carried verdicts keep their age and their qualifiers.** Expired → route to re-audit, don't report it standing; overridden → visible, never cleaned.
• **Pressure is data.** "Make it green / keep it positive" gets the honest report plus the recorded ask — never a recolored one.
• **Write boundary (bench invariant):** writes only inside `knowledge-base/` and `inputs/` (creating them if absent), plus the root `AGENTS.md` pointer — never anywhere else.
• **Data handling (bench invariant):** the record carries conclusions, definitions, and aggregates — never row-level or personal data. Flag person-level content in handed evidence before it enters `inputs/` (redact,