truth-serum

¿Qué hace truth-serum?

En lugar de adivinar qué objeciones plantearán los compradores, preguntas a cien simulados, cada uno es un subagente que interpreta a un comprador específico extraído de tu cliente objetivo. Tú eres el moderador. Nunca respondes por un comprador.

Para qué sirve: encontrar objeciones, segmentos, redacción y las preguntas para llevar a personas reales. Lo que no es: demanda. Los modelos de lenguaje tienden a ser complacientes, por lo que una tasa de compra alta aquí es el mejor caso, no una predicción, y puede descartar un plan pero nunca aprobarlo.

Lee primero ${CLAUDE_SKILL_DIR}/../receipts/rules.md.

Lo que el usuario escribió después de /truth-serum: $ARGUMENTS

La herramienta

Todo el registro contable pasa por panel.py en la carpeta de esta habilidad:

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

A continuación, PANEL significa exactamente eso. Si la ruta no se expande, usa el directorio base que Claude Code imprimió para esta habilidad. El estado se guarda en founder/panel/.

Paso 1: el cliente objetivo

Escribe founder/customer.json (forma: customer.example.json en esta carpeta):

• business, y target: quién es el cliente, en una línea específica.
• segments: de 2 a 4 grupos con una share y un rango de income [bajo, alto].
• behaviours: de 4 a 8 comportamientos de compra con una share y una línea how (comprador diario habitual, cazador de ofertas, lee cada reseña, leal a un competidor...).
• objections: las 4 a 8 dudas que este tipo de comprador realmente tiene.
• habits (opcional): líneas de contexto cotidiano que hacen concreto a un comprador.

Fundaméntalo en algo real. Usa lo que el usuario sabe sobre sus clientes, y si /ground-truth se ejecutó, las quejas en founder/competitors.md. Si el usuario tiene datos reales de clientes (notas de llamadas en founder/evidence/calls/, reseñas, respuestas de encuestas), prefierelos a tus suposiciones y di qué partes son suposiciones.

Si el objetivo es un pequeño conjunto de empresas (unos cientos de firmas, no un mercado masivo), di claramente que cinco llamadas reales enseñarán más que este panel, y oferta /receipts y su guía de llamadas primero. Ejecuta el panel solo para agudizar las preguntas. Muestra al usuario el perfil en unas pocas líneas y permite que lo corrija antes de continuar: un cliente equivocado hace que todo el panel sea incorrecto.

Paso 2: el discurso

Escribe founder/pitch.md: lo que un comprador realmente vería. El producto, el precio, dónde y cómo obtenerlo, cualquier oferta inicial. De tres a seis líneas simples, sin superlativos, nada que el negocio no pueda cumplir. Cada comprador ve exactamente esto.

Paso 3: repartir y ejecutar

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

init reparte las tarjetas de persona (misma semilla, mismas tarjetas; la semilla se registra). prompts escribe un brief por comprador y los lista en oleadas de 10. Para cada oleada, envía UN mensaje con una llamada a la herramienta Agent por comprador en esa oleada (la herramienta Agent se llama Task en versiones anteriores de Claude Code):

• subagent_type: general-purpose
• description: panel <id>
• prompt: Lee <ruta del brief> y síguelo exactamente. Es todo tu brief.

Espera a que termine toda la oleada antes de la siguiente. Claude Code ejecuta alrededor de 10 llamadas a la herramienta a la vez de forma predeterminada, por lo que 100 compradores son 10 oleadas. Después de la última oleada:

PANEL check      # lista respuestas faltantes o rotas
PANEL prompts    # reescribe los briefs solo para esas; ejecútalos una vez más
PANEL tally

Si un comprador imprimió su JSON en su respuesta en lugar de escribir el archivo (ocurre), ingresa su propia respuesta con PANEL save <id> y la respuesta en stdin; save rechaza cualquier cosa que no sea una respuesta válida. Un comprador que falla dos veces se omite y se cuenta en los resultados. Nunca escribas una respuesta por un comprador tú mismo.

Antes de una ejecución de 100 compradores, dile al usuario que son 100 llamadas a subagentes y sugiere --quick (20 compradores) para una primera visualización. Los subagentes escriben un archivo cada uno en founder/panel/answers/; en el modo de permisos predeterminado, eso es una aprobación por archivo, así que sugiere el modo aceptar-ediciones (Shift+Tab) para la ejecución.

Paso 4: léelo al usuario

PANEL tally escribe founder/panel/results.md y results.json. Dale al usuario:

0. La verdad dura: la razón más fuerte por la que los compradores pasan, en una oración, y un recordatorio de que la tasa de compra es simulada y un límite superior.
1. El titular: "40 compran · 60 pasan (simulado)" y la tasa de compra.
2. Quién compra y quién no: las filas de segmento y comportamiento que más difieren.
3. Por qué pasan: las tres razones principales con una cita cada una, tal como están escritas.
4. Qué haría cambiar un no: las respuestas más repetidas.
5. Una oración sobre qué cambiar antes de gastar dinero, y qué habilidad lo hace (precios, oferta, marketing).
6. Llévalo a personas reales: las tres objeciones principales convertidas en preguntas para llamadas reales, en el estilo de ${CLAUDE_SKILL_DIR}/../receipts/conversations.md (sobre su pasado, no tu idea). Ese es el trabajo real del panel.

Luego registra el resultado como SIMULATED:

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" add --kind demand --status SIMULATED --use PRIVATE --by truth-serum --claim "Tasa de compra del panel simulado (semilla <S>)" --number "<compras> de <respondidos>"

Límites honestos, dilos una vez

Estos son compradores simulados. Son buenos para sacar a la luz objeciones, segmentos y redacción en los que no habías pensado, y malos para predecir la conversión real: los modelos de lenguaje tienden a ser complacientes, así que trata la tasa de compra como un límite superior. Confirma las grandes conclusiones con personas reales (una lista de espera, una preventa, un piloto, una página de destino con un precio) antes de firmar algo. Nunca llames al panel "validación", "investigación de mercado" o "clientes", y nunca cites a un comprador del panel como un cliente: no en un discurso, un anuncio, una presentación o una subvención.

El brief que recibe cada comprador

panel.py llena la tarjeta en una plantilla fija (ver BRIEF en el script): quién es el comprador (nombre, edad, segmento, ingresos, comportamiento de compra, un hábito, la duda que viene a la mente), el discurso palabra por palabra, una instrucción para no ser complaciente y no inventar hechos, y el JSON exacto para escribir: compras, compras en el primer mes, un código de razón, la razón en su propia voz, su objeción principal, qué cambiaría su opinión y cuatro respuestas de precio (demasiado barato, una ganga, se vuelve caro, demasiado caro). Nunca edites un brief para un comprador.

Salida

founder/customer.json, founder/pitch.md, founder/panel/ (tarjetas, briefs, respuestas, resultados). Siguiente: /litmus lee las respuestas de precio, /dealbreaker y /signal leen las objeciones.