--- name: verificacao-posts description: > Verificação adversarial completa de posts do @psi.entre.mentes antes da publicação. Dispara sempre que o usuário mencionar "verifica", "checa", "revisa", "valida", "testa", "adversarial", "checklist", "DOI", "pode publicar?", "tá pronto?", "confere as referências", "roda a verificação", "faz o teste", "checa os DOIs", "revisa o post". Também dispara quando o usuário entregar um rascunho de post e perguntar se está bom. NUNCA declarar um post "pronto para publicar" sem ter completado este skill. NÃO use para criação de posts (use fabrica-de-posts). --- # Verificação Adversarial — @psi.entre.mentes Este skill existe porque o perfil tem compromisso público com rigor. Cada erro factual, DOI inventado ou generalização indevida que passa custa credibilidade com um público de psicólogos que sabe checar fontes. O custo de publicar com erro é maior que o custo de atrasar um post. Se o post passou pelo NotebookLM (2ª passagem): a correspondência claim-fonte já foi checada. Focar em calibração retórica, proporcionalidade, transposição. Se o post NÃO passou pelo NotebookLM: verificar fidelidade às fontes completa. Perguntar ao usuário: "Esse post passou pelo NotebookLM?" ## Etapa 1: Verificação bibliográfica Para CADA referência citada, executar na ordem: 1. IDENTIFICAÇÃO: autores, ano, periódico, título 2. DOI: triangulação determinística INDIVIDUAL, não web search aberto: `https://api.crossref.org/works/` + `https://api.openalex.org/works/doi:`, conferindo título + 1º autor + ano. Regra 2-de-3: em divergência, Semantic Scholar (`https://api.semanticscholar.org/graph/v1/paper/DOI:?fields=title,authors,year,journal`) como árbitro; se a API do Semantic Scholar barrar o leitor automatizado (erro 402, comportamento já observado em sessão Cowork), o terceiro sinal vira busca web por título + 1º autor. Falha de rede de um índice NUNCA rebaixa a referência sozinha. NÃO inferir DOI por memória. NÃO assumir que está correto. DOI que não resolve: buscar pelo título literal (`https://api.crossref.org/works?query.bibliographic=&filter=type:journal-article&rows=3`; o filtro `type:journal-article` é obrigatório, sem ele a API devolve registros de peer review com título quase idêntico ao do artigo) e reportar o DOI correto ou a ausência. 2-bis. RETRATAÇÃO (BLOQUEANTE): na mesma resposta das APIs, conferir `update-to` no Crossref (base Retraction Watch integrada) e `is_retracted` no OpenAlex. Referência retratada = BLOQUEANTE absoluto. Expression of concern = BLOQUEANTE se sustenta claim central; caso contrário, exigir flag explícita no post/aprofundamento. 3. **MODO 7-bis — Metadata hallucination** (portado de verificacao-artigo, Camada 1): DOI resolver corretamente NÃO basta. Após confirmar que o DOI resolve, checar contra a fonte original: título exato (não só parecido), revista exata, volume, número e páginas. Qualquer divergência de metadados é BLOQUEANTE, mesmo com DOI correto. LLMs alucinam metadata em torno de DOIs reais, esse é o vetor mais sutil de erro. 4. TIPO: artigo peer-reviewed | preprint | livro | capítulo | divulgação Para livros: registrar "verificação conceitual" em vez de DOI. 5. DISTÂNCIA ao tema clínico: A = psicologia clínica direta B = psicopatologia sem clínica direta C = neurociência cognitiva/computacional (justificar inclusão) D = neurociência teórica (justificar inclusão) E = área sem ponte (justificar ou recomendar remoção) 6. SOBREPOSIÇÃO: se duas referências apontam pro mesmo artigo, registrar explicitamente como intencional+justificada, não como erro. 7. ÂNCORA POR CITAÇÃO (fidelidade de alegação, versão leve portada da verificacao-artigo/ARS): cada referência num slide carrega o achado específico que sustenta (N, efeito, página ou seção). DOI existir não significa claim suportado. Sem âncora identificável = atenção; âncora contradita pela fonte = BLOQUEANTE. 8. CHECAGEM TEMPORAL anti-anacronismo: a fonte é anterior ao que ela supostamente sustenta? Citação de 2024 não documenta evento de 2026. Anacronismo = BLOQUEANTE. ## Etapa 2: Verificação de claims Para cada afirmação factual nos slides e legenda: - A claim corresponde ao conteúdo real da fonte citada? - N amostral, tipo de estudo, tamanho de efeito estão corretos? - A generalização é proporcional à evidência? (ex: estudo com N=30 de universitários americanos apresentado como "a ciência mostra que...") - Dados de amostra WEIRD identificados como tal? - Preprints não retratados apresentados como se fossem peer-reviewed? **Classificação obrigatória de cada par claim ↔ fonte** (lógica de três classes portada do Academic Research Skills, Cheng-I Wu, ARS v3.11.1, CC BY-NC, integrado em 09-10/06/2026; usada também pelo `verify_citations.py` v3.0): - **SUSTENTADA**: a fonte sustenta o claim de forma direta. Conteúdo, direção do efeito, escopo e qualificadores batem. - **NÃO SUSTENTADA**: a fonte existe e foi lida, mas não diz o que o post afirma que ela diz. Inclui: extrapolação além do escopo do estudo, troca de sinal (efeito positivo virou negativo), atribuição de achado a um autor que não é o autor real, citação de revisão pra reivindicar achado empírico que a revisão só comenta. - **NÃO RESOLVÍVEL**: não dá pra checar agora. Inclui: paywall sem acesso institucional via baixar-papers, capítulo de livro físico sem cópia, fonte em idioma que o pipeline não cobre, ou claim genérico demais pra mapear num trecho específico. Qualquer claim NÃO SUSTENTADA é bloqueante. Qualquer claim NÃO RESOLVÍVEL precisa de marcação explícita no output (não confundir com SUSTENTADA por omissão). ## Etapa 3: Sobreposição entre itens Apenas para listicles com 10+ itens: - Listar TODOS os pares que possam parecer redundantes ao leitor - Para cada par, classificar: SOBREPOSIÇÃO PROBLEMÁTICA → propor correção concreta COMPLEMENTAR → justificar por que são distintos - Critério: compartilham referência, área ou autor principal? Se sim, a distinção precisa estar explícita no texto do slide. ## Etapa 4: Teste adversarial com 3 críticos Simular três perfis e registrar vulnerabilidades de cada: CRÍTICO 1 — Acadêmico rigoroso "As referências sustentam as claims? Dados estão corretos? Falta autor essencial? A metodologia dos estudos citados é sólida?" CRÍTICO 2 — Clínico cético "Isso muda algo na minha prática? Ou é jargão bonito para coisas que já sei? O post fala COM clínicos ou SOBRE clínicos?" CRÍTICO 3 — Especialista da área importada (quando aplicável) "O conceito foi usado corretamente? A analogia se sustenta no formalismo original? Controvérsias da área de origem foram mencionadas?" Para cada vulnerabilidade: - Severidade: ALTA / MÉDIA / BAIXA - Correção proposta concreta - Se a vulnerabilidade é limitação do formato (50 palavras por slide não permitem nuance completa) ou do estado da literatura, classificar como FRAQUEZA ACEITA com justificativa. ## Etapa 4.5: Devil's Advocate (argumento central) Portado de verificacao-artigo (Camada 5), versão enxuta pra post. Post não tem ciclo de rebuttal autor↔revisor, então o DA aqui é one-shot e produz só um relatório, não um diálogo. 1. Identificar o argumento central do post em uma frase. Se o post é listicle sem tese unificadora, identificar o sentido de fundo que o slide de fechamento crava (regra do bottom-line em regras-comuns). 2. Gerar o melhor contra-argumento possível, fundamentado em literatura real. Não chute, não strawman, não "alguns argumentam que". 3. Avaliar o contra-argumento contra o post pelo concession threshold (1-5): - 5: contra-argumento traz evidência empírica que derruba o post. - 4: contra-argumento mostra que o post interpreta mal a literatura. - 3: contra-argumento é teórico legítimo, não conclusivo. - 2: contra-argumento é reformulação ou crítica vaga sem evidência. - 1: contra-argumento é apelo à autoridade ou ao consenso. 4. Score ≥4 é gatilho de revisão obrigatória: o post precisa, no mínimo, reconhecer a objeção (mesmo que mantenha a tese). Score 3 entra como fraqueza aceita explicitada. Score ≤2 é registrado e descartado. O DA não modifica o post. Só produz a entrada `devils_advocate` no output da Etapa 6. ## Etapa 5: Calibração retórica Checklist binário (SIM/NÃO para cada item): [ ] Há padrões de escrita de IA? (tríades, "Não é X. É Y." repetido) [ ] Há "genuinamente", "notavelmente", "de fato", "é importante notar"? [ ] Há travessões (—)? [ ] O ritmo varia entre slides ou está monótono? [ ] Registro semi-informal com autoridade? (não academicismo, não coloquial) [ ] Parágrafos dentro de 50-80 palavras por slide? [ ] Algum slide abre com "Em [ano], [pesquisador] demonstrou..."? [ ] O fechamento evita frase de efeito polida demais? Cada item NÃO-conforme deve ter justificativa e correção proposta. ## Etapa 6: Output Gerar relatório estruturado com: 1. STATUS: ✅ Aprovado | ⚠️ Aprovado com ressalvas | ❌ Reprovar para revisão 2. DOIs VERIFICADOS (tabela): | Ref | DOI resolve | Metadata bate (Modo 7-bis) | Tipo | Distância | Nota | 3. CLAIMS VERIFICADAS — três classes (tabela): | Slide | Claim | Fonte | Classe | Nota | Classe ∈ {SUSTENTADA, NÃO SUSTENTADA, NÃO RESOLVÍVEL}. 4. SOBREPOSIÇÕES (tabela): | Par | Classificação | Justificativa | 5. VULNERABILIDADES ADVERSARIAIS: | Crítico | Vulnerabilidade | Severidade | Correção | 5b. DEVIL'S ADVOCATE: | Argumento central | Contra-argumento | Score 1-5 | Ação | 6. CALIBRAÇÃO RETÓRICA: itens não cumpridos com correção 7. FRAQUEZAS ACEITAS: limitações mantidas por decisão editorial Salvar como `outputs/verificacao-[nome-do-post].md` O output desta skill é input direto do `auditor-p`. A tabela de claims com três classes e a entrada do Devil's Advocate são lidas lá pra compor o veredicto final. NUNCA esconder fraquezas do usuário. Se a referência é nível C em vez de A, dizer. Se o dado é de amostra WEIRD, dizer. Se a transposição é parcialmente metafórica, dizer. A decisão de publicar ou não é DELE, não sua.