skilld
All skills
mattpocock avatar

/prototype

@3216582 official
by Matt Pocockmattpocock/skills274k stars
22,987

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Ask your Agent

Use this Skill: https://skilld.dev/gh/mattpocock/skills/prototype

This session only. Nothing lands on disk.

SKILL.md

≈48 tokens always: the name and description. ≈678 when used: this file. ≈3.3k more on demand in 3 files.

Prototype

A prototype is throwaway code that answers a question. The question decides the shape.

Pick a branch

Identify which question is being answered, using the user's prompt, the surrounding code, or by asking if the user is around:

  • "Does this logic / state model feel right?" → LOGIC.md. Build a single shareable HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
  • "What should this look like?" → UI.md. Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.

The two branches produce very different artifacts, so getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.

Rules that apply to both

  1. Throwaway from day one, and clearly marked as such. Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious, but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
  2. Trivial to run. A UI prototype starts from one command in the project's task runner: pnpm <name>, python <path>, bun <path>, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
  3. No persistence by default. State lives in memory. Persistence is the thing the prototype is checking, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE, wipe me" name.
  4. Skip the polish. No tests, no error handling beyond what makes the prototype runnable, no abstractions. The point is to learn something fast.
  5. Surface the state. After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
  6. Capture it when done. Fold any validated decision into the real code, then capture the prototype itself as a primary source: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too (the verdict and the question it settled) in the issue or a commit. The main branch keeps only the validated decision.

Source: SKILL.md on GitHub

Third-party checks

No alerts17d3 checks · Risk SAFE
  • Gen Agent Trust Hub17d

    The skill facilitates rapid prototyping by generating and executing code based on project context. While safe for its intended use, it carries a low risk of indirect prompt injection if analyzed project files contain malicious instructions.

  • Socket17d

    No alerts

  • Snyk17d

    Risk: LOW · No issues

Provenance

Signed by skilld at 3216582. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 2 days ago.

Activeupdated last month

Topics

  • prototype
  • throwaway
  • state-machine
  • ui-design
  • terminal
  • interactive
  • experimentation
  • design-validation

README badge

README badge for mattpocock/skills/prototype

What it does

Builds a throwaway prototype to answer a specific design or logic question, routing to either an interactive terminal app for state-machine testing or a multi-variant UI explorer. Use this when the user wants to quickly validate a data model, mock up UI options, or explore design directions before committing.

Generated from the current SKILL.md.

Frequently asked

When should I use the logic branch vs. the UI branch?
Use the logic branch to test state machines and business logic interactively in a terminal. Use the UI branch to explore multiple design variations on a single route. Choose based on whether the user is asking about how something should work (logic) or what it should look like (UI).
Should I add tests, error handling, and abstractions to the prototype?
No. Skip polish entirely — the point is to learn fast and delete the prototype when done. Only include enough error handling to keep it runnable.
Where should I put the prototype code in the project?
Place it close to the code it's prototyping (next to the module or page), but name it clearly so readers know it's throwaway, not production.
Should the prototype save data to a database?
No. State should live in memory by default. Only hit a database if the question being answered explicitly involves persistence, and use a clearly marked scratch DB or local file.
What do I do with the prototype after it answers its question?
Either delete it or fold the validated decision into real code. Capture the answer and the question it was solving in a durable place like a commit message, ADR, or NOTES.md before deleting.

Generated from the current SKILL.md. These answers refresh after source changes.