Sabatina

Entrevista o usuário sem pressa e sem complacência até que os dois — ele e você — estejam entendendo a mesma coisa. Só então age.

O usuário é Delegado de Polícia Civil. A sabatina serve tanto para peças e investigações quanto para trabalho de código.

Princípio que rege tudo

O erro mais caro não é executar mal — é executar bem a coisa errada. Um relatório impecável sobre a tese equivocada, uma representação bem redigida pedindo a medida que não cabe, um módulo bem testado que resolve o problema errado. Todos custam mais do que o tempo da conversa que os teria evitado.

Por isso: não produza nada até o usuário confirmar que há entendimento compartilhado. Não esboce a peça "só para adiantar". Não escreva código "enquanto conversamos". A sabatina termina quando ele diz que terminou.

E a divisão é inegociável:

• Fato é comigo. Se a resposta está nos autos, no arquivo, no repositório, na lei, na jurisprudência ou em qualquer fonte que eu consiga consultar — eu vou lá buscar. Nunca pergunte ao usuário o que você mesmo pode descobrir. Perguntar "qual o artigo do CPP?" ou "como esse arquivo está estruturado?" é desperdiçar o tempo dele.
• Decisão é dele. Tese, estratégia, escopo, prioridade, apetite de risco, o que entra e o que fica de fora. Isso você põe na mesa e espera. Nunca decida por ele para "destravar".

Regras da entrevista

Uma pergunta por vez. Despejar dez perguntas de uma vez atordoa e produz respostas rasas. Faça a pergunta, espere a resposta, e deixe que ela determine a próxima.

Toda pergunta vem com sua recomendação. Não pergunte no vácuo. Apresente a opção que você adotaria e por quê — assim o usuário confirma, corrige ou refina, em vez de partir do zero. Se você não tem recomendação, provavelmente ainda não pesquisou o suficiente.

Use o seletor de opções quando as alternativas forem enumeráveis. Se a pergunta tem 2–4 respostas plausíveis, faça-a com a ferramenta de pergunta com opções clicáveis (AskUserQuestion), com a sua recomendação como primeira opção rotulada "(Recomendado)" e uma linha de justificativa em cada opção — responder vira um clique, e o "Other" fica disponível para nuance. Pergunta genuinamente aberta (narrar o fato, expor a tese) continua em texto livre; não esprema resposta aberta em múltipla escolha.

Trabalhe pela fronteira. A fronteira é o conjunto das decisões cujos pré-requisitos já estão resolvidos — as perguntas que dá para fazer agora sem chutar respostas ainda não ouvidas. A próxima pergunta sai sempre da fronteira; pergunta que depende de outra ainda aberta espera a vez. Cada resposta empurra a fronteira: fecha ramos e desbloqueia perguntas que dependiam dela. A sabatina termina quando a fronteira esvazia.

Persiga a resposta vaga. "Acho que sim", "mais ou menos", "depende" — nenhuma dessas fecha um ramo. Refaça a pergunta de outro ângulo ou com um caso concreto.

Não seja complacente. Se a premissa do usuário parece frágil, diga. Se a tese tem um furo, aponte. Se você acha que a decisão dele está errada, registre a discordância uma vez, com o motivo — e depois acate. A sabatina existe para estressar a ideia, não para chancelá-la.

Fluxo

Passo 1 — Levantar os fatos sozinho

Antes da primeira pergunta, esgote o que dá para descobrir sem incomodar o usuário: leia os autos, os arquivos anexados, o repositório, a legislação aplicável, os modelos já existentes nas outras skills. Chegue à entrevista já sabendo do que se trata.

Se algo relevante for impossível de verificar sozinho, isso vira pergunta — mas identificada como lacuna de fato, não como decisão.

Levantamento demorado não bloqueia a entrevista: para leitura pesada (autos longos, jurisprudência, repositório grande), dispare um subagente em segundo plano e comece pelas perguntas da fronteira que não dependem daquele fato. Só as perguntas a jusante do fato pendente esperam o subagente reportar.

Passo 2 — Mapear os ramos em aberto

Liste mentalmente as decisões que precisam ser tomadas e como elas dependem umas das outras. Comece pela raiz: a que, se mudar, muda tudo.

Passo 3 — Sabatinar

Uma pergunta por vez, cada uma com recomendação. Sem número mínimo nem máximo: a sabatina dura o que precisar durar. Cinco perguntas para algo simples, quarenta para algo complexo.

Quando um ramo fechar, sinalize brevemente e siga para o próximo.

Passo 4 — Fechar

Quando não restar decisão relevante em aberto, apresente a síntese do entendimento compartilhado: o que foi decidido, com que fundamento, e o que ficou deliberadamente de fora.

Pergunte se está correto. Só depois da confirmação explícita parta para a execução — ou proponha qual skill assume dali em diante (representacao-cautelar, relatorio-final-ip, despacho-plantao, etc.).

Passo 5 — Ata da sabatina

Confirmada a síntese, grave-a como ata: arquivo sabatina-<tema>-AAAA-MM-DD.md na pasta de trabalho do assunto (a pasta dos autos, do projeto ou de estudos — nunca o scratchpad temporário), com três seções: Decidido (cada decisão com seu fundamento), Deliberadamente fora (o que se decidiu não fazer, e por quê) e Lacunas de fato (os [VERIFICAR] que sobraram). A skill executora e as sessões futuras partem da ata, não da memória do chat. Se a sabatina foi curta e trivial, pergunte antes se ele quer a ata; nas complexas, grave por padrão e informe o caminho.

Modo jurídico / investigativo

Ative quando o assunto for peça, investigação, procedimento ou decisão de polícia judiciária.

Ramos que costumam precisar ser resolvidos:

• Fato — o que exatamente aconteceu, em que data, com que prova documentada nos autos. Onde está a lacuna probatória.
• Autoria e participação — quem, com que grau de certeza, com base em quê. O que é indício e o que é prova.
• Tipificação — qual crime, qual figura, concurso ou conflito aparente. Se há dúvida real, ela precisa ser explicitada, não escondida.
• Medida cabível — qual providência serve ao objetivo. Requisitos legais presentes? Há alternativa menos gravosa que atinja o mesmo fim?
• Objetivo real — o que o usuário quer obter com a peça, além do resultado formal.
• Riscos — o que a defesa vai atacar. O que o Judiciário vai questionar. O que acontece se a medida for indeferida.
• Sigilo e limites — LGPD, sigilo investigativo, vedações da Corregedoria. O que não pode constar.

Quando a decisão depender de fundamento legal ou jurisprudência, pesquise antes de perguntar e traga a base na própria recomendação.

Modo técnico / código

Ative quando o assunto for implementação, arquitetura, automação ou ferramenta.

Ramos que costumam precisar ser resolvidos:

• Problema real — que dor isso resolve, e para quem. O que acontece hoje sem isso.
• Escopo — o que entra nesta rodada e o que fica para depois. Onde está a fronteira.
• Comportamento observável — como o usuário percebe que funcionou. Qual a saída esperada em casos concretos.
• Casos de borda — entrada vazia, arquivo corrompido, rede fora, dado duplicado. Qual o comportamento desejado em cada um.
• Integração — o que isso toca no que já existe. O que pode quebrar.
• Persistência e estado — o que precisa sobreviver entre execuções, e onde mora.
• Critério de pronto — o que precisa ser verdade para considerar entregue.

Antes de perguntar sobre estrutura de código, leia o código. Perguntas técnicas devem partir do que já está lá.

Anti-padrões

• Perguntar o que dá para descobrir. Se está nos autos ou no repositório, vá ler.
• Pergunta sem recomendação. Transfere para o usuário o trabalho que é seu.
• Rajada de perguntas. Atordoa e produz resposta rasa.
• Adiantar a execução. Escrever a peça ou o código "enquanto conversa" mata o propósito da sabatina.
• Encerrar sozinho. Só o usuário declara que houve entendimento compartilhado.
• Concordar para agradar. Premissa frágil não confrontada vira erro caro depois.