prototype
Skill1 starsChanged 4 months agoMITView on GitHub
Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.
We split this skill into the rules it gives an agent
3 rules. 2 are common, 1 is distinctive, and 0 are very specific to this project.
2
Common
Most of the 172 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 25
Skip the polish: No tests, no error handling beyond what makes the prototype _runnable_, no abstractions.
- Common: line 26
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 …
- Distinctive: line 27
Delete or absorb when done: When the prototype has answered its question, either delete it or fold the validated decision into the real …
“Common” is measured: kept by at least 6 in 10 of the 172 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
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 — from 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 tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
- "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 — 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
- 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.
- One command to run. Whatever the project's existing task runner supports —
pnpm <name>,python <path>,bun <path>, etc. The user must be able to start it without thinking. - 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.
- Skip the polish. No tests, no error handling beyond what makes the prototype runnable, no abstractions. The point is to learn something fast and then delete it.
- 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.
- Delete or absorb when done. When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.
When done
The answer is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a NOTES.md next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.
Other versions199 projects use a version of this.
Word for word · 11
- GreyDGL/PentestGPT★ 16k100% same
- Tiberriver256/mcp-server-azure-devops★ 398100% same
- ninehills/skills★ 280100% same
- Roentek/Claude_Code_Boilerplate_Framework★ 4100% same
- grasscaograss/AwesomeWeldoneSkills★ 2100% same
- FabienDehopre/triple-yahtzee-score-board★ 1100% same
- josecabralf/skills★ 0100% same
- Raj1984/BaseProject★ 0100% same
- surasakcho/claude-skills★ 0100% same
- treramey/dot_minions★ 0100% same
1 more not listed
Edited · 110
- mattpocock/skills★ 309k63% same
- QuivrHQ/quivr★ 40k63% same
- ArcReel/ArcReel★ 6k63% same
- withcoral/coral★ 4.9k63% same
- epicenter-md/epicenter★ 4.8k86% same
- EpicenterHQ/epicenter★ 4.8k86% same
- bestofjs/bestofjs★ 3.1k65% same
- CelestoAI/SmolVM★ 1k61% same
- moeru-ai/xsai★ 66463% same
- nodetool-ai/nodetool★ 60362% same
100 more not listed
Wrote their own version · 78
- emilkowalski/skills★ 53ksame name
- emilkowalski/skill★ 47ksame name
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- spree/spree★ 16ksame name
- usekaneo/kaneo★ 9.7ksame name
- podman-desktop/podman-desktop★ 8.1ksame name
- vinvcn/mattpocock-skills-zh-CN★ 5.5ksame name
- nightly-labs/openbot★ 4.4ksame name
- plugin87/ux-ui-agent-skills★ 3.1ksame name
- classroomio/classroomio★ 1.7ksame name
68 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use soak-test, team-live-ops and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
lilangMaxSkillsoak-test
Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.
Also in 9 projects that use this
lilangMaxSkillteam-live-ops
Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update.
Also in 9 projects that use this
CoralGameSkillplaytest-report
Generates a structured playtest report template or analyzes existing playtest notes into a structured format. Use this to standardize playtest feedback collection and analysis.
Also in 12 projects that use this
CoralGameSkillteam-polish
Orchestrate the polish team: coordinates performance-analyst, technical-artist, sound-designer, and qa-tester to optimize, polish, and harden a feature or area for release quality.
Also in 14 projects that use this
- +5 more from lilangMax
- +3 more from CoralGame
In this repository22 other files it gives its agents.
- pi/AGENTS.mdAGENTS.md
- agent-workflowsSkill
- architecture-securitySkill
- code-review-releaseSkill
- documentation-passSkill
- exploring-codebasesSkill
- find-skillsSkill
- frontend-webSkill
- githubSkill
- grill-meSkill
- grill-with-docsSkill
- improve-codebase-architectureSkill
- improveSkill
- product-design-writingSkill
- project-backlogSkill
- red-teaming-decisionsSkill
- systems-backendSkill
- tddSkill
- testing-debugging-verificationSkill
- to-issuesSkill
- to-prdSkill
- triageSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

