The craziest part of the pack. Instead of guessing whether people will buy, you ask a hundred of them, each one a sub-agent playing a specific buyer drawn from your target customer. You are the moderator. You never answer for a buyer.

What the user typed after :

All bookkeeping goes through in this skill's folder:

python3 "${CLAUDE_SKILL_DIR}/panel.py" <command>

Below, means exactly that. If the path is not expanded, use the base directory Claude Code printed for this skill. State lives in .

Write (shape: in this folder):

Ground it in something real. Use what the user knows about their customers, and if ran, the complaints in . If the user has real customer data (interviews, reviews, survey answers), prefer it to your guesses and say which parts are guesses. Show the user the profile in a few lines and let them correct it before you deal: a wrong customer makes the whole panel wrong.

Write : what a buyer would actually see. The product, the price, where and how to get it, any opening offer. Three to six plain lines, no superlatives, nothing the business cannot deliver. Every buyer sees exactly this.

PANEL init --customer founder/customer.json --pitch founder/pitch.md --n 100
PANEL prompts

deals the persona cards (same seed, same cards; the seed is recorded). writes one brief per buyer and lists them in waves of 10. For each wave, send ONE message with one Agent tool call per buyer in that wave (the Agent tool is called Task in older Claude Code versions):

Wait for the whole wave before the next one. Claude Code runs about 10 tool calls at once by default, so 100 buyers is 10 waves. After the last wave:

PANEL check      # lists missing or broken answers
PANEL prompts    # rewrites briefs for those only; run them once more
PANEL tally

If a buyer printed its JSON in its reply instead of writing the file (it happens), file its own reply with and the reply on stdin; refuses anything that is not a valid answer. A buyer that fails twice is left out and counted in the results. Never write an answer for a buyer yourself.

Before a 100-buyer run, tell the user it is 100 sub-agent calls and suggest (20 buyers) for a first look. Sub-agents write one file each into ; in the default permission mode that is one approval per file, so suggest accept-edits mode (Shift+Tab) for the run.

writes and . Give the user:

These are simulated buyers. They are good at surfacing objections, segments and wording you had not thought of, and bad at predicting real conversion: language models lean agreeable, so treat the buy rate as an upper bound. Confirm the big calls with real people (a waitlist, a pre-sale, a landing page with a price) before signing anything. Do not present panel quotes as customer testimonials.

fills the card into a fixed template (see in the script): who the buyer is (name, age, segment, income, buying behaviour, a habit, the doubt that comes to mind), the pitch word for word, an instruction not to be agreeable and not to invent facts, and the exact JSON to write: buys, purchases in the first month, a reason code, the reason in their own voice, their main objection, what would change their mind, and four price answers (too cheap, a bargain, getting expensive, too expensive). Never edit a brief for one buyer.

, , (cards, briefs, answers, results). Next: reads the price answers, and read the objections.