Project Status Dashboard

Project Status Dashboard

Produce a read-only snapshot of the current repository. Do not edit files.

When To Use

Use this when the user asks for status, a health check, a catch-up, current state, dashboard, or what is going on in a repo.

Do not use this for cleanup edits; use project-docs-cleanup. Do not use it for scaffold readiness; use repo-workflow-checker.

Workflow

1. Load lightweight project context:
   • AGENTS.md, CLAUDE.md, or equivalent repo instructions when present.
   • README.md, backlog files, bug trackers, specs, plans, and release notes when present.
2. Inspect git state:
   • Current branch.
   • Working tree status.
   • Recent commits.
   • Upstream drift when a remote exists.
3. Inspect work queues:
   • Backlog, bugs, specs, TODO docs, issue exports, or local planning files.
   • Stale or contradictory status notes.
4. Inspect verification hints:
   • Package scripts, Makefile targets, CI workflow names, test folders, and recent local logs if available.
5. Return a concise dashboard.

For sample prompts and dashboard outputs, see references/examples.md. For a ready-to-fill dashboard template, see references/dashboard-template.md.

Input Signals

Prefer cheap, read-only signals: git status, recent commits, current branch, remotes, README, agent instructions, active specs, backlog files, test scripts, CI workflow names, and local log files the user points to.

Output

Use this structure:

• Now: the most important current state in one or two sentences.
• Branch: current branch, dirty files, upstream drift if known.
• Open Work: active specs, backlog items, bugs, or PR-prep items.
• Verification: likely test/build commands and whether anything has recently run.
• Risks: stale docs, unclear state, broken workflow clues, or missing checks.
• Next Move: the smallest useful next action.

Guardrails

• Never mark work as verified without evidence.
• Never treat docs as source of truth when code or git evidence contradicts them.
• If data is missing, say what is unknown instead of guessing.
• Do not run long or destructive commands.

Avoid

• Do not turn the dashboard into a cleanup plan unless the user asks.
• Do not imply CI, tests, or deploys passed unless you observed that result.
• Do not run network or heavyweight commands just to fill a nice-looking dashboard.

Final Checks

• The dashboard is read-only and does not propose broad refactors.
• Verification distinguishes likely commands from commands actually run.
• Unknowns are labeled clearly.
• The next move is small and immediately actionable.