| name | screenshot |
| description | Regenerate real product screenshots — either CLI screenshots (actual `basilisk check` output rendered in a Terminal window) or VS Code editor screenshots (the extension showing diagnostics, hover, quick-fix, activity panel). Use when the user asks to regenerate, update, or add marketing/docs screenshots. Requires a target argument, `cli` or `vsix`. |
| argument-hint | cli|vsix [cli-shot-names...] |
| arguments | target |
| allowed-tools | Bash(npm run *), Bash(node screenshots/*), Bash(cargo build *) |
Regenerate product screenshots
Screenshots must be real output of the actual binary/extension, never hand-typed code fences or synthetic renders (those drift and mislead). Both suites write to the canonical location website/src/assets/images/ and are committed; CI only verifies they render (website/tests/e2e/screenshots.spec.ts), never captures, per [GITHUB-NO-ARTIFACTS].
Step 1 — Resolve the target
The target is $target ($ARGUMENTS).
cli → CLI screenshots. Go to Step 2a.vsix (or vscode) → VS Code editor screenshots. Go to Step 2b.- Empty or anything else → STOP and ask the user which target they want:
cli or vsix. Do not guess — the two paths capture different images with different tooling.
Step 2a — CLI screenshots
Real basilisk check --color always output rendered in a faithful macOS Terminal window via Playwright. See [WEBSITE-SCREENSHOTS] (docs/specs/WEBSITE-SCREENSHOTS-SPEC.md).
Images: rule shots e0001.png…e0025.png (named after the code), plus the homepage pair cli-demo.png (errors) + cli-clean.png (pass). Snippet→expected-code pairings live in website/screenshots/shots.mjs; generate.mjs asserts the documented diagnostic actually fires, so a checker change can't silently ship a misleading image.
From website/:
npm run screenshots
node screenshots/generate.mjs e0001 e0012
BASILISK_BIN=../target/release/basilisk npm run screenshots
If the user passed extra args after cli (e.g. e0001 e0012), pass them through to node screenshots/generate.mjs <names> to regenerate only those. Otherwise regenerate all.
To add or change a shot, edit website/screenshots/shots.mjs (snippet + expected code) and rerun — never craft images by hand. After regenerating, run npm run build and confirm the images copied to website/_site/assets/images/.
Step 2b — VS Code editor screenshots
Headed VS Code capture of the running extension (diagnostics, hover, quick-fix, activity panel) via a dependency-free CDP sidecar (vscode-extension/screenshot-watcher.mjs). See [VSIX-EDITOR-SCREENSHOTS] (docs/specs/VSIX-EDITOR-SCREENSHOTS-SPEC.md).
Images: vscode-*.png in website/src/assets/images/.
The suite is a no-op without the BASILISK_SCREENSHOTS=1 flag (which npm run screenshots:editor sets), so normal npm test never opens these windows.
First build the binaries the extension stages, then run the suite. From vscode-extension/:
cargo build -p basilisk-cli -p basilisk-profiler-helper
npm run screenshots:editor
screenshots:editor stages the freshly built binary into the dev extension, copies shipwright.json, launches the headed "Editor screenshots" suite, and the sidecar captures each window to website/src/assets/images/vscode-*.png.
To add an editor screenshot, add a test(...) that makes the feature visible and calls takeWindowScreenshot(...), then rerun.
⚠️ Never kill a VS Code process (per CLAUDE.md) — it disrupts active debugging/test sessions. Let the headed suite open and close its own windows.
Step 3 — Report
Report exactly which images were regenerated and their paths. If a run asserted a diagnostic and it failed to fire, surface that failure — do not commit a misleading image.
