teamcraft:project-status

---
name: teamcraft:project-status
description: Generate a visual project status dashboard from work items and git history. Shows work by status, what's in progress, cycle times, backlog priorities, and aging alerts. Use when the user says 'project status', 'show me the project status dashboard', 'show me the work item dashboard', 'what's the status of the work items', or 'generate a status report'.
argument-hint: "(no arguments)"
disable-model-invocation: false
user-invocable: true
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
---

## Goal

Generate a concise, visual project status report from the work items in `.teamcraft/work/` and recent git history. The output is markdown with Mermaid charts — readable in the terminal, renderable in GitHub, VS Code, and Cowork. No files are written. This is a read-only snapshot.

Read `references/example-status-report.md` first. It shows a complete report with every section populated, including how to adapt when data is sparse. Use it as your quality bar.

## What to Gather

**1. Read the work items.** Read `.teamcraft/work/INDEX.md` for the overview. Then read individual work item files to get dates (`created`, `started`, `completed`) and effort estimates. If INDEX.md doesn't exist or is empty, say so — there's nothing to report on yet, and point the developer to `/create-issue`.

**2. Compute metrics from the data you have:**
- **Counts by status** — how many items in each status (backlog, ready, in-progress, in-review, done)
- **In-progress details** — which items, their priority, when they started, how many days elapsed
- **Aging alerts** — any item in-progress or in-review for longer than its effort estimate suggests is reasonable (small: >2 days, medium: >5 days, large: >10 days, xl: >15 days). If no effort is set, flag anything over 5 days.
- **Blocked items** — any item in `backlog`, `ready`, `in-progress`, or `in-review` whose `relationships.blocked_by` includes an ID whose own status is not yet `done`. Show the blocked item, the blocker(s), and the blocker's status. Also flag blockers that don't exist on disk (probable stale references). Items blocked >7 days deserve a callout — the dependency may have stalled.
- **Recently completed** — items with a `completed` date in the last 30 days, with cycle time (completed minus started)
- **Backlog priority distribution** — count of backlog items by priority, with the top item in each tier
- **Throughput** — items completed per week over the last 4 weeks (if enough data exists)

**3. Check git activity.** Run `git log --oneline --since="2 weeks ago"` to get a sense of recent commit activity. This adds context — a project with 2 items in-progress and 50 commits is healthy; 2 items in-progress and 0 commits might not be.

## What to Present

Generate a markdown report with these sections. Use Mermaid charts where they add clarity — a pie chart for status distribution, nothing else unless the data warrants it. Don't force charts onto small data sets.

### Report Structure

```
# Project Status — YYYY-MM-DD

## At a Glance
[Table: status | count]
[Row showing count of currently-blocked items if any exist]
[Mermaid pie chart if there are 5+ total items]

## In Progress
[Table: item | priority | started | days elapsed]
[Aging alerts if any items are aging]

## Blocked
[Table: item | priority | blocked by | blocker status | days blocked]
[Callout for items blocked >7 days, or with non-existent blocker IDs]

## Recently Completed
[Table: item | cycle time | completed date]
[Average cycle time if 3+ items completed]

## Backlog
[Table: priority | count | top item in each tier]
[Call out any critical-priority items explicitly]

## Activity
[Commit count last 2 weeks, brief summary of what areas were active]
```

Skip the **Blocked** section entirely if no items are blocked. Don't fabricate an empty section just because the structure lists it.

Adapt the report to what data exists. If there are no completed items, skip that section — don't show an empty table. If the backlog is empty, say so. If there are only 2 items total, skip the pie chart — it adds nothing.

## Constraints

- **Read-only.** Do not modify any files. Do not update work items. Do not commit anything.
- **No speculation.** Report what the data shows. Don't infer why something is aging or predict when it will finish.
- **Keep it scannable.** A dev or tech lead should get the picture in 30 seconds. Tables over prose. Numbers over adjectives.