status

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" ]; then
    STATUS=$(grep -m1 "^status:" "$VFILE" | awk '{print $2}')
    if [ "$STATUS" = "gaps_found" ] || [ "$STATUS" = "human_needed" ] || [ "$STATUS" = "partial" ]; then
      echo "DEBT: $(basename "$dir") — $STATUS"
    fi
  fi
done

If ANY phase has outstanding verification (gaps_found, human_needed, partial):

• Display a Verification Debt section in the status dashboard
• List each phase with outstanding items and their status
• This is non-blocking — informational only, but surfaces items that might be forgotten

Step 4: Display Status Dashboard

Present the status in this format:

Project: {name from PROJECT.md or config.json}
Phase: {current} of {total} -- {current phase name}
Progress: [{progress bar}] {percentage}%

Phase Status:
| Phase | Status | Plans | Progress |
|-------|--------|-------|----------|
| 1. {name} | {status indicator} {status text} | {completed}/{total} | {percentage}% |
| 2. {name} | {status indicator} {status text} | {completed}/{total} | {percentage}% |
| ...

**Project documents:**
| File | Status |
|------|--------|
| PROJECT.md | {exists / not found -- run /pbr:new-project} (includes ## Context section) |
| REQUIREMENTS.md | {exists / not found -- run /pbr:new-project} |

{If STATE.md frontmatter contains a `velocity` field (JSON object), display velocity metrics in a single compact line:}
Velocity:  {velocity.plans_executed} plans | avg {velocity.avg_duration_minutes} min/plan | trend: {velocity.trend}
Total:     {total_plans} plans across all phases
{If no `velocity` field exists in STATE.md frontmatter, skip this block entirely — do not show "No metrics".}

{If STATE.md frontmatter contains `session_last`, display session continuity:}
Last session: {session_last}{if session_stopped_at:} — stopped at: {session_stopped_at}{/if}
{If no `session_last` field exists, skip this block entirely.}

{If context tier is DEGRADING, POOR, or CRITICAL:}
⚠ Context: {percentage}% used ({tier}) — {recommendation_text}
  Run `/compact` to reclaim context before spawning more agents.

Where `{recommendation_text}` maps:
- DEGRADING → "quality may degrade on complex agents"
- POOR → "context window is fillin