truth-serum

Que fait truth-serum ?

Au lieu de deviner quelles objections les acheteurs soulèveront, vous en interrogez une centaine de simulés, chacun étant un sous-agent jouant un acheteur spécifique issu de votre client cible. Vous êtes le modérateur. Vous ne répondez jamais à la place d'un acheteur.

À quoi cela sert : trouver des objections, des segments, du phrasé et les questions à poser à de vraies personnes. Ce que ce n'est pas : de la demande. Les modèles de langage ont tendance à être complaisants, donc un taux d'achat élevé ici est le meilleur des cas, pas une prévision, et il peut faire échouer un plan mais jamais le valider.

Lisez d'abord ${CLAUDE_SKILL_DIR}/../receipts/rules.md.

Ce que l'utilisateur a tapé après /truth-serum : $ARGUMENTS

L'outil

Toute la comptabilité passe par panel.py dans le dossier de cette compétence :

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

Ci-dessous, PANEL signifie exactement cela. Si le chemin n'est pas développé, utilisez le répertoire de base que Claude Code a imprimé pour cette compétence. L'état réside dans founder/panel/.

Étape 1 : le client cible

Écrivez founder/customer.json (format : customer.example.json dans ce dossier) :

• business, et target : qui est le client, en une ligne spécifique.
• segments : 2 à 4 groupes avec une share et une fourchette de income [bas, haut].
• behaviours : 4 à 8 comportements d'achat avec une share et une ligne how (habitué quotidien, chasseur de bonnes affaires, lit tous les avis, fidèle à un concurrent...).
• objections : les 4 à 8 doutes que ce type d'acheteur a vraiment.
• habits (facultatif) : lignes de contexte quotidien qui rendent un acheteur concret.

Ancrez-le dans quelque chose de réel. Utilisez ce que l'utilisateur sait de ses clients, et si /ground-truth a été exécuté, les réclamations dans founder/competitors.md. Si l'utilisateur a de vraies données clients (notes d'appel dans founder/evidence/calls/, avis, résultats de sondage), préférez-les à vos suppositions et dites quelles parties sont des suppositions.

Si la cible est un petit ensemble d'entreprises (quelques centaines d'entreprises, pas un marché de masse), dites clairement que cinq vrais appels en apprendront plus que ce panel, et proposez d'abord /receipts et son guide d'appel. Exécutez le panel uniquement pour affiner les questions. Montrez le profil à l'utilisateur en quelques lignes et laissez-le le corriger avant de distribuer les cartes : un mauvais client rend tout le panel faux.

Étape 2 : l'argumentaire

Écrivez founder/pitch.md : ce qu'un acheteur verrait réellement. Le produit, le prix, où et comment l'obtenir, toute offre de lancement. Trois à six lignes simples, pas de superlatifs, rien que l'entreprise ne puisse livrer. Chaque acheteur voit exactement cela.

Étape 3 : distribuer et exécuter

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

init distribue les fiches personnage (même graine, mêmes fiches ; la graine est enregistrée). prompts écrit un briefing par acheteur et les liste par vagues de 10. Pour chaque vague, envoyez UN message avec un appel d'outil Agent par acheteur dans cette vague (l'outil Agent s'appelle Task dans les versions plus anciennes de Claude Code) :

• subagent_type: general-purpose
• description: panel <id>
• prompt: Lisez <chemin du brief> et suivez-le exactement. C'est l'intégralité de votre briefing.

Attendez la fin de chaque vague avant la suivante. Claude Code exécute environ 10 appels d'outil à la fois par défaut, donc 100 acheteurs représentent 10 vagues. Après la dernière vague :

PANEL check      # liste les réponses manquantes ou cassées
PANEL prompts    # réécrit les briefs pour ceux-ci uniquement ; exécutez-les à nouveau
PANEL tally

Si un acheteur a imprimé son JSON dans sa réponse au lieu d'écrire le fichier (cela arrive), classez sa propre réponse avec PANEL save <id> et la réponse sur stdin ; save refuse tout ce qui n'est pas une réponse valide. Un acheteur qui échoue deux fois est laissé de côté et compté dans les résultats. N'écrivez jamais vous-même une réponse pour un acheteur.

Avant une exécution sur 100 acheteurs, dites à l'utilisateur qu'il s'agit de 100 appels de sous-agents et suggérez --quick (20 acheteurs) pour un premier aperçu. Les sous-agents écrivent un fichier chacun dans founder/panel/answers/ ; en mode d'autorisation par défaut, cela représente une approbation par fichier, donc suggérez le mode accept-edits (Shift+Tab) pour l'exécution.

Étape 4 : lire les résultats à l'utilisateur

PANEL tally écrit founder/panel/results.md et results.json. Donnez à l'utilisateur :

0. La vérité qui fait mal : la raison la plus forte pour laquelle les acheteurs refusent, en une phrase, et un rappel que le taux d'achat est simulé et une limite supérieure.
1. Le titre : « 40 achètent · 60 refusent (simulé) » et le taux d'achat.
2. Qui achète et qui ne fait pas : les lignes de segment et de comportement qui diffèrent le plus.
3. Pourquoi ils refusent : les trois principales raisons avec une citation chacune, telles qu'écrites.
4. Ce qui ferait basculer un non : les réponses les plus répétées.
5. Une phrase sur ce qu'il faut changer avant de dépenser de l'argent, et quelle compétence le fait (tarification, offre, marketing).
6. Amenez-le à de vraies personnes : les trois principales objections transformées en questions pour de vrais appels, dans le style de ${CLAUDE_SKILL_DIR}/../receipts/conversations.md (sur leur passé, pas votre idée). C'est le vrai travail du panel.

Ensuite, enregistrez le résultat comme SIMULÉ :

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" add --kind demand --status SIMULATED --use PRIVATE --by truth-serum --claim "Taux d'achat du panel simulé (graine <S>)" --number "<achats> sur <répondu>"

Limites honnêtes, dites-les une fois

Ce sont des acheteurs simulés. Ils sont bons pour faire émerger des objections, des segments et du phrasé auxquels vous n'aviez pas pensé, et mauvais pour prédire la conversion réelle : les modèles de langage ont tendance à être complaisants, donc traitez le taux d'achat comme une limite supérieure. Confirmez les grandes décisions avec de vraies personnes (une liste d'attente, une prévente, un pilote, une page d'atterrissage avec un prix) avant de signer quoi que ce soit. N'appelez jamais le panel « validation », « étude de marché » ou « clients », et ne citez jamais un acheteur du panel comme un client : ni dans un argumentaire, une publicité, un deck ou une subvention.

Le briefing que chaque acheteur reçoit

panel.py remplit la fiche dans un modèle fixe (voir BRIEF dans le script) : qui est l'acheteur (nom, âge, segment, revenu, comportement d'achat, une habitude, le doute qui lui vient à l'esprit), l'argumentaire mot pour mot, une instruction de ne pas être complaisant et de ne pas inventer de faits, et le JSON exact à écrire : achats, achats dans le premier mois, un code de raison, la raison dans sa propre voix, son objection principale, ce qui changerait son avis, et quatre réponses de prix (trop bon marché, une affaire, ça devient cher, trop cher). Ne modifiez jamais un briefing pour un acheteur.

Résultat

founder/customer.json, founder/pitch.md, founder/panel/ (fiches, briefings, réponses, résultats). Ensuite : /litmus lit les réponses de prix, /dealbreaker et /signal lisent les objections.