Design & UX · Building & coding
prototype
/prototype
Build a throwaway UI prototype for the user to react to before any real code. Read this skill when the user asks for a mockup or a prototype of a UI. Use it when a design decision depends on look, feel, or flow that text cannot settle.
For whom
Assessment and security
82/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content17 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
- Files in this package
- 2
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
Deprecation
No signals detected. Repository changed on 16.10.2026, without references to retired models or APIs.
Licence
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Build a throwaway UI prototype for the user to react to before any real code. Read this skill when the user asks for a mockup or a prototype of a UI. Use it when a design decision depends on look, feel, or flow that text cannot settle.
Original author description
Build a throwaway UI prototype for the user to react to before any real code. Read this skill when the user asks for a mockup or a prototype of a UI. Use it when a design decision depends on look, feel, or flow that text cannot settle.
How it works
SKILL.md has no level-two headings · 17 lines, 331 words
SKILL.md preview
--- name: prototype description: Build a throwaway UI prototype for the user to react to before any real code. Read this skill when the user asks for a mockup or a prototype of a UI. Use it when a design decision depends on look, feel, or flow that text cannot settle. --- The user wants a throwaway prototype to react to before any real code. It settles a question of look, feel, or flow that text cannot settle. 1. Base the prototype on a design system before you build. Never build on the defaults of the model, because they look generic. Use the `DESIGN.md` of the project, or its existing design tokens, when they exist. When none exists, get one from the user first. That is a `DESIGN.md`, a reference site to match, or a font pairing from a source such as fontpairs.co. Do not start until typography, color, and spacing come from a real source. 2. Sometimes that source is a reference site or a font pairing, not an existing `DESIGN.md`. Then write the resolved tokens to the `DESIGN.md` of the project before you build: typography, color, and spacing. That file is the one thing that the prototype leaves behind. `implement` and `rubric` read it. 3. Tokens leave most of the look open. Build to [look.md](references/look.md): the defaults that generated UI tends toward, and what replaces them. 4. Build the prototype as one self-contained HTML file outside the repository. Give the user its path, to open in a browser. 5. Stop when the user has reacted. Rules: - The prototype is visual only. Mock the screens with fake data. Connect no backend, keep no state, open no branch, and touch no production code. - Write less: short labels, and no helper text or explanation that the design does not need. Generated UI explains too much. A prototype that explains too much is already wrong. - When the direction is open, put a few clearly different layouts in the file to react to. Do not show one polished guess. - Copy what exists: the markup and tokens of the real components or pages to match. Do not describe them. - The prototype is a throwaway. It settles the direction. Discard it when the user picks, and take the decision into the real work.
Files in this package (2)
- SKILL.md 2 KB
- references/look.md 3 KB
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · pwguler/skills | 82 | MIT |
| leanstacks/lstk | 100 | MIT |
| A7-studio/jobmigo | 100 | MIT |
| akillness/jeo-skills | 100 | MIT |
| runwield/runwield | 100 | MIT |
| yuan88964/RelayStudio | 100 | MIT |
| mathews-tom/armory | 100 | MIT |
| deaconb28-lang/prototype | 100 | MIT |
| drvoss/everything-copilot-cli | 100 | MIT |
Database snapshot: 13.11.2026 · package version 68a3003d3c64 (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 95ce-prototype
Build a throwaway prototype to answer how something should work, feel, or read. Use when committing the wrong answer would be expensive to unravel and a cheap sketch cannot settle it. Not a rough visual probe during brainstorming, not for deciding what to build, not polishing a… - 90throwaway-prototype
Use when a design question needs a throwaway runnable answer: a terminal app that exercises a state model, or switchable UI variants on one route. Not for production code. - 85workflow-prototype
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. - 100prototype-fast
[Orbit 2.1.3 Plan] A throwaway prototype for one question: logic or look, in an hour or two. Use when: «прототип», «проверим идею», «набросай вариант», «быстрый прототип»; prototype, spike, quick mockup, test the idea. - 90prototype-spike
Build or plan an explicitly throwaway prototype to answer a design, API, UX, performance, or integration question, then capture findings and cleanup. Use when the user asks for a spike, prototype, proof of concept, or experiment before committing to production design. - 90jor-prototype
Build a throwaway prototype to answer a design question. Use to sanity-check whether a state model or logic feels right, or to explore what a UI should look like with variants screenshotted at the project's breakpoints.