Prototyping
A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
npx -y skills add NjoyimPeguy/augments --skill prototypingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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.
What its author says it does
Copied from the file, not written here
Use when a design or feasibility question is genuinely uncertain and cheaper to answer by building a throwaway than by arguing — a tricky bit of logic, a layout choice, a library's real behaviour. Skip when you already know the answer.
SKILL.md
2.1 KB, as published. Nobody here has run it
Prototyping
A prototype answers one question and dies. Its only job is to turn an uncertainty into a fact cheaply — the code is disposable; the answer is what you keep.
When to use
- A specific question is uncertain and faster to build than to argue: does this algorithm work, does this layout read, does this library do what its docs claim.
- Reached from
feasibility-check(a killer risk) orui-ux-design(a layout choice). - Skip when you already know the answer, or the question is vague — a prototype that answers the wrong question is pure waste.
Procedure
- Write the question down, explicitly, before any code. If you can't state it in one sentence, you're not ready to prototype.
- Build the smallest thing that answers it — in memory, with no persistence, no tests, no generality. "What if we needed X later" is banned; that's not the question.
- For logic: isolate it in a portable module behind a tiny throwaway driver (a CLI or loop). The driver dies; the validated logic can be lifted into the real code.
- For UI: build 2–3 structurally different variants (different layout, hierarchy, primary affordance — not colour) inside a real, populated page, not an empty route where everything looks fine.
- Record the answer — the question and what you learned — durably (a note, or an ADR via
architecture-decisionsif it settles a decision). Then delete the prototype.
Common mistakes
- No written question — you can't tell when you're done, and the code becomes "real" by accident.
- Adding tests or generality — a prototype that needs tests is no longer a prototype.
- Variants that differ only in colour — that's a tweak, not an answer.
- Keeping the prototype "as a base" — you'll ship unvalidated throwaway code. Delete means delete.