A Claude Code skill for seeing an idea before you build it.
Say "let's prototype this" and Claude takes the conversation you've been having as the brief, then draws it: several rough, grayscale, clickable wireframes of the same feature, each betting on a different structure. If the conversation doesn't have enough in it yet, Claude interviews you first. What are you picturing? What has to happen on this screen? What have you already ruled out?
The output is deliberately rough. Boxes, labels, system fonts, no color. That's the point: you judge the plan instead of the paint, and a round takes 45 seconds instead of 5 minutes.
/plugin marketplace add madebydiego/prototype
/plugin install prototype@prototype
Or drop skills/prototype/ and skills/prototype-setup/ into ~/.claude/skills/ yourself.
let's prototype this
prototype 3 ways to show upload progress
what could the settings page look like?
You get 3 to 5 options, as many genuinely different structures as the idea supports. Say a number to force more or fewer.
- The conversation is the brief. Claude says it back in one line before drawing anything. If there's nothing to go on, it asks up to four questions, once, in a single message, and then starts.
- Before writing any markup, Claude names the structural bet each option makes: the nav pattern, the hierarchy, the interaction model. No two options may share a bet. Variations of one layout don't count as options.
- Each option is a wireframe, not a mockup. Around 70 lines of markup, gray rectangles where images go, realistic short copy instead of Lorem ipsum.
- Every option gets a name in a sticky header, like
2 · Split sidebar, with jump links at the top of the file. You say "keep going with the split sidebar one" instead of scrolling back to figure out which number was which. - The parts that matter are clickable: the tab that switches, the drawer that opens, the empty state that fills. An
onclickand a class toggle. No React, no build, no npm. - Claude names its pick, gives two or three reasons and the trade-off it would watch, then stops. You choose, and it iterates a couple of rounds on your choice.
- When a direction is approved, the wireframe becomes the spec and the real thing gets built in your actual codebase.
Two skills and one stylesheet.
skills/prototype/SKILL.md runs every round. It writes all the options into a single file, .prototypes/<slug>/index.html, next to a copy of the kit stylesheet, so the page opens on a double click and the folder can be zipped or moved whole.
skills/prototype/assets/kit.css is the entire visual language: a dozen classes (.ph for image placeholders, .box, .btn, .field, .tab, and friends) under a :root block of variables for font, colors, and radius. The class list is duplicated as a table inside the main skill, so generating a round never requires reading the CSS. The variables are the only part setup is allowed to change.
skills/prototype-setup/SKILL.md is the optional half. Run once per repo, it detects your components and design tokens, asks whether you want house style or plain gray, and writes two files: .prototypes/kit.css (the same stylesheet with your values in :root) and .prototypes/kit.md (a few lines mapping kit classes to your real components, used at handoff time).
On disk, after setup:
.prototypes/
.gitignore ignores everything except itself and the two kit files
kit.css written by setup, committed, shared with teammates
kit.md written by setup, committed
<slug>/
kit.css per-round copy of whichever kit applies
index.html the round itself
The ownership rule that keeps this sane: /prototype only ever writes slug folders and a one-line .gitignore, so until you run setup, nothing commit-visible appears in your repo at all. /prototype-setup owns the kit files, and re-running it edits only the :root variables. The mockups themselves can never reach a commit; delete slug folders whenever you like.
Gray boxes work fine, and installed globally that's all you get. Inside a repo you can do better. Run this once:
/prototype-setup
It finds your components, design tokens and fonts on its own, shows you what it found, and asks a single question: match your house style, or keep plain gray? Gray is a real answer, not a fallback; some people want the paint out of the way on purpose.
Worth being straight about the ceiling: these are standalone HTML files with no build step, so your real React or Vue components can't be rendered in them. The kit approximates their look with CSS, and kit.md records how a button is actually written in your codebase. Wireframes in your fonts and colors read more easily than gray ones. They're still wireframes.
/prototype never stops to ask about any of this. Without setup you get gray boxes and one line at the end telling you the command exists.
MIT