prototype

Trigger phrases

Phrases that activate this skill when typed to Claude Code:

• prototype this
• try a few designs
• let me play with it
• sanity-check this state machine

What it does

prototype answers one shape-of-the-thing question with throwaway code. The skill picks which of two branches fits from the user’s framing:

• Logic branch — “does this state model feel right?” produces a tiny interactive terminal app that drives the state machine through cases that are hard to reason about on paper. Sub-doc LOGIC.md carries the recipe.
• UI branch — “what should this look like?” produces several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar that lets you toggle between them. Sub-doc UI.md carries the recipe.

If the question is genuinely ambiguous and the user isn’t reachable, the skill defaults by surrounding code (backend module → logic, page/component → UI) and states the assumption at the top of the prototype.

The shared rules (across both branches) are deliberately strict:

1. Throwaway from day one, and clearly marked as such. Locate the prototype next to the module/page it’s prototyping for; name it so a casual reader can see it’s a prototype.
2. One command to run. Whatever the project’s task runner is (pnpm <name>, bun <path>, python <path>).
3. No persistence by default. State in memory. Persistence is what the prototype is checking, not something it should depend on.
4. Skip the polish. No tests, no error handling beyond what makes it runnable, no abstractions.
5. Surface the state. Print or render full relevant state after every action (logic) or on every variant switch (UI).

When to use it

Reach for it when:

• You’re about to commit to a non-trivial data model, state machine, or domain shape and staring at the code isn’t telling you whether it’ll feel right
• You have a UI section where 2–4 candidate directions are reasonable and the right call is “look at them next to each other”
• The plan currently says “I’ll figure out the state shape as I build it” — that’s the signal

When not to reach for it:

• The shape is settled; you’re just implementing it
• The question is well-bounded enough to answer with a paper sketch or a single console.log

Install

The skill is distributed via Pocock’s skills repo. Install via his recommended path (npx skills add or manual copy of the SKILL.md + the LOGIC.md / UI.md sub-docs into .claude/skills/prototype/) — see the repo README for canonical install instructions.

What a session looks like

A typical session has three phases:

1. The agent picks the branch. Logic vs UI, based on the question or (if ambiguous) the surrounding code. The branch decision gets stated at the top of the prototype as an assumption.
2. The agent writes the throwaway code. A terminal app on the logic branch; a route with variants and a floating toggle bar on the UI branch. The code lives next to the real module/page, named clearly as a prototype.
3. You play with it; the prototype is the receipt. State gets surfaced on every action or variant switch. You either commit to the answer or revise the question. Then delete the prototype.

The discipline that makes it work is the throwaway rule. If the prototype starts accumulating tests, abstractions, or error handling, it has stopped being a prototype.

Receipts

TODO — to be filled in from a real session. When the skill is triggered in production use, capture: which branch the agent picked (logic vs UI) and whether the framing matched the question, how long from trigger to runnable prototype, how many UI variations or state-machine cases the prototype covered, and whether the answer-to-question round-trip closed in one pass or needed a second iteration.

Source and attribution

Originally written by Matt Pocock. The canonical SKILL.md plus the LOGIC.md / UI.md sub-docs live in the engineering/prototype folder of his public skills repository.

License: MIT. You can install, adapt, and redistribute the skill, with attribution preserved.

This page documents the skill from a practitioner’s perspective. For the formal spec and any updates, defer to the source repo.