painel-do-consumidor

O que painel-do-consumidor faz?

Em vez de adivinhar quais objeções os compradores levantarão, você pergunta a cem compradores simulados, cada um um subagente interpretando um comprador específico extraído do seu cliente-alvo. Você é o moderador. Você nunca responde por um comprador.

Para que serve: encontrar objeções, segmentos, formulação e as perguntas a levar para pessoas reais. O que não é: demanda. Modelos de linguagem tendem a ser concordantes, portanto uma taxa de compra alta aqui é o melhor cenário, não uma previsão, e pode reprovar um plano, mas nunca aprová-lo.

Leia ${CLAUDE_SKILL_DIR}/../receipts/rules.md primeiro.

O que o usuário digitou após /truth-serum: $ARGUMENTS

A ferramenta

Toda a contabilidade passa pelo panel.py na pasta desta skill:

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

Abaixo, PANEL significa exatamente isso. Se o caminho não for expandido, use o diretório base que o Claude Code imprimiu para esta skill. O estado fica em founder/panel/.

Passo 1: o cliente-alvo

Escreva founder/customer.json (formato: customer.example.json nesta pasta):

• business e target: quem é o cliente, em uma linha específica.
• segments: 2 a 4 grupos com uma share e uma faixa de income [baixo, alto].
• behaviours: 4 a 8 comportamentos de compra com uma share e uma linha how (cliente diário regular, caçador de ofertas, lê todas as avaliações, fiel a um concorrente...).
• objections: as 4 a 8 dúvidas que esse tipo de comprador realmente tem.
• habits (opcional): linhas de contexto cotidiano que tornam um comprador concreto.

Baseie-se em algo real. Use o que o usuário sabe sobre seus clientes e, se /ground-truth foi executado, as reclamações em founder/competitors.md. Se o usuário tiver dados reais de clientes (notas de ligações em founder/evidence/calls/, avaliações, respostas de pesquisas), prefira-os aos seus palpites e diga quais partes são palpites.

Se o alvo for um pequeno conjunto de empresas (algumas centenas de firmas, não um mercado de massa), diga claramente que cinco ligações reais ensinarão mais do que este painel, e ofereça /receipts e seu guia de ligações primeiro. Execute o painel apenas para aprimorar as perguntas. Mostre ao usuário o perfil em poucas linhas e deixe-o corrigi-lo antes de distribuir as cartas: um cliente errado torna todo o painel errado.

Passo 2: o discurso de vendas

Escreva founder/pitch.md: o que um comprador realmente veria. O produto, o preço, onde e como obtê-lo, qualquer oferta de lançamento. Três a seis linhas simples, sem superlativos, nada que a empresa não possa entregar. Todo comprador vê exatamente isso.

Passo 3: distribuir e executar

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

init distribui as cartas de persona (mesma semente, mesmas cartas; a semente é registrada). prompts escreve um briefing por comprador e os lista em ondas de 10. Para cada onda, envie UMA mensagem com uma chamada de ferramenta Agent por comprador naquela onda (a ferramenta Agent é chamada de Task em versões mais antigas do Claude Code):

• subagent_type: general-purpose
• description: painel <id>
• prompt: Leia <caminho do briefing> e siga-o exatamente. Ele é seu briefing completo.

Aguarde a onda inteira antes da próxima. O Claude Code executa cerca de 10 chamadas de ferramenta por vez por padrão, então 100 compradores são 10 ondas. Após a última onda:

PANEL check      # lista respostas ausentes ou quebradas
PANEL prompts    # reescreve briefings apenas para essas; execute-os mais uma vez
PANEL tally

Se um comprador imprimiu seu JSON em sua resposta em vez de escrever o arquivo (acontece), arquive sua própria resposta com PANEL save <id> e a resposta na entrada padrão; save recusa qualquer coisa que não seja uma resposta válida. Um comprador que falhar duas vezes é excluído e contabilizado nos resultados. Nunca escreva uma resposta para um comprador você mesmo.

Antes de uma execução com 100 compradores, informe ao usuário que são 100 chamadas de subagentes e sugira --quick (20 compradores) para uma primeira olhada. Os subagentes escrevem um arquivo cada em founder/panel/answers/; no modo de permissão padrão, isso é uma aprovação por arquivo, então sugira o modo accept-edits (Shift+Tab) para a execução.

Passo 4: leia para o usuário

PANEL tally escreve founder/panel/results.md e results.json. Entregue ao usuário:

0. A verdade dura: o motivo mais forte pelo qual os compradores recusam, em uma frase, e um lembrete de que a taxa de compra é simulada e um limite superior.
1. O título: "40 compram · 60 recusam (simulado)" e a taxa de compra.
2. Quem compra e quem não compra: as linhas de segmento e comportamento que mais diferem.
3. Por que recusam: os três principais motivos com uma citação cada, conforme escritos.
4. O que faria um 'não' virar 'sim': as respostas mais repetidas.
5. Uma frase sobre o que mudar antes de gastar dinheiro, e qual skill faz isso (precificação, oferta, marketing).
6. Leve para pessoas reais: as três principais objeções transformadas em perguntas para ligações reais, no estilo de ${CLAUDE_SKILL_DIR}/../receipts/conversations.md (sobre o passado deles, não sobre sua ideia). Esse é o verdadeiro trabalho do painel.

Em seguida, registre o resultado como SIMULADO:

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" add --kind demand --status SIMULADO --use PRIVADO --by truth-serum --claim "Taxa de compra do painel simulado (semente <S>)" --number "<compras> de <respondidos>"

Limites honestos, diga-os uma vez

Estes são compradores simulados. Eles são bons em trazer à tona objeções, segmentos e formulações que você não havia pensado, e ruins em prever conversão real: modelos de linguagem tendem a ser concordantes, portanto trate a taxa de compra como um limite superior. Confirme as grandes conclusões com pessoas reais (uma lista de espera, uma pré-venda, um piloto, uma página de destino com um preço) antes de assinar qualquer coisa. Nunca chame o painel de "validação", "pesquisa de mercado" ou "clientes", e nunca cite um comprador do painel como cliente: não em um discurso de vendas, um anúncio, uma apresentação ou uma subvenção.

O briefing que todo comprador recebe

panel.py preenche a carta em um modelo fixo (veja BRIEF no script): quem é o comprador (nome, idade, segmento, renda, comportamento de compra, um hábito, a dúvida que vem à mente), o discurso de vendas palavra por palavra, uma instrução para não ser concordante e não inventar fatos, e o JSON exato a ser escrito: compras, compras no primeiro mês, um código de motivo, o motivo na própria voz do comprador, sua principal objeção, o que mudaria sua opinião e quatro respostas de preço (muito barato, uma pechincha, ficando caro, muito caro). Nunca edite um briefing para um comprador.

Resultados

founder/customer.json, founder/pitch.md, founder/panel/ (cartas, briefings, respostas, resultados). Em seguida: /litmus lê as respostas de preço, /dealbreaker e /signal leem as objeções.