/stardust

name: stardust
description: Guided multi-page redesign of an existing website through a four-phase pipeline — extract (crawl and capture the current site), direct (set a visual direction), prototype (generate redesigned HTML), and migrate (emit a deployable static site). Tracks progress incrementally per page in stardust/state.json so redesigns are resumable. Delegates the per-page design craft (typography, spacing, color, layout, motion) to the impeccable skill. Use when the user wants to redesign, revamp, modernize, or restyle an existing site they can point to by URL, run the extract/direct/prototype/migrate flow, or resume a multi-page redesign or migration. Also routes the same-design migration flow (replica) and the donor-design flow (reskin). Not for designing a brand-new site from scratch or one-off single-component edits.
license: Apache-2.0
compatibility: Requires Node 22+, Playwright with Chromium resolvable from the project, playwright-cli on PATH, and the impeccable skill (github.com/pbakaus/impeccable) installed alongside stardust.

stardust

You are operating the `stardust` skill: a guided redesign of an existing website. The user's job is to say what they want; your job is to reason about what that means, propose a plan, and execute it through a small set of sub-commands that delegate the actual design work to **impeccable**.

Setup (run before anything else)

1. **Verify impeccable is installed.** Stardust has a hard dependency on impeccable and ships no fallbacks. Look for the `impeccable` skill wherever the harness installs skills or plugins: the skill list the harness exposes to you, project skill directories (`.claude/skills/`, `.agents/skills/`, `.cursor/skills/`, `.github/skills/`), or the harness's plugin cache (Claude Code: `~/.claude/plugins/cache/`; GitHub Copilot: `~/.copilot/installed-plugins/*/impeccable/skills/impeccable`). If it is not installed, stop and tell the user: > Stardust requires impeccable. Install it from > <https://github.com/pbakaus/impeccable> and re-run the command.

**Version hint (advisory, never blocking).** Stardust deliberately pins NO impeccable version — the design craft should always be the current one — and harnesses do not announce third-party plugin updates by default (Claude Code's marketplace auto-update is off for third-party marketplaces such as impeccable's; Copilot has no update notice). So, once per session, run `node <plugin>/skills/stardust/scripts/impeccable-version-check.mjs` (add `--local <impeccable-dir>` when impeccable lives in a harness skills directory rather than the plugin registry) and surface its one output line to the user verbatim when it reports a newer version; it prints the update command for the harness it found impeccable in. Any other outcome (current, unknown, offline) is noise — do not mention it, and never stop or degrade a run over it. The same script with `--where` prints impeccable's skill directory (the one holding its `SKILL.md` and `reference/`); note it once — the phases that read impeccable's format specs (`reference/init.md`, `reference/document.md`) read them from there by section, never after a filesystem search. 2. **Check the target-state files.** `PRODUCT.md` and `DESIGN.md` at the project root are the *target* state for stardust; check whether they exist (a directory listing is enough). Do not run impeccable's context loader (`scripts/impeccable context`) here: it emits directives for impeccable's own flow (init, new-work, detector, update checks) that do not apply to stardust's setup, and impeccable runs it itself whenever stardust invokes an impeccable command. Skip if already known from this session's history. 3. **Read stardust's state.** Read `stardust/state.json` if present (`reference/state-machine.md` defines the schema). Note which pages are `extracted`, `directed`, `prototyped`, `approved`, or `migrated`. 4. **Read impeccable's command registry.** Parse `<harness>/skills/impeccable/scripts/command-metadata.json`. This is the single source of truth for the 24 impeccable commands; never hardcode them in your reasoning. 5. **Status ledger.** Every stardust skill appends a phase-transition line to `stardust/status.jsonl` at each phase start/end, per `reference/run-status.md` — written with `skills/stardust/scripts/ledger.mjs <skill> <phase> <start|end|blocked> [--detail …]` (it knows each skill's phase names and warns on an unknown one; `--strict` refuses it), never with a hand-built `printf`. Page status moves with `skills/stardust/scripts/state.mjs advance <slug…> --to <status>`; a resuming agent orients with `ledger.mjs tail` and `state.mjs summary`. 6. **Project hygiene** (idempotent). Write `stardust/.gitignore` from `reference/stardust.gitignore` if absent; never edit a project's copy. In a git repo: root `.gitignore` covers `.env` / `.env.*` (managed `# >>> stardust` block), `.hlxignore` if present lists `stardust/`, and `git check-ignore -q stardust/state.json` must fail — if it passes, stop and name the rule. Offer, never write, LFS above 50 MB of tracked binaries under `stardust/`. Details in `reference/artifact-map.md` § Versioning.

Routing

Once setup is done, route on the user's input:

• **No argument.** Render the **state report** described in

`reference/state-machine.md`: project state, per-page status table, recommended next command, with reasoning. Do not write anything. The same applies to any **resume**: a new session on a project that has `stardust/state.json`, "continue", "where are we", or a resume driven by a memory file. Start with the state report (it names the flow and the last gate numbers), then enter the next phase **through its skill** — the procedure drives, not memory. (Recorded: a 144-hour resume session invoked no stardust skill at all, re-read the procedu