mcpField
P
prototype

prototype

github.com/jayden-dangDevelopment146 installsUpdated 4d ago
Repository

About prototype

prototype is a guide for throwaway code that answers one design question, aimed at developers exploring logic or interface ideas. It separates terminal-driven logic prototypes from switchable browser UI variants, and stresses recording findings before deleting or absorbing the code.

Key features

  1. 01Choose logic or UI based on the question
  2. 02Run with a single command
  3. 03Keep state in memory
  4. 04Show all relevant state
  5. 05Delete or absorb when finished
  6. 06Record the question and findings

Use cases

  1. 01Validate logic or a state model
  2. 02Compare structurally different screen variants
  3. 03Explore a design near related code

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jayden-dang/skills --skill prototype

After installing, type/prototypein Claude Code to confirm it loaded.

Bundled filesLOGIC.mdUI.md

Details

From the project README

Prototype

A prototype is throwaway code whose only job is to answer one design question. The question decides the shape.

Pick a branch

Identify the question first — from the request, the surrounding code, or by asking:

  • "Does this logic / state model hold up?" → LOGIC.md: an interactive terminal app over a pure logic module the user can drive by hand.
  • "What should this look like?" → UI.md: several structurally different variants of one screen, switchable in the browser.

Picking the wrong branch wastes the whole prototype. If it's genuinely ambiguous and the user is unreachable, choose by proximity (backend module → logic; page or component → UI) and record the assumption at the top of the prototype.

Rules for both branches

  1. Throwaway from day one, and marked as such. Put it near the code it's exploring so context is obvious, but name it so nobody mistakes it for production (prototype in the path or filename). Follow the project's existing conventions — never invent new top-level structure for it.
  2. One command to run. Register it with the project's existing task runner (read commands from docs/agents/project.md when present). The user starts it without thinking.
  3. No persistence. State lives in memory. Persistence is what the prototype is testing an idea against, not something it depends on. If the question is explicitly about storage, use a scratch store with an unmistakable "prototype — safe to wipe" name.
  4. Skip the polish. Write the logic inline, hardcoded, in the fewest lines that answer the question — no tests, and only enough error handling to keep it runnable. Speed of learning is the whole point.
  5. Surface internal state. After every action or variant switch, show the full relevant state. Hidden state hides the answer.
  6. Delete or absorb when done. Once the question is answered, remove the prototype or fold the validated piece into real code — REQUIRED SUB-SKILL: use tdd when reimplementing it as production code; the prototype's logic is a reference, not tested code.

The answer is the only deliverable

Nothing about the prototype's code matters afterward — only what it taught you. Capture the question and its answer somewhere durable: an ADR (if it clears the ADR gate in domain-modeling), a requirement in the feature's requirements.md, or the commit message that deletes/absorbs the prototype. If the user isn't around to give the verdict, leave a clearly-marked placeholder for it next to the prototype so it gets filled in before deletion.

Comments

Markdown supported