/status

name: status
description: "Show current project status and suggest what to do next."
allowed-tools: Read, Glob, Grep, Bash, AskUserQuestion
argument-hint: "[--json]"

**STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.**

Step 0 — Immediate Output

**Before ANY tool calls**, display this banner:

╔══════════════════════════════════════════════════════════════╗
║  PLAN-BUILD-RUN ► PROJECT STATUS                             ║
╚══════════════════════════════════════════════════════════════╝

Then proceed to Step 1.

/pbr:progress — Project Status Dashboard

You are running the **status** skill. Your job is to read the project state and present a clear, actionable status dashboard. You suggest the most logical next action based on where the project is.

This skill runs **inline** and is **read-only** — it never modifies any files.

References

• `references/questioning.md` — Questioning philosophy (for routing intelligence)
• `references/ui-brand.md` — Status symbols, banners, progress display format

---

Core Principle

**Show the user where they are and what to do next.** The status display should be a quick glance, not a wall of text. Surface problems and route to the right action.

---

Flow

Step 1: Read Project State

**CRITICAL — STOP. You MUST run these CLI commands FIRST. Do NOT skip them. Do NOT read files manually instead.**

First, run the init command to capture routing, drift, and metadata:

node plugins/pbr/scripts/pbr-tools.js init status

Store the JSON result as `blob`. This provides:

• `blob.routing` — suggestNext output with `blob.routing.command` and `blob.routing.reason` for Step 5 smart routing
• `blob.drift` — STATE.md discrepancy warnings (`blob.drift.drift_detected`, `blob.drift.stale_fields`)
• `blob.counts.pending_todos`, `blob.counts.notes`, `blob.counts.active_debug` — directory scan counts
• `blob.has_paused_work` — whether .continue-here file exists
• `blob.progress` — progress bar data (percentage, completed_plans, total_plans)
• `blob.state` — STATE.md frontmatter fields
• `blob.config.mode`, `blob.config.features`, `blob.config.workflow` — config checks

If `blob.error` is set, display the error banner and stop (no project found).

Then run the status render CLI for the full formatted dashboard:

pbr-tools status render

This returns a **complete, deterministic JSON object** with ALL project status: milestones, phases, progress bar, routing recommendations, todos, notes, quick tasks, paused work, documents, and warnings. Parse the JSON and proceed directly to Step 4 (Display) using the structured data. The init blob supplements this with routing and metadata that `status render` does not provide.

**If the CLI command fails** (non-zero exit or invalid JSON), display:

╔══════════════════════════════════════════════════════════════╗
║  ERROR                                                       ║
╚══════════════════════════════════════════════════════════════╝

Failed to render status dashboard. Run `pbr-tools status render` manually to diagnose.

Stop execution — do NOT attempt manual file reads as fallback.

Step 1b: Read Context Budget (advisory — skip on any error)

Run:

pbr-tools context-triage

Parse the JSON response. Capture:

• `tier` — one of PEAK / GOOD / DEGRADING / POOR / CRITICAL
• `percentage` — numeric 0-100 (or null if unavailable)
• `recommendation` — PROCEED / CHECKPOINT / COMPACT

Store these for use in Step 4 display and Step 5 routing.

**Steps 2-2b:** The `status render` CLI output includes phase statuses, plan counts, progress percentage, and STATE.md discrepancy warnings. Parse the JSON directly — do NOT re-scan the filesystem.

Step 3: Check for Special Conditions

Use blob fields from the init call where available to avoid redundant filesystem scans:

Paused Work

• Check `blob.has_paused_work` — if true, note that paused work exists
• If more detail is needed, search for `.continue-here.md` files in `.planning/phases/`

Verification Gaps

• Search for `VERIFICATION.md` files with `gaps_found` status
• If found: note which phases have gaps

Active Debug Sessions

• Use `blob.counts.active_debug` for the count of active debug sessions
• If count > 0: note active debug sessions

Pending Todos

• Use `blob.counts.pending_todos` for the count of pending todo files
• If count > 0: summarize

Critical Path

Identify the single next-blocking item — the one phase or plan whose completion unblocks the most downstream work.

Logic: 1. From ROADMAP.md dependency graph, find all phases that are NOT yet verified. 2. For each unverified phase, count how many other unverified phases list it in `depends_on` (direct + transitive). 3. The phase with the highest downstream dependent count is the critical-path phase. 4. If all unverified phases are independent (no dependencies between them), the critical path is the current phase from STATE.md. 5. Within the critical-path phase, the critical-path plan is the lowest-numbered plan without a SUMMARY.md.

Store: `criticalPhase` (number + name), `criticalPlan` (plan ID or null if phase not yet planned), `criticalCount` (number of downstream phases blocked).

Quick Notes

• Use `blob.counts.notes` for the total count of note files in `.planning/notes/`
• For promoted status filtering, read individual note frontmatter only if needed
• Also check `~/.claude/notes/` for global notes

Quick Tasks

• Check `.planning/quick/` for recent quick tasks
• Note any failed or partial quick tasks

Verification Debt Scan

Scan ALL completed phases (not just current) for outstanding verification items:

for dir in .planning/phases/*/; do
  VFILE=$(ls "$dir"VERIFICATION*.md 2>/dev/null | head -1)
  if [ -n "$VFILE" ]; th