🧪 Análise e síntese
Os comandos da família 03: decompor problemas, construir modelos, separar causa de correlação — e simplificar sem perder a essência.
🔬 /analyze — decomponha o problema
Divide o problema em partes analisáveis com método explícito. A qualidade de uma análise mora na decomposição: problema cortado no eixo errado produz respostas elegantes para a pergunta errada.
✓ Decomposição boa
- ✓Partes que juntas cobrem o problema inteiro (MECE quando possível).
- ✓Cada parte com método próprio declarado ("medirei X por Y").
✗ Decomposição ruim
- ✗Cortes por departamento interno em vez de pela estrutura do problema.
- ✗Sobreposição: a mesma causa aparece em três "partes diferentes".
🎯 Copie e rode
/analyze o problema de; decomponha com método explícito e indique como medir cada parte
Como verificar: as partes somadas explicam o todo, sem buracos nem sobreposições — cada uma com plano de medição.
🪢 /synthesize — integre sem apagar divergências
Integra achados múltiplos numa visão coerente — mantendo conflitos visíveis. Sintetizar não é tirar a média das opiniões: é organizar onde concordam e preservar onde divergem.
🪢 O teste da síntese honesta
Depois de sintetizar, pergunte:
- •"As fontes que discordavam ainda aparecem aqui?" Se não, você fez média, não síntese.
- •"Alguém que só lesse a síntese saberia onde está a incerteza?"
💡 Dica prática
Combine com pesquisa: /chain(/research -> /synthesize). A síntese herda as lacunas do research — verifique se elas sobreviveram à integração.
🎯 Copie e rode
/synthesize os achados abaixo em uma visão única; mantenha visíveis os pontos em conflito:
Como verificar: visão única coerente + seção explícita "onde as fontes divergem".
🧠 /model — crie o modelo mental
Constrói um modelo explicativo: variáveis, relações entre elas e a dinâmica resultante. Novo aqui? Um modelo mental é uma teoria miniatura de como o sistema funciona — boa o bastante para prever o que acontece se você mexer numa peça.
Análise + estrutura viram modelo; modelo bom antecipa consequências antes de você gastá-las.
🎯 Copie e rode
/model de como funciona; variáveis, relações e o que prevê cada relação
Como verificar: dá para apontar uma variável e receber a previsão de efeito em cadeia — senão é lista de fatos, não modelo.
🏗️ /framework — construa a estrutura analítica
Cria uma estrutura reutilizável: dimensões, eixos e critérios para analisar qualquer caso da mesma família. É a diferença entre resolver um problema e construir capacidade de resolver a classe inteira.
Defina as dimensões
Os eixos que importam para julgar casos dessa família (impacto × esforço, risco × reversibilidade…).
Fixe escalas e critérios
O que é "alto impacto"? Número ou exemplo âncora — senão cada pessoa mede com régua própria.
Teste em casos conhecidos
Um framework que classifica errado casos óbvios precisa ser revisado antes de uso real.
🎯 Copie e rode
/framework para priorizar; dimensões, escalas e teste em 3 casos conhecidos
Como verificar: aplicado aos casos-teste, o framework reproduz as decisões que você considera certas — e revela por quê.
🎯 /causes — distinga correlação de causa
Separa correlação de causalidade propondo mecanismos causais e testando explicações alternativas. Correlação é duas coisas andando juntas; causa é uma empurrando a outra.
✓ Pensamento causal
- ✓"Vendas subiram porque X" acompanhado do mecanismo (como X empurra vendas).
- ✓Explicação rival testada: "ou foi sazonalidade?" — checada antes de crer.
✗ Ilusão correlacional
- ✗"Postamos mais e vendemos mais, então posts causam vendas" — sem descartar fator de confusão (ex.: sazonalidade).
- ✗Inverter causa e efeito: talvez vendas altas é que permitem postar mais.
Novo aqui? Um fator de confusão é uma terceira variável que causa as duas coisas correlacionadas (verão aumenta vendas de sorvete E de afogamentos — sorvete não afoga ninguém). Procurar o candidato a confusão é o primeiro movimento de /causes.
🎯 Copie e rode
/causes de; proponha mecanismo, liste fatores de confusão e testes para separar causa de coincidência
Como verificar: mecanismo plausível + rival desqualificada COM evidência, não por conveniência narrativa.
🌊 /secondorder — veja os efeitos indiretos
Rastreia as consequências das consequências — efeitos de segunda ordem que chegam atrasados, maiores e quase nunca no plano.
Efeito imediato — o que todo mundo vê
Desconto agressivo → volume sobe na semana seguinte. Ótimo, comemore rápido.
Efeito indireto — o que chega depois
Clientes aprendem a esperar desconto → compra plena cai → margem estrutural cai. O volume da semana 1 pagou o prejuízo do trimestre.
Feedback — o sistema reage a você
Concorrentes copiam o desconto → categoria vira commodity → todos ganham menos. O /secondorder força essa camada antes da aposta.
🎯 Copie e rode
/secondorder da decisão de; efeitos em 1ª, 2ª ordem e feedbacks, com horizonte de chegada estimado
Como verificar: pelo menos um efeito indireto que você NÃO tinha considerado — esse é o valor do comando.
⚖️ /tradeoffs + /constraints — concessões e restrições
/tradeoffs explicita o que cada opção sacrifica; /constraints mapeia as restrições reais — tempo, orçamento, gente, regulação. Juntos, desenham o espaço de opções verdadeiramente disponível.
✓ Proposta adulta
- ✓"Escolher velocidade custa profundidade de teste — assumimos esse risco assim."
- ✓Restrição dura tratada como fronteira de design, não como detalhe.
✗ Proposta fantasia
- ✗"Sem desvantagens" — frase que sempre esconde o custo em outro lugar.
- ✗Restrições descobertas no meio da execução, quando já custaram caro.
🎯 Copie e rode
/tradeoffs /constraints para; o que sacrificamos, quais restrições são duras e o que é negociável
Como verificar: cada tradeoff com dono do risco aceito; restrições duras separadas das negociáveis.
✂️ /leverage + /simplify — alavanca e essência
Fecha a trilha com os dois comandos mais lucrativos da família: encontrar o ponto de alavancagem (pouco esforço, efeito desproporcional) e simplificar reduzindo complexidade sem perder a função essencial.
🪝 Como achar alavancas
- Pergunte: qual gargalo, se movido 10%, move o resultado inteiro?
- Procure passos repetidos manualmente — candidatos naturais a alavanca.
- Confirme com dados: alavanca de verdade mostra sensibilidade no número, não no discurso.
💡 Dica prática
Antes de adicionar qualquer coisa ao processo, rode /simplify. Metade das melhorias que parecem necessárias são apenas complexidade compensando outra complexidade.
🎯 Copie e rode
/leverage /simplify no processo de; ache os 2 pontos de maior alavancagem e corte o que não sustenta a função essencial
Como verificar: lista curta de alavancas com sensibilidade quantificada + itens cortados com justificativa de função preservada.
Auto-verificação rápida (opcional): "postamos mais e vendemos mais, então posts geram vendas." O que falta?
🎓 Resumo do Módulo
Próximo Módulo:
3.1 - Red team e robustez — agora que você analisa bem, aprenda a atacar suas próprias conclusões antes dos outros.