truth-serum

Instead of guessing which objections buyers will raise, you ask a hundred simulated ones, each a sub-agent playing a specific buyer drawn from your target customer. You are the moderator. You never answer for a buyer.

What this is for: finding objections, segments, wording and the questions to take to real people. What it is not: demand. Language models lean agreeable, so a high buy rate here is the best case, not a forecast, and it can fail a plan but never pass one.

Read ${CLAUDE_SKILL_DIR}/../receipts/rules.md first.

What the user typed after /truth-serum: $ARGUMENTS

The tool

All bookkeeping goes through panel.py in this skill's folder:

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

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

Step 1: the target customer

Write founder/customer.json (shape: customer.example.json in this folder):

• business, and target: who the customer is, in one specific line.
• segments: 2 to 4 groups with a share and an income range [low, high].
• behaviours: 4 to 8 buying behaviours with a share and a how line (daily regular, deal hunter, reads every review, loyal to a competitor...).
• objections: the 4 to 8 doubts this kind of buyer really has.
• habits (optional): everyday context lines that make a buyer concrete.

Ground it in something real. Use what the user knows about their customers, and if /ground-truth ran, the complaints in founder/competitors.md. If the user has real customer data (call notes in founder/evidence/calls/, reviews, survey answers), prefer it to your guesses and say which parts are guesses.

If the target is a small set of businesses (a few hundred firms, not a mass market), say plainly that five real calls will teach more than this panel, and offer /receipts and its call guide first. Run the panel only to sharpen the questions. 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.

Step 2: the pitch

Write founder/pitch.md: 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.

Step 3: deal and run

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

init deals the persona cards (same seed, same cards; the seed is recorded). prompts 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):

• subagent_type: general-purpose
• description: panel <id>
• prompt: Read <brief path> and follow it exactly. It is your whole brief.

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 PANEL save <id> and the reply on stdin; save 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 --quick (20 buyers) for a first look. Sub-agents write one file each into founder/panel/answers/; in the default permission mode that is one approval per file, so suggest accept-edits mode (Shift+Tab) for the run.

Step 4: read it to the user

PANEL tally writes founder/panel/results.md and results.json. Give the user:

0. The hard truth: the strongest reason buyers pass, in one sentence, and a reminder that the buy rate is simulated and an upper bound.
1. The headline: "40 buy · 60 pass (simulated)" and the buy rate.
2. Who buys and who doesn't: the segment and behaviour rows that differ most.
3. Why they pass: the top three reasons with one quote each, as written.
4. What would flip a no: the most repeated answers. 4b. The core worry or desire: under the reasons they give, what the buyers who pass seem to fear and the ones who buy seem to want (status, not looking foolish, time back, money saved). One line each, labelled simulated. This is a guess to check on real calls, not a finding.
5. One sentence on what to change before spending money, and which skill does it (pricing, offer, marketing).
6. Take it to real people: the panel is a survey, and a survey tells you what people say, not what they do. The real answer is a sale (Ready, Fire, Aim, rule 11 in rules.md). Turn the top three objections into questions for real calls, in the style of ${CLAUDE_SKILL_DIR}/../receipts/conversations.md (about their past, not your idea). That is the panel's real job.

Then log the result as SIMULATED:

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" add --kind demand --status SIMULATED --use PRIVATE --by truth-serum --claim "Simulated panel buy rate (seed <S>)" --number "<buys> of <answered>"

Honest limits, say them once

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 pilot, a landing page with a price) before signing anything. Never call the panel "validation", "market research" or "customers", and never quote a panel buyer as a customer: not in a pitch, an ad, a deck or a grant.

The brief every buyer gets

panel.py fills the card into a fixed template (see BRIEF 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.

Output

founder/customer.json, founder/pitch.md, founder/panel/ (cards, briefs, answers, results). Next: /litmus reads the price answers, /dealbreaker and /signal read the objections.