---
name: tp-status
description: "Use when the user asks where things stand with taskplane-governed work: 'status', 'where are we', 'what's the state of the loop/track/requirements/debt'. Read-only snapshot rendered as the inline mission-control dashboard: active track, loop step, tasks, open requirements, tracked debt, KB size, dependency graph — with an explicit action banner (gate buttons if a decision is yours, 'no action needed' if agents are working)."
---

# /tp-status — where the governed work stands

`TP=python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/taskplane/tp.py"`. Gather compactly
(skip empty sections):

- `$TP summary` — the user-facing headline, human decision, progress, graph,
  and enforcement assurance. Use this as the primary read model.
- `$TP context` — the one-screen summary (track, loop, reqs, debt, graph, KB)
- `$TP loop status` — step, per-task status + fix cycles, checkpoints
- `$TP track list` — all tracks + which is active
- `$TP req list` — requirements incl. open debt items
- `$TP status` — the active contract, if any (who's governed right now)

**Present it as the dashboard, not a wall of JSON.**

1. TEXT first, three lines max: what's running, what state it's truly in,
   and — most important — **whether anything is waiting on the human**.
   If the loop's book lags reality (e.g. a custom flow like an A/B
   selection gate, or an agent that couldn't record its gate), SAY SO and
   name the real pending action; the dashboard renders the recorded state.
2. Then `$TP dashboard` — it prints a `HEADLINE:` line first (relay it as
   plain text — the never-skippable carrier of step + gate, so status lands
   even if the render is skipped), then the fragment. Show the fragment
   inline via `mcp__visualize__show_widget` when available as the LAST thing
   in the reply; otherwise link `.taskplane/dashboard.html` as the final
   dashboard artifact.
   Title: `taskplane_status_<step-or-context>` — UNIQUE per render; a
   repeated title updates the earlier widget in place instead of drawing a
   new one where the user is looking. (For an unusually large board,
   `$TP dashboard --paged` returns ordered ≤14 KB pages — render each in
   order, same contract as tp-engineering findings.) The dashboard carries an **action banner** at
   the top of the loop tab: gate buttons (approve / sign-off / resolve,
   wired to `sendPrompt`) when a decision is the human's, an explicit
   "no action needed from you — <role> is on <step> · next human gate: X"
   strip when agents are working, and a retro button at done. Their click
   IS the proceed — no command to remember.
3. Two v2.5 surfaces to get right — relay them where they actually are,
   never invent them where they are not:
   - **Component surfaces (know which board shows what):** the dashboard's
     Graph tab is MODULE-level only — modules / internal edges / external
     deps, the most-connected hubs, and the blast radius of the current
     tasks' scope. It does not draw component nodes; never say it does.
     On a decomposed graph (`tp graph scan --decompose`) two component
     surfaces do appear: the review dashboard's graph line gains a
     "N components (decomposed)" count, and the coverage map marks routed
     lenses with their component attribution (which component(s) proposed
     them). The drawn component layer — a node per component ringed around
     its owning module — is in the standalone `tp graph html` map, not the
     dashboard; point the user there when they want to see it. Graph with
     no `components` → module-level everywhere, say so.
   - **Coverage map v2:** review status dispositions EVERY catalog lens as
     deep · light · n/a, each n/a only with its stated negative evidence
     (e.g. "0 i18n markers in the diff"); the HEADLINE carries the coverage
     counts (deep/light/n-a). A bare, unevidenced n/a is a blocker to report,
     not a formatting nit.

Never mutate anything from this skill — status reads and renders only.