Rite prototype
Skill ViktorsBaikers/DevRites/pack/generated/claude/skills/rite-prototype
User-invoked throwaway prototype for one logic or UI design question; delete or absorb after the answer.From its SKILL.md
npx -y skills add ViktorsBaikers/DevRites --skill rite-prototypeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.1 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
/rite-prototype: answer one question with throwaway code
A prototype is throwaway code for exactly one question. Choose its shape from that question.
0. Read core rules
Read .claude/skills/devrites-lib/reference/standards/core.md first: the operating rules and the "capture the answer"
persistence discipline apply even to throwaway code. The other rule files load on demand.
1. Name the question
If the user did not give the question explicitly, ask one short question to pin it down. Examples that count as "the question":
- "Does this reducer correctly model add / undo / re-add of the same item?"
- "Which of these three settings layouts feels right?"
- "Will the proposed state machine deadlock when X overlaps Y?"
A vague request such as "explore this feature" is not enough. Ask once for a specific question.
2. Pick the branch
Read the user's prompt and surrounding code, then choose one branch:
| Question shape | Branch | Artifact |
|---|---|---|
| "Does this logic / state / data model behave right?" | Logic | Smallest runnable harness (terminal script / REPL / mini node or python file) that pushes the model through the hard cases. |
| "What should this look like / which UX wins?" | UI | 2-4 radically different UI variations on a single route, switchable via a query param + a small floating selector bar. |
If genuinely ambiguous and the user is AFK: pick by the surrounding code (backend module → Logic; page / component → UI) and state the assumption in a comment at the top.
Variations must differ in structure. Colour or padding changes alone do not answer a design question. Give each variation a different information architecture or interaction model.
3. Rules that apply to both branches
- Mark it as throwaway. Place the prototype near its eventual use, but use a name
that clearly identifies it:
prototype/,__prototype__,.scratch/, etc. Obey the project's existing routing / module convention; don't invent a new top-level structure. - Provide one run command. Use the project's existing task runner:
pnpm <name>,python <path>, orbun <path>. - No persistence by default. State lives in memory. Persistence is usually the
thing the prototype is checking, not a dependency. If the question explicitly
involves a DB, hit a scratch DB or a local file with a name like
PROTOTYPE — wipe me. - Skip polish. Add no tests, abstractions, or error handling beyond what is needed to run and answer the question.
- Surface 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. After answering the question, delete the prototype or fold the validated decision into production code.
4. Capture the answer
The answer is the only durable output. Before declaring the prototype done, write one of:
- An entry in the active feature's
decisions.md(.devrites/work/<slug>/decisions.md) with the question and the answer. - A
NOTES.mdnext to the prototype if no active feature exists.
If the user is present, ask for the verdict directly. In AFK, the prototype remains
incomplete until the verdict is filled in. A blank VERDICT: ___ is not an answer.
Mark it not yet complete. Queue the question and do not delete the prototype until
a later pass records the verdict.
Where this slots in
/rite-prototype is a scoped detour, not a separate phase. Typical uses:
- During
/rite-clarify(between spec and define): a product/constraint question is undecidable on paper; prototype it, capture the answer, return to/rite-clarify. - Mid-build:
/rite-buildhit a state-model ambiguity that the spec doesn't resolve. Drop into a Logic prototype, capture the answer, return.
After the prototype answers the question and the answer is recorded, return to the calling phase. The prototype itself does not ship.
Output
Reply-contract exception: scoped prototype detour. Run devrites-engine progress only when
an active workspace exists; otherwise skip it. Use the compact labels from the shared
completion reply contract
(devrites-lib/reference/reply-contract.md).
Done: prototype answered <question>.
Changed: <prototype path | deleted after absorption>; decisions.md or NOTES.md
Evidence: run command <cmd -> result>; verdict <one line>
Open: <none | non-blocking delete/absorb follow-up>
Next: <single command returning to the calling phase>
Record: <.devrites/work/<slug>/decisions.md | NOTES.md path>
↻ Hygiene: /clear after the answer is recorded; delete or absorb throwaway code before shipping
If the verdict is missing, use the shared Awaiting human form. The prototype is
not Done, and Resume: points to the queued verdict question.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.