Skip to main content
skill CX Codex

brainstorm-prototypes — Claude Code skill: variations to react to

A skill that produces 3–5 deliberately different throwaway variations — layouts, approaches, names — so you can react to them instead of describing what you want.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add Neeeophytee/finding-unknowns-skills --skill brainstorm-prototypes -a claude-code
Open on GitHub

What brainstorm-prototypes does

Use it when the criterion lives in your head but refuses to come out as words. You will know it the moment you see it. The skill takes one decision at a time — a layout, an approach, a data model, a tone — and returns 3–5 variations that diverge for real rather than shading the same idea. Two variations that would draw the same reaction means one gets replaced.

Everything stays cheap and disposable. Visual and UX work comes back as a single self-contained HTML file with fake data, no backend, no state. Approaches come back as a one-screen sketch each: the idea, what it optimizes for, its sharpest tradeoff. Ranked lists run from cheapest to most ambitious so you can draw your own line. Each variation is labelled with the belief it bets on, which is what turns your reaction into a criterion rather than a preference.

After your reactions come in, the skill states what it learned: what you kept rejecting and the requirement hiding behind that. That sentence is the deliverable and belongs in the spec. Prototypes are not production code, so do not wire them into the real app. And if none of the variations land, the framing was wrong — the skill reframes and reruns instead of churning out more of the same.

What it helps with

  • pick a layout you can only judge by looking at it
  • compare several approaches before writing code
  • settle on a name or a tone by trying options
  • surface a requirement the stakeholder cannot put into words
  • mark where cheap ends and ambitious begins

Example prompts for the agent

  • Give me 4 wildly different onboarding screens, each as one HTML file with fake data
  • Sketch 3 approaches to storing order history: the idea, what it optimizes, the sharpest tradeoff
  • Draft 5 names for a CLI tool and label the belief each one bets on

How to install brainstorm-prototypes

1Skills CLI (Vercel)

npx skills add Neeeophytee/finding-unknowns-skills --skill brainstorm-prototypes -a claude-code

2Manually: put the files in place

~/.claude/skills/brainstorm-prototypes/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/brainstorm-prototypes/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about brainstorm-prototypes

How do I install brainstorm-prototypes in Claude Code?

Run npx skills add Neeeophytee/finding-unknowns-skills --skill brainstorm-prototypes -a claude-code. The skill lands at ~/.claude/skills/brainstorm-prototypes/SKILL.md.

What does brainstorm-prototypes do?

It generates several genuinely different throwaway variations — designs, approaches, drafts — for you to react to. Once it has your reactions, it names the requirement behind them and hands that back for the spec.

Which platforms can run this skill?

Claude, Codex, Cursor, GitHub Copilot, Gemini CLI and OpenCode. Each platform has its own install command and its own skills directory.

Source text

SKILL.md · MIT
---
name: brainstorm-prototypes
description: 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.
---

# 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

1. Establish scope first: what is being decided (layout? approach? data model? tone?) and what is explicitly out of scope. One decision per round.
2. Produce 3-5 variations that are **wildly different, not shades of the same idea**. If two variations would get the same reaction, replace one.
3. 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.
4. 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.
5. 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.

© Neeeophytee · MIT · Neeeophytee/finding-unknowns-skills

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set5

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor