One-Off Prototype — Use Disposable Code to Answer a Design Question

Skill Overview

The one-off prototyping skill helps you write a piece of throwaway code specifically to answer a design question: does this state model make sense, or what should this interface actually look like?

Applicable Scenarios

1. When the state model or business logic is uncertain. It is easy to miss branches when reasoning through complex state transitions on paper or in your head. The prototype generates a single-file HTML document that can be opened by double-clicking, exercises the state machine through the boundary cases that are hardest to reason about, and allows non-developers to try it out themselves.
2. When the interface design has not yet been decided. Instead of repeatedly describing “the kind of feeling” you want, generate several visibly different UI variants under the same route, switch between them through URL parameters and a floating bottom bar, and choose visually.
3. When others need to participate in the decision. For requirements reviews, solution discussions, or explaining logic to non-technical colleagues, an interactive prototype is much more effective than a written description.

Core Features

1. Automatic branch selection. The skill first determines what kind of question needs to be answered: questions about whether the “logic/state model is correct” follow the logic branch, while questions about “what the interface should look like” follow the UI branch. The outputs of the two branches are completely different, so the skill makes its judgment based on your description and the surrounding code. If the question is genuinely ambiguous and you cannot be reached, it defaults to the branch that best matches the surrounding code and states the assumption at the top of the prototype.
2. Logic prototype: single file + free interaction + step-by-step guidance. The output is a shareable HTML file with buttons for unrestricted interaction as well as a tabbed, guided walkthrough that leads users through the key paths step by step.
3. UI prototype: one route, multiple variants. Provide several stylistically distinct interface options under the same route, switch between them using URL query parameters, and include a floating bottom bar for quick comparison.

Constraints Shared by Both Branches

• Make it explicitly one-off from day one. Place the prototype code next to the module or page where it will eventually be implemented, so the context is clear, but name it so that anyone who happens to find it can immediately tell that it is a prototype, not production code. UI prototypes should follow the project’s existing routing conventions rather than inventing a new top-level structure.
• Startup cost must be zero. A UI prototype should run with an existing project task command (pnpm <name>, python <path>, bun <path>, etc.); a logic prototype should simply be a double-clickable HTML file. It should run without requiring any thought.
• Do not persist by default. Keep all state in memory—persistence itself is often what needs to be validated and should not become a prerequisite for the prototype. If the question genuinely involves a database, use a temporary database or a local file whose name clearly includes “PROTOTYPE—delete freely.”
• Skip all polish. Do not write tests, implement error handling beyond what is necessary to get it running, or extract abstractions. The sole purpose is to learn something as quickly as possible.
• Expose the state. After every operation (logic branch) or every variant switch (UI branch), print or render the complete relevant state so users can clearly see what changed.
• Archive it at the end. Fold the validated conclusion back into the production code. Submit the prototype itself to a disposable branch for archival purposes, keep it out of the main branch, and leave a contextual link to that branch in the implementation issue. Also record the conclusion—the answer and the question it answers—in the issue or commit message. The main branch should retain only the decision that was validated.

Common Questions

What is the difference between a one-off prototype and production code?

The essential difference is purpose: a prototype exists to answer a question, and its mission ends once the question has been answered. Therefore, it does not include tests, real error handling, abstraction, or persistence by default, and it does not go into the main branch. The final step of the skill requires folding the validated decision back into the production code, while preserving the prototype in a disposable branch for reference. Do not directly turn the prototype into production code.

When should I make a logic prototype, and when should I make a UI prototype?

Look at the question you are asking. If you are asking whether “this logic/state model feels right,” use the logic branch; its output is a single-file HTML document with free-interaction buttons and a step-by-step walkthrough. If you are asking “what should this look like,” use the UI branch; its output consists of multiple interface variants under the same route, along with a floating switcher bar. Getting this judgment wrong makes the entire prototype pointless, so the skill first looks for clues in your description and the surrounding code. If both options are plausible and you cannot be reached, choose the one that best matches the surrounding code (backend module → logic, page or component → UI) and state the assumption at the top of the prototype.

How can I tell what the state actually changed to in the prototype?

The skill treats “exposing the state” as a hard requirement: a logic prototype prints or renders the relevant complete state after every operation, while a UI prototype does so after every variant switch. This way, you see not merely an interface that “seems right,” but the actual state after each step.