prototype

name	prototype
description	Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).

prototype

The de-risking skill. When a decision or plan hinges on a feasibility unknown ("will this approach even work?"), it plans the smallest throwaway build that answers that one question — the learning goal, the minimal scope, the success signal, and the explicit discard. It plans a spike to learn; it is not the real build (that is executor after specify), and it does not choose the approach (that is propose).

It is read-only and advisory: it writes a PROTOTYPE-PLAN.md, never the product. A prototype is throwaway by definition — the plan says so, so its code is never mistaken for production. The output is judged by Review — does the spike actually answer the question, is it the smallest thing that does, and is the discard explicit?

What this does / does not do

Does: name the one feasibility question; define the learning goal + the success/failure signal that answers it; scope the smallest build that produces that signal (mock everything not under test); set a timebox; state the throwaway/discard plan (and what, if anything, graduates as knowledge — not code); write PROTOTYPE-PLAN.md + a receipt. Does not: build the production feature (that is specify → executor), choose between approaches (that is propose), or let prototype code become the real implementation.

When NOT to use

• There is no genuine unknown — the path is clear; skip to specify and build it for real.
• The question is "which approach", not "does this work" — use propose.
• The intent is to build the actual feature — use the pipeline (specify → decompose → executor); a prototype is throwaway, not a head start on production.
• The unknown is about users/market, not technical feasibility — that is research, not a code spike.

Inputs

• The one feasibility unknown + why it blocks the decision/plan.
• The context needed to scope a minimal spike (the risky component, the environment) + any timebox.

How to do it

1. Name the one question. The single feasibility unknown the spike will answer, and what it blocks. One question per prototype — a spike answering three things answers none well.
2. Define the signal. What result means "yes, feasible" and what means "no" — decided before building, so the spike can't be rationalized into a pass.
3. Scope the smallest build. The minimum that produces the signal; mock/stub everything not under test. Smaller is better — the spike's value is the answer, not the artifact.
4. Timebox. A limit that forces the question, not a polished build. State it.
5. Plan the discard. State plainly that the code is throwaway and what graduates instead — the learning (a note, a decision input), not the prototype code. Guard against the spike sliding into production.
6. Write PROTOTYPE-PLAN.md — question + signal + minimal scope + timebox + discard/graduation plan.

Output

• PROTOTYPE-PLAN.md at the product root (or prototypes/PROTOTYPE-PLAN.md if that dir exists) — persistence: Ephemeral. The feasibility question · success/failure signal · minimal scope (what is mocked) · timebox · discard plan + what graduates as knowledge.
• receipt (<workspace>/receipts/prototype-receipt-<ts>.json): base schema + question, success_signal, minimal_scope, timebox, discard_plan, prototype_plan_path. persistence: Ephemeral.

Completion Criteria

Done when: PROTOTYPE-PLAN.md names one feasibility question, defines the success/failure signal before the build, scopes the smallest spike that produces it, sets a timebox, and states the discard + what graduates as knowledge; a receipt records the question + signal.

Not done if: the spike answers several questions at once (none cleanly); the success signal was left undefined (unfalsifiable); or the plan treats the prototype as the start of the production build rather than throwaway.

Next step: run the spike, read the signal, and feed the answer to propose (decide) or specify (build the real thing) — the prototype code is discarded; the learning graduates.

Related Skills

• propose: decides among approaches. prototype supplies the missing feasibility evidence a decision hinges on.
• specify: turns a settled, de-risked approach into a task card. prototype answers "will it work"; the real build follows in the pipeline.
• hunt: validates whether a suspected issue is real. prototype validates whether an approach is feasible — a forward spike, not a bug check.