truth-serum

Was macht truth-serum?

Statt zu raten, welche Einwände Käufer erheben werden, fragen Sie hundert simulierte, von denen jeder ein Sub-Agent ist, der einen bestimmten, aus Ihrem Zielkunden abgeleiteten Käufer spielt. Sie sind der Moderator. Sie antworten niemals für einen Käufer.

Wofür das gedacht ist: Einwände, Segmente, Formulierungen und die Fragen zu finden, die man echten Menschen stellen sollte. Was es nicht ist: Nachfrage. Sprachmodelle neigen zur Zustimmung, daher ist eine hohe Kaufrate hier der Best-Case, keine Prognose, und es kann einen Plan scheitern lassen, aber nie bestehen.

Lesen Sie zuerst ${CLAUDE_SKILL_DIR}/../receipts/rules.md.

Was der Benutzer nach /truth-serum eingegeben hat: $ARGUMENTS

Das Tool

Die gesamte Buchhaltung erfolgt über panel.py im Ordner dieses Skills:

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

Im Folgenden bedeutet PANEL genau das. Wenn der Pfad nicht expandiert ist, verwenden Sie das Basisverzeichnis, das Claude Code für diesen Skill druckt. Der Zustand befindet sich in founder/panel/.

Schritt 1: Der Zielkunde

Schreiben Sie founder/customer.json (Form: customer.example.json in diesem Ordner):

• business und target: Wer der Kunde ist, in einem bestimmten Satz.
• segments: 2 bis 4 Gruppen mit einem share und einem income-Bereich [low, high].
• behaviours: 4 bis 8 Kaufverhalten mit einem share und einer how-Zeile (täglich, regelmäßig, Schnäppchenjäger, liest jede Bewertung, loyal zu einem Wettbewerber ...).
• objections: Die 4 bis 8 Zweifel, die diese Art von Käufer wirklich hat.
• habits (optional): Alltagskontextzeilen, die einen Käufer konkret machen.

Verankern Sie es in etwas Realem. Verwenden Sie, was der Benutzer über seine Kunden weiß, und falls /ground-truth ausgeführt wurde, die Beschwerden in founder/competitors.md. Wenn der Benutzer echte Kundendaten hat (Gesprächsnotizen in founder/evidence/calls/, Rezensionen, Umfrageantworten), ziehen Sie diese Ihren Vermutungen vor und sagen Sie, welche Teile Vermutungen sind.

Wenn das Ziel eine kleine Gruppe von Unternehmen ist (einige hundert Firmen, kein Massenmarkt), sagen Sie klar, dass fünf echte Anrufe mehr lehren als dieses Panel, und bieten Sie zuerst /receipts und seinen Gesprächsleitfaden an. Führen Sie das Panel nur durch, um die Fragen zu schärfen. Zeigen Sie dem Benutzer das Profil in wenigen Zeilen und lassen Sie es korrigieren, bevor Sie fortfahren: Ein falscher Kunde macht das gesamte Panel falsch.

Schritt 2: Der Pitch

Schreiben Sie founder/pitch.md: Was ein Käufer tatsächlich sehen würde. Das Produkt, der Preis, wo und wie man es bekommt, etwaige Einführungsangebote. Drei bis sechs klare Zeilen, keine Übertreibungen, nichts, was das Unternehmen nicht liefern kann. Jeder Käufer sieht genau dies.

Schritt 3: Austeilen und ausführen

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

init teilt die Persona-Karten aus (gleicher Seed, gleiche Karten; der Seed wird aufgezeichnet). prompts schreibt eine Aufgabenbeschreibung pro Käufer und listet sie in Wellen von 10 auf. Senden Sie für jede Welle EINE Nachricht mit einem Agent-Tool-Aufruf pro Käufer in dieser Welle (das Agent-Tool heißt in älteren Claude Code Versionen Task):

• subagent_type: general-purpose
• description: panel <ID>
• prompt: Lies <Aufgabenpfad> und befolge ihn genau. Er ist deine gesamte Aufgabenstellung.

Warten Sie auf die gesamte Welle, bevor Sie mit der nächsten beginnen. Claude Code führt standardmäßig etwa 10 Tool-Aufrufe gleichzeitig aus, also sind 100 Käufer 10 Wellen. Nach der letzten Welle:

PANEL check      # listet fehlende oder fehlerhafte Antworten auf
PANEL prompts    # schreibt Aufgabenbeschreibungen nur für diese neu; führen Sie sie einmal erneut aus
PANEL tally

Wenn ein Käufer sein JSON in seiner Antwort anstatt in der Datei ausgegeben hat (das kommt vor), erfassen Sie seine Antwort mit PANEL save <ID> und der Antwort über stdin; save lehnt alles ab, was keine gültige Antwort ist. Ein Käufer, der zweimal scheitert, wird ausgelassen und in den Ergebnissen gezählt. Schreiben Sie niemals selbst eine Antwort für einen Käufer.

Informieren Sie den Benutzer vor einem Lauf mit 100 Käufern, dass es 100 Sub-Agent-Aufrufe sind, und schlagen Sie --quick (20 Käufer) für einen ersten Eindruck vor. Sub-Agents schreiben jeweils eine Datei in founder/panel/answers/; im Standard-Berechtigungsmodus ist das eine Genehmigung pro Datei, also schlagen Sie den accept-edits-Modus (Umschalt+Tab) für den Lauf vor.

Schritt 4: Dem Benutzer vorlesen

PANEL tally schreibt founder/panel/results.md und results.json. Geben Sie dem Benutzer:

0. Die harte Wahrheit: Der stärkste Grund, warum Käufer ablehnen, in einem Satz, und eine Erinnerung daran, dass die Kaufrate simuliert und eine obere Schranke ist.
1. Die Schlagzeile: „40 kaufen · 60 lehnen ab (simuliert)“ und die Kaufrate.
2. Wer kauft und wer nicht: Die Segment- und Verhaltenszeilen, die sich am stärksten unterscheiden.
3. Warum sie ablehnen: Die drei häufigsten Gründe mit jeweils einem Zitat, wie geschrieben.
4. Was ein Nein umkehren würde: Die am häufigsten wiederholten Antworten.
5. Ein Satz darüber, was geändert werden sollte, bevor Geld ausgegeben wird, und welcher Skill das erledigt (Preisgestaltung, Angebot, Marketing).
6. An echte Menschen weitergeben: Die drei häufigsten Einwände, in Fragen für echte Gespräche umgewandelt, im Stil von ${CLAUDE_SKILL_DIR}/../receipts/conversations.md (über ihre Vergangenheit, nicht über Ihre Idee). Das ist die eigentliche Aufgabe des Panels.

Protokollieren Sie dann das Ergebnis als SIMULATED:

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" add --kind demand --status SIMULATED --use PRIVATE --by truth-serum --claim "Simulierte Panel-Kaufrate (Seed <S>)" --number "<Käufe> von <Beantworteten>"

Ehrliche Grenzen, einmal ausgesprochen

Dies sind simulierte Käufer. Sie sind gut darin, Einwände, Segmente und Formulierungen aufzudecken, an die Sie nicht gedacht haben, und schlecht darin, reale Konversionen vorherzusagen: Sprachmodelle neigen zur Zustimmung, also behandeln Sie die Kaufrate als obere Schranke. Bestätigen Sie die großen Erkenntnisse mit echten Menschen (einer Warteliste, einem Vorverkauf, einem Pilotprojekt, einer Landingpage mit Preis), bevor Sie irgendetwas unterschreiben. Nennen Sie das Panel niemals „Validierung“, „Marktforschung“ oder „Kunden“ und zitieren Sie niemals einen Panel-Käufer als Kunden: nicht in einem Pitch, einer Anzeige, einem Deck oder einem Zuschussantrag.

Die Aufgabenstellung, die jeder Käufer erhält

panel.py füllt die Karte in eine feste Vorlage (siehe BRIEF im Skript): Wer der Käufer ist (Name, Alter, Segment, Einkommen, Kaufverhalten, eine Gewohnheit, der Zweifel, der ihm in den Sinn kommt), der Pitch Wort für Wort, eine Anweisung, nicht zustimmend zu sein und keine Tatsachen zu erfinden, und das genaue JSON, das geschrieben werden soll: Käufe, Einkäufe im ersten Monat, ein Grundcode, der Grund in seiner eigenen Stimme, sein Haupteinwand, was seine Meinung ändern würde, und vier Preisantworten (zu billig, ein Schnäppchen, wird teuer, zu teuer). Bearbeiten Sie niemals eine Aufgabenstellung für einen bestimmten Käufer.

Ausgabe

founder/customer.json, founder/pitch.md, founder/panel/ (Karten, Aufgaben, Antworten, Ergebnisse). Als Nächstes: /litmus liest die Preisantworten, /dealbreaker und /signal lesen die Einwände.