prototypekit
prototypekit
Some decisions can't be settled by reading. Does this reducer survive partial refunds? Is this library fast enough for our load? What should this settings page actually look like? prototypekit writes code whose only job is to answer one of those, then throws the code away and keeps the answer.
That inversion is the whole skill. The prototype is not a draft of the real thing, not a head start, and not a demo. It is an instrument, and instruments get put away. Everything below exists to keep the code disposable and the answer durable.
When this fires
"Prototype this", "spike this", "throwaway explore X", "does this state model hold up", "will this survive ", "is this fast enough", "do these two interop", "does this API do what its docs imply", "show me a few options for this screen", "mock up three versions", "/prototypekit".
Four things it deliberately is not:
- Not the build step. A build skill turns a settled intent into production code behind a test-and-build gate. prototypekit runs when the intent isn't settled because nobody has seen it work, writes code that fails every production standard on purpose, and gates on nothing.
- Not the research step. Research answers from primary sources and never builds. prototypekit answers by building and cites nothing. They're complements: when research hits a claim its sources won't settle, that claim comes here.
- Not the UI builder. A UI skill builds the screen that ships, conforming to the project's design system. prototypekit's mocks exist to be compared, chosen between, and deleted, and they deliberately break conformity, because three variants that all conform are three variants of one idea.
- Not a demo generator. This is the shape the request most often arrives disguised as. See No question, no prototype.