codingthefuturewithai/teamcraft:project-status

Goal

Give the developer project status in the form that actually fits the moment. There are two, and they answer different needs — so this skill offers the choice instead of assuming:

• A quick read, here in the session. Read the work items in .teamcraft/work/ and recent git history, and give a tight, interpreted snapshot: not just the counts, but what they mean — whether an aging item is a real stall or a deliberate gate, and how commit activity lines up with item movement. This costs a little time and tokens each run, but it's portable (drop it into a standup, a retro, a PR) and it's the only path that can correlate git with the board. It's a point-in-time snapshot; no files are written.

• The live dashboard. The work board carries a Status tab — the developer runs /work-board, then clicks Status. It renders the same metrics (work by status, throughput, cycle time, aging, blocked chains) live from .teamcraft/work/, recomputing on its own with zero tokens, and they bookmark it once. It can't show git activity (a browser has no shell), but as the always-on "how are we doing right now" surface, it's the better daily driver.

So start by reading intent, not by generating. If the phrasing already picks a lane — "quick status", "just tell me" → the in-session read; "open the dashboard", "show me visually", "I want to keep it up" → point them at the work board's Status tab — go straight there. If it's ambiguous, offer both in one line and let them choose. Don't silently run the full in-session report just because the skill was invoked; that's the token cost the developer should get to opt into.

When you give the in-session read, references/example-status-report.md is the quality bar — a complete report with every section populated, plus how to adapt when data is sparse. The tables and numbers matter, but the callouts and the git correlation are what make the in-session read worth choosing over the dashboard — lead with the interpretation, not just the tables.

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.
• Ground interpretation in the data; don't guess at causes. Distinguishing what the data shows is the value — a blocker that's itself still open is a real dependency gate; an in-progress item with no recent commits in the git log may have stalled. That's reading evidence, not speculating. What to avoid is inventing reasons you can't see ("probably busy with other work") or predicting completion dates.
• Picking what's next isn't this skill's job. Reporting that something is blocked, aging, or that nothing's in flight is status. Recommending which work item to start next belongs to pick-next-issue — point the developer there rather than choosing for them.
• Keep it scannable. A dev or tech lead should get the picture in 30 seconds. Tables over prose, numbers over adjectives — but lead the read with the one or two things that actually need attention.