Fidelity-Raising Prototype
A planning primitive: when a discussion is stuck at the abstract level, make a cheap, rough, concrete artifact to react to — an outline, a rough tech stub, some throwaway UI or logic code — because reacting to something concrete raises the fidelity of the conversation faster than more abstract back-and-forth. The source's framing: "you raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to." The prototype is deliberately disposable; its job is to sharpen intent, not to be kept. It is most essential where the key question is "how should it look?" or "how should it behave?" — i.e. almost anything touching front-end code, where words under-specify and a rough mock immediately surfaces disagreement.
In the source's system the prototype is a /prototype
skill that offers a choice between a logic prototype
and a UI (state) prototype — the two react quite
differently — and it is invoked as a resolution mode for a planning
ticket (Resolution-Typed
Tasks), linking the produced artifact back to the plan as an asset.
It sits before the spec: prototype to decide, then write the
decided thing down.
Claims
- Raise the fidelity of a planning discussion by producing a cheap, rough, concrete artifact to react to, rather than arguing in the abstract. principle — durable: a concrete referent lowers ambiguity between the parties regardless of tool or domain — it's the same "location/thing is part of the message" logic as a pinned annotation, applied to intent instead of to a diff.
- Prototype before the spec, and treat the artifact as disposable — its value is the reaction it provokes, not the code. best practice — context: planning where intent is still fuzzy; contingent on the prototype being genuinely cheap, because a prototype you're tempted to keep stops being a throwaway probe and starts accruing the cost of real code.
- A prototype is essential for almost anything front-end, where "how should it look / behave" is the deciding question. best practice — context: UI / interaction work; the payoff shrinks for back-end or config work whose behavior is already pinned by a contract, so reach for it when the open question is experiential.
- Distinguish a logic prototype from a UI/state prototype —
they react differently and want different rough artifacts.
observation — the source's
/prototypesplit; a note on shape, not a universal law.
Related
- Resolution-Typed Tasks — "prototype" is one of the resolution modes a planning ticket can carry; this page is that mode as a standalone primitive.
- Map-First Planning — prototyping is how you resolve a foggy node whose unknown is experiential ("how should it look / behave") before the map converts to a spec.
- Spec-Driven Development — the downstream artifact: prototype to decide, then write the decision into the spec; the prototype raises the fidelity of what the spec will say.
- Imagination Constraint — a cheap concrete artifact widens what the parties can imagine asking for, by giving them something real to push against.
- Distillate: Skills v1.1: Wayfinder, the SDLC flow, and naming the artifact right