Brainstorm prototypes
Skill Neeeophytee/finding-unknowns-skills/skills/brainstorm-prototypes
8 installable skills for Claude Code and OpenAI Codex, for finding your unknowns before they get expensive: blindspot pass, brainstorms, interviews, references, plans, notes, pitches, and a merge quiz. Community distillation, not official Anthropic.
npx -y skills add Neeeophytee/finding-unknowns-skills --skill brainstorm-prototypesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing 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.
What its author says it does
Copied from the file, not written here
Generate several genuinely different throwaway variations (designs, approaches, drafts) for the user to react to. Use when the user can only recognize what they want by seeing it — visual design, UX flows, naming, tone — or asks to brainstorm or prototype before building.
SKILL.md
1.9 KB, as published. Nobody here has run it
Brainstorm and prototypes
The user has unknown knowns: criteria they can't verbalize but will recognize on sight. Finding those during prototyping is cheap; finding them mid-implementation is expensive, because small spec changes can mean drastically different code. Give them things to react to.
Steps
- Establish scope first: what is being decided (layout? approach? data model? tone?) and what is explicitly out of scope. One decision per round.
- Produce 3-5 variations that are wildly different, not shades of the same idea. If two variations would get the same reaction, replace one.
- Make them cheap and disposable:
- Visual/UX → a single self-contained HTML file with fake data, no backend, no state.
- Approaches → a one-screen sketch of each: the idea, what it optimizes for, its sharpest tradeoff.
- Ranked lists → order from cheapest to most ambitious so the user can draw their line.
- Label each variation with the belief it bets on ("this one assumes density beats whitespace"), so the user's reaction reveals the underlying criterion, not just a preference.
- Collect reactions, then verbalize what was learned: "you consistently rejected X, which suggests the real requirement is Y." That sentence is the deliverable — it becomes part of the spec.
Guardrails
- Nothing produced here is production code. Say so, and don't wire prototypes into the real app.
- Do not converge early to the variation you'd pick. The point is spanning the space.
- If the user reacts to none of them, that's signal too: the decision space was framed wrong. Reframe and rerun rather than generating more of the same.