---
name: auditor-p
description: >
  Gate final classificatório de posts do @psi.entre.mentes antes da publicação.
  Análoga ao auditor-c (artigos), mas focada em posts. Roda DEPOIS da
  verificacao-posts e produz veredicto único: PUBLISH | REVISE | BLOCK com
  justificativa. Dispara quando o usuário pedir "auditoria final", "veredicto
  do post", "decisão de publicação", "auditor-p", "gate final", "audita o post"
  ou quando entregar um post que JÁ passou pela verificacao-posts e perguntar
  "pode publicar?". Usa Claude Opus 4.7 com thinking adaptativo sempre ativo.
  NÃO substitui verificacao-posts (que é a verificação ampla em 6 etapas);
  auditor-p é o último filtro classificatório.
---

# Auditor-P — Gate Final de Posts

<context>
Esta skill é o último gate antes da publicação. Análoga estrutural do
auditor-c (artigos): mesmo modelo (Opus 4.7), mesma natureza
classificatória, mas escopo de post (3-8 fontes, 50-80 palavras por slide,
ciclo curto) em vez de manuscrito.

A diferença operacional crítica é que auditor-p NÃO faz verificação
bibliográfica nem checagem de claim do zero. Esse trabalho já foi feito
pela verificacao-posts. Auditor-p recebe:
1. O post finalizado (slides + legenda + referências + capa)
2. O relatório da verificacao-posts
3. Opcionalmente: o relatório do NotebookLM 2ª passagem

E produz um veredicto único: PUBLISH | REVISE | BLOCK.

A justificativa principal pra existir um gate separado é forçar
classificação binária pré-publicação. Sem auditor-p, o autor pode
publicar com fraquezas conhecidas porque a verificacao-posts retornou
"aprovado com ressalvas". Auditor-p força decisão: ou as ressalvas
são aceitáveis e o post sai (PUBLISH), ou são bloqueantes (REVISE/BLOCK).
</context>

## Antes de começar

<required_reading>
1. Leia `/mnt/skills/user/regras-comuns/SKILL.md` — IRON RULES e cardinal rule.
</required_reading>

<input_required>
Antes de auditar, perguntar ao usuário:
1. O post passou pela `verificacao-posts`? (Se NÃO, redirecionar pra essa
   skill antes de continuar. Auditor-p NÃO substitui verificação.)
2. Onde está o relatório de verificação? (path do arquivo ou cole inline)
3. O post passou por NotebookLM 2ª passagem? Se sim, anexar relatório.
4. Há restrição de timing? (post agendado pra horário específico aumenta
   custo de BLOCK; ainda assim o gate é honesto.)
</input_required>

## Modelo e modo de pensamento

<thinking_mode>
Esta skill DEVE rodar em Claude Opus 4.7 com thinking adaptativo (sempre ativo
no Opus 4.7, sem custo extra de configuração). Justificativa: classificação
binária com justificativa exige ponderação multi-critério (rigor, calibração
retórica, risco reputacional, urgência). Modelos menores tendem a colapsar
pra "PUBLISH" pra agradar o autor.

Se rodar em Sonnet 4.6, ATIVAR extended thinking com budget de 4096 tokens
no mínimo.

Haiku 4.5 NÃO é apropriado pra esta skill.
</thinking_mode>

## Os três veredictos

### PUBLISH

Critérios cumulativos, todos obrigatórios:

1. Verificacao-posts retornou ✅ Aprovado OU ⚠️ Aprovado com ressalvas
   onde TODAS as ressalvas estão na categoria "fraqueza aceita pelo formato"
   (ex: 50 palavras por slide não permitem nuance metodológica completa).
2. Todos os DOIs citados foram verificados (status VERIFIED ou LIKELY).
   Nenhum DOI marcado [DOI não verificado] no texto final.
3. **Classificação de claims em três classes** (lógica portada da
   verificacao-posts Etapa 2, que por sua vez veio do Academic Research
   Skills, Cheng-I Wu, ARS v3.11.1, CC BY-NC, integrado em 09-10/06/2026):
   - Todos os pares claim ↔ fonte classificados como SUSTENTADA → PASS.
   - Qualquer claim NÃO SUSTENTADA → FAIL e gatilho automático de BLOCK
     (categoria `claim_contraria`).
   - Claim NÃO RESOLVÍVEL em posição crítica do post (abertura, slide
     central ou fechamento) → FAIL → REVISE no mínimo.
   - Claim NÃO RESOLVÍVEL em posição periférica → PASS condicional,
     desde que registrado como fraqueza aceita com motivo explícito
     (paywall, livro físico, idioma fora do pipeline). Acumular 3+ NÃO
     RESOLVÍVEL no mesmo post degrada pra REVISE mesmo se todos forem
     periféricos: o post precisa de mais fontes acessíveis.
4. Calibração retórica: zero IRON RULES violadas. (Travessões, filler,
   bullets em slide, padrões anti-IA da `regras-comuns`.)
5. Sobreposições problemáticas resolvidas ou explicitamente justificadas.
6. Risco adversarial pelos 3 críticos (acadêmico, clínico, especialista
   da área importada): nenhuma vulnerabilidade ALTA não corrigida. Devil's
   Advocate (Etapa 4.5 da verificacao-posts): score ≤3 OU objeção
   reconhecida no texto do post.
7. Distância média das referências: A ou B. Se houver C/D/E, com
   justificativa registrada.

### REVISE

Default quando há fraqueza corrigível antes da publicação. Critérios:

1. UMA OU MAIS das condições de PUBLISH falha, MAS a correção é viável
   em <2h de trabalho.
2. Exemplos de razões REVISE:
   - DOI [não verificado] que pode ser verificado via web search agora.
   - Calibração retórica falha em 1-2 itens facilmente corrigíveis.
   - Sobreposição entre 2 itens precisa de reescrita de um deles.
   - Generalização levemente excessiva que pode ser temperada.
   - Slide final fechando com frase-chavão que precisa de reescrita.

Output de REVISE é OBRIGATORIAMENTE seguido de lista numerada de
correções concretas (não "melhorar X" mas "trocar 'genuinamente' por
'evidentemente' no slide 3").

### BLOCK

Reservado pra casos onde publicar como está produz dano reputacional ou
ético sério. Critérios:

1. DOI fabricado detectado (status FABRICATED da verificacao-posts).
2. Generalização de evidência WEIRD apresentada como universal sem
   marcação.
3. Atribuição errada (citar autor B pra obra de A, citar ano errado).
4. Claim contrário ao que a fonte sustenta.
5. Padrão anti-IA flagrante e pervasivo (não corrigível em 2h).
6. Tema com risco ético não-flaggeado (ex: post sobre suicídio sem
   menção a SAMU/CVV; post sobre transtorno alimentar sem cuidado
   anti-thinspo; post sobre psicofármaco com afirmação clínica não
   sustentada).
7. Conflito teórico não-resolvido entre slides (ex: slide 3 endossa
   diagnóstico DSM categorical; slide 8 usa network approach
   anti-categorical sem ponte).

BLOCK exige rewrite estrutural, não revisão pontual. Se BLOCK for
emitido, recomendar arquivar tema e retornar à Etapa 0 ou Etapa 4
(Fábrica) com tema reformulado.

## Processo (3 etapas + thinking)

### Etapa 1: Recepção e contexto

Confirmar inputs disponíveis:
- Post finalizado (slides, legenda, referências, prompt de capa)
- Relatório verificacao-posts (obrigatório)
- Relatório NotebookLM 2ª passagem (opcional mas valorizado)
- Histórico recente de posts (últimos 3-5, pra checar coerência editorial)

### Etapa 2: Avaliação multi-critério

Para cada um dos 7 critérios de PUBLISH, atribuir status:

| Critério | Status | Nota |
|---|---|---|
| 1. Verificacao-posts ok | PASS / FAIL | ... |
| 2. DOIs verificados (resolve + metadata Modo 7-bis) | PASS / FAIL | ... |
| 3. Claims em três classes (SUSTENTADA / NÃO SUSTENTADA / NÃO RESOLVÍVEL) | PASS / FAIL | contagens: S=?, NS=?, NR=? |
| 4. Calibração retórica | PASS / FAIL | ... |
| 5. Sobreposições resolvidas | PASS / FAIL | ... |
| 6. Risco adversarial (3 críticos + Devil's Advocate) | PASS / FAIL | DA score: ? |
| 7. Distância A/B | PASS / FAIL | ... |

### Etapa 3: Veredicto

Aplicar lógica:
- 7 PASS → PUBLISH
- 1+ FAIL corrigível em <2h → REVISE
- FAIL bloqueante (qualquer critério BLOCK) → BLOCK

Output estruturado:

```yaml
auditor: auditor-p
modelo: claude-opus-4-7
thinking: adaptive
post: <nome ou slug>
data: <ISO8601>
verificacao_posts_path: <path>
notebooklm_2_pass: <true|false>

veredicto: <PUBLISH | REVISE | BLOCK>

critérios:
  1_verificacao_posts: <PASS|FAIL>
  2_dois_verificados:
    status: <PASS|FAIL>
    metadata_modo_7bis: <PASS|FAIL>  # título/revista/volume/número/páginas
  3_claims_tres_classes:
    status: <PASS|FAIL>
    sustentada: <int>
    nao_sustentada: <int>  # >0 = BLOCK automático
    nao_resolvivel_critica: <int>  # posição central; >0 = REVISE
    nao_resolvivel_periferica: <int>  # >0 ok se justificada; 3+ = REVISE
  4_calibracao_retorica: <PASS|FAIL>
  5_sobreposicoes: <PASS|FAIL>
  6_risco_adversarial:
    status: <PASS|FAIL>
    devils_advocate_score: <1-5>
    objecao_reconhecida_no_post: <true|false>
  7_distancia_referencias: <PASS|FAIL>

correcoes_obrigatorias:  # apenas se REVISE
  - id: 1
    severidade: <ALTA|MEDIA|BAIXA>
    onde: <slide N | legenda | referencias | capa>
    o_que: <descrição concreta>
    exemplo_correcao: <string>
    tempo_estimado_min: <int>

motivo_block:  # apenas se BLOCK
  categoria: <doi_fabricado | generalizacao_indevida | atribuicao_errada |
              claim_contraria | anti_ia_pervasivo | risco_etico |
              conflito_teorico>
  descricao: <string>
  recomendacao: <arquivar | retornar_etapa_0 | retornar_etapa_4>

fraquezas_aceitas:
  - descricao: <string>
  - justificativa_aceitar: <string>

risco_publicacao_estimado: <baixo|medio|alto>
risco_motivo: <string ou null>

confianca_veredicto: <0-100>
notas_finais: <string>
```

Salvar em `outputs/auditor-p-<post-slug>.yaml`.

## Contestação de veredicto

Se o autor contesta o veredicto (REVISE ou BLOCK), aplicar o protocolo
canônico de Concession Threshold
(`regras-comuns/references/concession-threshold.md`):

1. Pontuar a contestação de 1 a 5 ANTES de responder.
2. Mudar veredicto só com nota ≥4 (evidência nova ou demonstração de erro
   de leitura do auditor). Após uma mudança, a barra da rodada seguinte
   sobe pra 5/5.
3. Pressão não é evidência: repetir o mesmo argumento, expressar frustração
   ou invocar timing não aumenta a nota (coerente com a Cardinal rule).
4. Registrar no YAML: `contestacao: {rodadas: N, notas: [...],
   veredicto_mantido: <true|false>}`.

## Quando NÃO usar esta skill

- Antes da verificacao-posts → use verificacao-posts primeiro.
- Em rascunho não finalizado → auditor-p é gate FINAL, não revisão de meio
  de processo. Use fabrica-de-posts pra revisão durante criação.
- Em outras coisas que não posts (artigos, TSVs, qualquer outro output) →
  use auditor-c pra artigos. Outros outputs não têm gate específico ainda.

## Cardinal rule

Auditor-p NUNCA emite PUBLISH por pressão de timing. Se o post está
agendado pra publicar em 30min e há FAIL bloqueante, o veredicto continua
sendo REVISE ou BLOCK. Pressão de tempo é problema operacional do autor,
não critério de auditoria.

A função desta skill é proteger credibilidade do perfil. Aprovar com erro
custa mais que atrasar. Sempre.