ai-blueprint: Skill for Claude Code

prototype - lock the look before you build

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

First action: Before project inspection, preflight, or any other tool call, publish running to blueprint/.state/run.json when blueprint/.state/ exists. From the project root, run the first helper that exists, node .agents/skills/blueprint-doctor/scripts/run-state.mjs or node .claude/skills/blueprint-doctor/scripts/run-state.mjs, with start --command <skill> --summary "<truthful summary>" --boundary <read-only|reviewed|local-only>. Use update at milestones, with --status blocked --resume <command> for a blocker, and finish --status ready|completed at the end; --help lists every option and blueprint/workflow.md has the full activity contract. A missing or failing helper is a warning, not a blocker.

Where this sits in the workflow:

plan  ->  /overview  ->  [prototype]  ->  /feature  ->  build
(you      (project-      (lock the       (one spec    (real
 write)    overview.md)   look)           at a time)   code)

Prototyping is a pre-build step, not a feature. It's fast, visual, and throwaway. Its one durable output is the theme: a set of CSS theme variables that port into the real app's globals.css @theme when you build the first UI feature. Everything else here gets discarded.

This skill is plan-first. Gather the look and the page list, agree on a plan, and only then write any files. Never generate mockups before the user approves.

Step 1 - read what the plan already says

Pull the stated look and feel and the screen/route list from blueprint/context/project-overview.md (its UI/UX section); fall back to the UI/UX section of blueprint/project-plan.md if the overview isn't generated yet. Use this as the starting point, so you're refining the user's intent, not asking from scratch.