project-artifact

# project-artifact — an opinionated project status page

This skill produces one specific *kind* of artifact: a tabbed status page that represents a
project too big for one update — a software migration, a research effort, a launch, an org
initiative; anything with a set of parallel/dependent workstreams tracked over time. It
generates the HTML (one file, self-contained — the Artifact CSP blocks all external hosts,
so everything is inlined; the only `<script>` is the tab switcher) and publishes it with
the built-in `Artifact` tool to `https://claude.ai/code/artifact/<uuid>`. The page is
default-private; the viewer gives the owner a version picker and lets them share it with
teammates. (The general "render any HTML/Markdown to a web page" capability is the built-in
`Artifact` tool; this is the project-tracker structure on top — defining what an artifact
*is* belongs to that tool, not here.)

The SWE specifics for PR-driven projects are in `swe.md`, kept out of this file so the
project-artifact structure stays domain-neutral.

## Workflow

1. **Resolve the artifact config, then locate the project.** Each project gets a directory
   at `${CLAUDE_PLUGIN_DATA}/artifacts/<slug>/` holding `config.md` (see **"The artifact
   config"** below) and `page.html` (the current render); listing `artifacts/` is the
   registry of this skill's artifacts on this machine. If the
   user names a project,
   load that slug; if exactly one config matches the session (its repo is the cwd, or its
   project came up in conversation), use it; a config that exists means this is a
   **refresh** — follow **"Refreshing an artifact"** below. No config means a first build:
   gather from scratch and write the config after the first publish — but if the user says
   the project already has a published artifact (made on another machine or in a lost
   session), get that URL and record it instead of minting a new one.
   Then collect the source material: the goal, the set of workstreams (PRs, milestones,
   sub-projects, tasks), owners, dates, and any sibling docs (design doc, plan, spec).
   Pull whatever the domain gives you cheaply — always live, never from memory or earlier
   turns — for software that's `gh pr list` / `git log` / `gh pr view` (see `swe.md`); for
   other domains it's the project doc, a tracker, a spreadsheet, your own notes. If the
   source is itself an existing `claude.ai/code/artifact/...` page to reshape, fetch it —
   see **"Reading an existing artifact page"** below. Don't ask the user to paste content or hand you a local file
   as a substitute for fetching it yourself.

2. **Pick the tabs** from the catalog below — only the ones with real content.
   **Overview** and the **Workstreams** sequence are the spine and are essentially always
   there; **Attention**, **Background**, **Plan**, **Risks & open questions**, and
   **Decisions/FAQ** each earn a tab only when there's something substantive to put in it
   (a simple, self-explanatory project may have just Overview + Workstreams; a big one ~6–8). Never
   ship an empty tab. If this is a software project, `swe.md` notes the extra tabs a
   rigorous one tends to want — none of them mandatory.

3. **Generate the HTML** from `template.html` in this skill directory (same folder as this
   SKILL.md): it already has the house style (light/dark via `prefers-color-scheme`, CSS
   variables), the header, the status banner, the next-steps strip, both tab mechanisms
   (JS-toggled panes as the default; pure-CSS radio tabs as a no-JS alternative), the
   status-pill classes, and a stub `<section>` per catalog tab with fill-in comments. Fill the stubs, delete unused
   tabs, keep it one file. **Set a concise `<title>`** — the Artifact tool uses it as the
   page's name in the browser tab and the claude.ai gallery, and falls back to the file
   basename without one; keep it stable across redeploys. **Write the file to the config's
   `html` path** — default `${CLAUDE_PLUGIN_DATA}/artifacts/<slug>/page.html`, next to the
   config (not `/tmp`; not inside the user's repo unless they ask — if they do, use
   `<repo>/.claude/project-artifact/<slug>.html` and record it as the config's `html` path):
   a stable path means the Artifact tool redeploys to the same URL within a session, and
   the previous render stays around for the next refresh's delta. **Embed the state
   block** (see "Refreshing an artifact") so the next run can compute what changed.

4. **Review the output for cut-off text and overflow.** Before publishing, re-read the
   file and check that nothing gets clipped or truncated: fixed-width table columns
   squeezing their contents, long unbroken strings (URLs, PR/branch names, IDs) overflowing
   their container, anything sitting behind `overflow:hidden` or `white-space:nowrap`. The
   viewport is unknown (could be a phone): wide content — tables, diagrams, code blocks —
   must scroll inside its own `overflow-x:auto` container, never the page body. After
   publishing, open the page and eyeball it — if anything is clipped, wrap or shorten it
   (`word-break`, a smaller font, a shorter label) and redeploy.

5. **Publish with the Artifact tool.** Call `Artifact` with `file_path` = the HTML,
   `favicon` = one or two emoji that fit the project (keep the same emoji on every
   redeploy — viewers find their tab by it), `label` = a short version tag (e.g.
   "phase 1 cut" or the date — shows in the version picker), and — on a refresh — `url` =
   the config's recorded artifact URL so the redeploy lands on the same address. The tool
   returns the `https://claude.ai/code/artifact/<uuid>` URL; the slug is server-minted,
   not chosen.

6. **Share it.** First publish is **private to the user** — teammates can't open it (they
   get a 404) until the user shares it. Tell the user to open the artifact on claude.ai
   and share it with their teammates from the viewer; redeploys preserve the sharing
   setting.

7. **(Optional) Register on a hub.** If the u