Some decisions can't be settled by reading. Does this reducer survive partial refunds? Is this library fast enough for our load? What should this settings page actually look like? prototypekit writes code whose only job is to answer one of those, then throws the code away and keeps the answer.

That inversion is the whole skill. The prototype is not a draft of the real thing, not a head start, and not a demo. It is an instrument, and instruments get put away. Everything below exists to keep the code disposable and the answer durable.

"Prototype this", "spike this", "throwaway explore X", "does this state model hold up", "will this survive <hard case>", "is this fast enough", "do these two interop", "does this API do what its docs imply", "show me a few options for this screen", "mock up three versions", "/prototypekit".

Four things it deliberately is not:

Before writing a line, state the question and the decision it unblocks, one sentence each. If you can't write both, there is nothing to prototype yet.

An ask that resolves to "build me a demo", "make a proof of concept for the client", or "just try something" is production work under a softer name. Bounce it once, naming the reason and the route: it wants a plan and a real build, not a throwaway.

If the user reaffirms, the ask converts, not the skill. They've made a decision; arguing twice is not your job. Say plainly that this is production work, then do it as production work: no marker, no exclude entry, no disposal, and it stays on disk. prototypekit stops driving at that point. What you must never do is build a demo as a marked, disposed prototype, because that hands someone a thing to show a client and then deletes it.

Both modes obey these.

Write the question and the decision it unblocks, per No question, no prototype.

Then draw the scope box: the cases that are in, and the cases explicitly out. This is the mechanism behind rule 6, and it exists because the drift is gradual and feels productive. A spike that works invites one more case, then error handling, then a component extraction, and the throwaway quietly becomes an app nobody chose to build. A case outside the box is a new decision: say so out loud and get agreement, don't absorb it.

The box goes in the prototype file's own header comment, so it's in front of you every time you reopen the file, which is exactly where the drift happens. Put any assumption you had to make beside it: a stated wrong assumption is correctable, a silent one isn't.

Ambiguous and the user isn't reachable? Default by what surrounds the code and state the assumption in the header.

Before the first file exists, register the marker patterns in the repo's private exclude, not the tracked . A tracked ignore edit is itself an uncommitted change that commit and review tooling will pick up, so the skill would leave a diff behind while claiming it left nothing; the private exclude is local-only and leaves tracked files untouched.

git rev-parse --git-path info/exclude    # resolve the real path; never hardcode .git/info/exclude

Ask git for that path rather than assuming it, because in a linked worktree is a file, not a directory, so the literal path doesn't exist. Append and only if they aren't already listed. Both patterns ship, because the file glob won't match a directory on its own.

Say you did it in the same line you say where the prototype is going, so the user knows the guard is in place before any code lands.

Same gate, same scope box, same disposal across all four combinations; only the render target changes.

Three structurally different variations on a single route, switched by a URL search param with a small floating switcher. One route means one dev-server start covers all of them and each variant has a link you can send someone.

Divergence is the deliverable, and it's the part that actually fails. Every variant must differ on a structural axis (layout, information hierarchy, or interaction model) and must name the axis it takes. Differing on color, spacing, or corner radius is a recolor, not a variant. Three variants of one idea is a failed prototype: you've spent the effort and still have nothing to choose between. Ship fewer than three only when three genuinely distinct axes can't be named, and then say so rather than padding the set.

Follow whatever routing and naming the project already uses, and never invent a new top-level structure to hold a mock.

When a UI skill is installed, borrow its anti-slop catalog and accessibility floor, but override its design-system precedence for this job only, and say so out loud. That precedence exists to enforce conformity, and conformity is the opposite of what a variant set is for. When no such skill is installed, which is the common case, the structural-axis test above stands on its own and is enough.

A winning variant is evidence, not a starting point. Building it for real is a fresh job against the real files, at full conformity, from scratch.

Four lines, wherever it lands:

Question: <what we needed to know>
Built:    <what was made, and which cases it was driven through>
Showed:   <what actually happened>
Answer:   <the decision this unblocks, now settled>

Write Built straight from the scope box, so it names the cases driven and transitions covered. That specificity is what makes the answer durable without keeping the code, and it's what someone needs six weeks later when the decision gets relitigated.

Land it in whatever asked the question:

When the prototype answered a different question than the one asked, report and stop. The verdict says the asked question is still open and reports the finding beside it. Chasing the new question mid-run is the exact drift the scope box exists to catch, wearing a justification, and the user may not want it chased at all. One carve-out: when the finding invalidates the premise of the asked question (the state model can't exist, so "does it hold up" is moot), that is the answer, and it's reported as one.

Offer the park first, as one ask, with the literal command. It is off by default, because the premise of this skill is that the answer matters and the code doesn't:

git checkout -b prototype-<slug> && git add -f <files> && git commit -m "prototype: <question>" && git checkout -

Then delete, confirmed per file. List every file you created this session and confirm each one individually. This is not ceremony: an excluded file is untracked, so git cannot recover it, which makes the delete final in a way most deletes aren't. Never touch a file you didn't create in this session.

Remove the exclude entry only when every prototype file is gone. Any file the user keeps gets reported by absolute path with its exclude line left in place, which is what keeps the leftover local-only and findable instead of quietly commit-able.

What changed. Report the files created, which were deleted and which the user chose to keep, whether the exclude entry was removed or retained, and whether the park happened.

Where it landed. Give the verdict's destination by path (the plan file and the row it added, the issue, or the chat), and the absolute path of anything still on disk.

Next. Crown one move:

Name a sibling skill only when it's actually installed, and always give the plain fallback.