prototype

Build a disposable prototype to answer a single feasibility question.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/prestarius/jet-skills-stack --skill prototype-prestarius
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: prototype
Source: https://github.com/prestarius/jet-skills-stack/tree/main/skills/prototype
Command: npx skills add https://github.com/prestarius/jet-skills-stack --skill prototype-prestarius

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

A prototype exists to answer a question, not to ship. Treat it as disposable from the first line.

Core Features & Use Cases

  • State the question. Pin down the single thing the prototype must resolve ("can we stream this under 200ms?", "does library X fit our data model?", "which of these two APIs is simpler to use?").
  • Build the minimum that answers it. Hard-code, stub, and fake everything not under test. No error handling, no abstractions, no tests, no config, no polish — those would be wasted effort on code you intend to delete. Timebox it; smaller is better.
  • Isolate it. Put it somewhere clearly disposable (e.g. a spike/ or prototype/ dir, or a throwaway branch). Mark it as throwaway in a comment/README so it can't be mistaken for real code.
  • Report the finding. State the answer plainly, the evidence (numbers, the snippet that proved it, what broke), and a recommendation: which design to take forward, or what to spike next.
  • Close it out. Default to deleting the prototype. If a piece is worth keeping, say which part "graduates" — and note that graduating means rewriting it properly (with tests, error handling, real structure), not promoting the throwaway code as-is.

Quick Start

Create a throwaway prototype to answer a specific feasibility question and report the finding.

Frequently Asked Questions about prototype

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I build a throwaway prototype to test design feasibility?

Build a throwaway prototype when you need rapid validation to decide between approaches, such as checking if a library fits your data model or if streaming stays under 200ms. It answers a single design query quickly without shipping production code.

How do I build a rapid validation spike for a new architecture?

To build a rapid validation spike, hard-code and stub everything not under test. Timebox the effort, skip error handling and abstractions, and isolate the code in a throwaway directory. Document the evidence and recommend which design to take forward.

What is the best way to validate if an API or library fits my data model?

The best way to validate API fit is building a disposable prototype that fakes all unrelated components. Timebox the spike to answer the specific data model question, then document the evidence and your recommended next steps before deleting the code.

Should I keep or delete my prototype code after answering the feasibility question?

You should default to deleting prototype code after it answers the feasibility question. If a piece is worth keeping, note which part graduates and rewrite it properly with tests and structure rather than promoting the throwaway code as-is.

What should a feasibility prototype report include?

A feasibility prototype report should state the answer plainly, provide evidence like numbers or snippets that proved it, and give a recommendation on which design to take forward or what to spike next before closing the experiment out.