Project Status Artifact
Generate and publish an opinionated, tabbed project status page for work too big for one update — success criteria, a workstream sequence, next steps, risks — then refresh it in place on the same URL, reporting only what changed instead of re-narrating the whole project.
A status update in a chat thread is already stale and buried by the time the third person asks 'wait, where are we on this?' — a living page that redeploys to the same link and reports only the delta solves the problem a Slack message never can.
Who it's for: engineering leads tracking a multi-workstream migration or launch, project managers who want a shareable overview kept current instead of a stale slide deck, teams running a research effort or org initiative with parallel dependent tracks, anyone whose status updates currently get retyped from scratch every check-in
Example
"Give me a status page for the auth migration" → A tabbed page with Overview (success criteria, scope), Workstreams (one row per PR/milestone with status pills), and Risks & Open Questions — published to a shareable, default-private link with a stable title and icon — then, a week later, "refresh the status page" re-gathers live state, redeploys to the same URL, and reports just the delta: two workstreams merged, one new blocker
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add project-status-artifact# Project Status Artifact
Generate and publish an opinionated, tabbed project status page for a project too big for one text update — a migration, a research effort, a launch, an org initiative with several parallel or dependent workstreams tracked over time. Publish it as a shareable web page, then refresh it in place on future check-ins: re-gather live state, redeploy to the same URL, and report only what changed.
Use this when a piece of work spans several workstreams and a shareable, always-current overview is worth more than another status message buried in a thread.
## Workflow
### 1. Locate or Start the Project
Check whether this project already has a published status page from an earlier session. If it does, this is a **refresh** — jump to "Refreshing" below. If not, this is a first build: gather source material — the goal, the set of workstreams (PRs, milestones, sub-projects, tasks), owners, dates, and any sibling docs (a design doc, a plan, a spec) — always pulled live from its actual source (a tracker, a repo, a spreadsheet, project notes), never reconstructed from memory or an earlier conversation turn.
Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Structures a project's status as one opinionated, tabbed page instead of a recurring text update: an Overview tab with success criteria and scope, a Workstreams tab that's always present (one row per PR, milestone, or sub-project with a status pill and the current state at a glance), and optional tabs — Attention, Background, Plan, Risks & Open Questions, Decisions/FAQ — that only appear when there's genuinely substantive content for them. The page is self-contained, light/dark aware, and published to a shareable, default-private link.
The part that makes it worth building over a plain status doc is the refresh discipline: every later "refresh the status page" re-gathers live state, reads the previous render's embedded state block to know what's already there, edits it in place rather than regenerating from scratch, redeploys to the same URL, and reports only the delta — merged items, status flips, new blockers — instead of re-narrating the whole project every time. A failed data fetch marks the affected rows stale rather than inventing a plausible-looking update, and every fetched third-party text (an issue body, a comment) is treated as data to summarize, never as instructions to follow.
Quick Start
Step 1: Create a Project Folder
mkdir project-status && cd project-status
Step 2: Download the Template
Click Download above, then:
mv ~/Downloads/CLAUDE.md ./
Step 3: Build the Status Page
claude
Describe the project — its goal, its workstreams, where live state lives (a repo, a tracker, a doc) — and ask Claude to build a status page. On future check-ins, just say "refresh the status page" and it will re-gather, update the same page in place, and report the delta.
Tips & Best Practices
- Resist adding a tab "just in case." An empty or thin tab is worse than no tab — readers learn to skip a page that wastes their clicks.
- The status banner and next-steps strip at the very top are what most readers actually consume — get those two exactly right even when the deeper tabs are rougher.
- On a refresh, edit the previous render in place rather than regenerating it from a blank template — that's what keeps the page's voice consistent across many refreshes over a project's lifetime.
Limitations
- Depends on a runtime capable of publishing a self-contained HTML page to a stable, shareable URL — without that, this produces a well-structured status document but not a live, redeployable page.
- Designed for a project with genuine parallel or dependent workstreams tracked over time — a single-PR change or a short-lived task doesn't need this much structure.
- The delta-reporting discipline only works if the previous render's location is actually recorded — losing that turns every "refresh" back into an unintended first build.