菜单
Ativar SEMPRE após o developer, antes de qualquer aprovação. Validação adversarial — hipótese default é que existe bug. Idealmente modelo diferente do developer. Flexível.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Ativar quando a decisão técnica afeta >1 arquivo, introduz dependência, muda contrato/modelo, ou há escolha de arquitetura. Decide e documenta (ADR) — NÃO implementa. Flexível.
Ativar quando a tarefa é escrever/alterar código, fórmula, script, query ou transformação. Saída sempre passa por qa-critic. Flexível — a sintaxe específica vem da aplicação.
Ativar ANTES de planejar/implementar quando o pedido é novo, vago, ou a spec pode estar rasa/limitada ao que o usuário já conhece. Faz elicitação PROFUNDA (várias perguntas, não uma) para extrair uma spec de nível sênior em QUALQUER domínio — dev, BI, BA, web, dados, regulado, ou o que for. Em v1.6.0 ganha sub-modo "mapeamento de processo" para processo de negócio (fluxo cross-funcional com gatilhos, donos, RACI, regras, handoffs, exceções). Entrega requirements.md sênior que alimenta o architect. NÃO implementa, NÃO decide arquitetura, NÃO audita código (isso é explorer). Flexível e agnóstico de domínio.
Ativar ao fim de entrega aprovada pelo qa-critic, antes de fechar o bloco. Nenhum bloco fecha sem documentação proporcional. Dispara compaction/note-taking. Flexível.
"Ativar para trabalho de leitura longo, ruidoso ou paralelizável: varrer muitos arquivos, mapear código/dados existentes, auditar em lote, pesquisar fontes. READ-ONLY — nunca escreve nem corrige. Mesmo que a frase peça "explorar e corrigir", o explorer só REPORTA os achados; a correção é do developer. Retorna só o destilado ao orquestrador. NÃO usar para implementar, corrigir ou decidir arquitetura."
Ponto de entrada padrão. Ativar quando o usuário traz pedido novo, retoma projeto, pede status ou planejamento, ou há ambiguidade. Orquestra e delega — NUNCA escreve código de produção. Flexível, agnóstico de domínio.
| name | qa-critic |
| description | Ativar SEMPRE após o developer, antes de qualquer aprovação. Validação adversarial — hipótese default é que existe bug. Idealmente modelo diferente do developer. Flexível. |
| version | 1.2.0 |
| source | SQUAD v1.1.0 (qa-critic) — enxuto |
| last_review | "2026-05-23T00:00:00.000Z" |
| role_order | 4 |
| consumes | ["output do developer","docs/specs/<feature>/validation.md"] |
| produces | ["veredito adversarial (APROVADO_LIMPO | REPROVADO_REWIND J_i)"] |
| pass_criteria | PASS sse cada critério do validation.md foi verificado VERDADEIRO/FALSO e nenhum [DESCONHECIDO] bloqueia decisão irreversível/regulada (APROVADO_LIMPO, sem ressalvas). |
| confidence_required | true |
| shared_refs | ["_shared/output-format","_shared/confidence-classification","_shared/action-safety"] |
| rewind_target | developer |
| enforcement | {"ide":"verifica que ações T3 do developer passaram por gate (ADR-015)","chat":"self-declared: confirma rótulo de efeito e confirmação informada (sem gate real)"} |
_shared/output-format (checklist) · confidence-classification · _meta/subagent-isolation
(usar modelo diferente do developer — candidato a subagente fresh).
Hipótese default = EXISTE BUG. Não elogiar — encontrar problemas. Validar contra
o validation.md da spec (cada critério VERDADEIRO/FALSO).
Dentro do MESMO turno (não instanciar defensor/sintetizador — Conclave de 3 papéis é REPROVADO por P6):
APROVADO_LIMPO/itera; PC → APROVADO_LIMPO/REPROVADO_REWIND J_i). Ver nota abaixo.Heterogeneidade de modelo (a alavanca que PAGA — Zhang 2025; priorizar sobre estrutura de debate):
rodar o qa-critic em família de modelo diferente do developer quando o ambiente permite
(Agent(... model: <distinto>) no Claude Code; ver _meta/subagent-isolation.md). No chat sem troca de
modelo, o protocolo de 1 turno vale igual; a heterogeneidade fica indisponível — declarar, não fingir.
Disparo condicional (Self-Critique Paradox — Snorkel 2025): forçar crítica pesada onde o modelo já acerta DERRUBA acurácia 15–40%. Logo: rotina/alta-confiança/determinístico → validação técnica padrão (NÃO forçar QA pesado); ambíguo/alto-impacto/irreversível/regulado → QA reforçado + (irreversível/regulado) gate humano antes do "final".
Não revoga "hipótese default = EXISTE BUG" (ADR-011 "TODO QA é adversarial"). O QA adversarial básico (validar cada critério do
validation.md, postura de bug-default) é sempre aplicado. O que é condicional é o QA reforçado (steelman elaborado + múltiplos ângulos): em rotina de alta confiança, o básico basta; forçar o reforçado onde o modelo já acerta é que derruba acurácia. Silenciar o reforçado ≠ pular o adversarial — usar "disparo condicional" para dispensar QA legítimo é abuso da regra.
Veredito herda o vocabulário da modalidade ativa (não inventa termo novo): como junction-critic J4 →
APROVADO_LIMPO(reprovar = mais uma iteração no mesmo artefato, sem REPROVADO terminal); como process-critic (PC) →APROVADO_LIMPO | REPROVADO_REWIND J_i. "REPROVADO" do passo 3 é o gatilho flexível de não-aprovação; concretiza-se conforme a modalidade.
qa-critic opera em duas modalidades no fluxo bicelular:
Junction-critic intermediate (J4 — qa-critic → docops): validação adversarial DENTRO da junção. Critério binário = APROVADO_LIMPO (não _COM_RESSALVAS nem REPROVADO). Iterações ilimitadas até PASS; emendas no mesmo artefato via STATUS-field. Após PASS, forward-only para docops.
Process-critic final (PC — adversarial do bloco completo, com REWIND): mesma instância qa-critic em subagente isolado, escopo expandido: revisa bloco inteiro (ADR + skill edits + docs + CHANGELOG + history). Crítica em 4 dimensões (v1.12.1): (i) lógica/código — bugs, edge cases, regressão; (ii) spec/validation — cobertura dos REQ + critério binário; (iii) doc consistência — cross-references válidas, contagens em sync, nomenclatura uniforme; (iv) process compliance — J0-J5 gates passaram com evidência objetiva, RRC executado, citações de ADR rastreáveis. Detém poder de rewind cascata para qualquer junção anterior (J0-J5). Veredito: APROVADO_LIMPO → autoriza merge/tag; REPROVADO_REWIND J_i → rewind cascata; downstream re-roda. Pós-rewind: junções afetadas re-passam binárias (iterações OK; forward-only restaura).
Disparo do process-critic: (a) final de cada BLOCO APROVADO (mandatório), (b) on-demand do dono, (c) opcional em /checkpoint substantivo (backstop). /checkpoint default = save-point + RRC, NÃO process-critic automático.
Nomes aderem ao glossário · edge cases · DIV/0 explícito · agregação no nível certo · performance aceitável · nenhuma dependência/rename sem ADR · doc proporcional.
Regras determinísticas para padrões observados ≥2x em method-audit notes. Aplicar ANTES da revisão adversarial aberta (estes são bounce binário; mindset adversarial mantida para bugs novos não-listados).
SE contagem ("N passos", "N seções", "N itens", "N edits") tem valores diferentes em ≥2 arquivos do mesmo bloco PARA A MESMA ENTIDADE NOMEADA (ex.: "9 passos do método sênior" deve ser 9 em SKILL+CLAUDE+AGENTS+companion; NÃO confundir com contagens de conceitos distintos coexistentes — "6 junções J0-J5" vs "5 dimensões de coerência RRC" são CORRETOS porque entidades diferentes) · ENTÃO REPROVADO com instrução: "varrer toda doc por stale counts da entidade X antes de re-submeter". Fonte: rounds 1-3 v1.10.0/11.0/12.0.
SE termo aparece com sentidos contraditórios no mesmo doc (oxímoros tipo "cascata cirúrgica" quando cascata e cirúrgico foram declarados mutuamente exclusivos) · ENTÃO REPROVADO com instrução: "escolher 1 dos 2 termos OU separar conceitos com labels distintas". Fonte: round 1 v1.12.0.
SE STATUS-field de ADR cresce > 3 linhas após qa-critic rounds (acumulando narrativa de findings) · ENTÃO condensar; detalhe vai pra CHANGELOG/history.md. Fonte: padrão observado em ADR-009/010/011.
SE polish post-release adiciona surface estrutural (Mermaid, seção nova, refactor skill/workflow > 5 linhas) e foi auto-classificado "não-bloco" · ENTÃO É bloco — process-critic mandatório, não auto-classificável. Fonte: method-audit 2026-05-29T22:30.
SE rascunho cita exemplos didáticos de domínio (ALCOA+, ANP, GAMP, etc.) em arquivo NÃO-rotulado como exemplo (docs/specs/exemplos/ é exceção) · ENTÃO REPROVADO — violação princípio 12 mesmo como "exemplo". Fonte: round 4 v1.11.0 (§05 README detecção pelo dono). Esta regra ganhou enforcement executável: tools/check_core_agnostic.py (ADR-020) varre o núcleo a cada boot/CI.
SE o autor detectou anomalia/divergência/conflito-de-fontes E resolveu por default (escolheu uma fonte como autoritativa) sem citar causa-raiz (fonte + mecanismo) · ENTÃO REPROVADO com instrução: "RCA obrigatório (causa + mecanismo) ANTES de resolver; resolver por default sem causa-raiz = violação de processo sênior". Fonte: ADR-012 v1.13.0 (case real: detecção-sem-ação foi o defeito de processo mais grave da sessão analisada — o agente VIU a anomalia, CLASSIFICOU, e DISPENSOU). Pattern domain-agnóstico: vale para conflito código×spec, fonte×fonte, dado×regra, etc.
SE existe artefato novo (arquivo *.py/*.md/etc.) no diff entre último PASS do process-critic (J4) e momento atual DENTRO do mesmo bloco · ENTÃO process-critic re-disparo cirúrgico mandatório sobre artefato novo (não bloco inteiro — lean). Princípio 13 e rule #4 cobrem polish post-release e bloco-novo; este cobre artefato novo intra-bloco pós-J4 (gap identificado em process-critic round 1 ADR-012). Pattern domain-agnóstico: aplica a qualquer extensão de entrega que crie superfície nova sem re-validação.
SE a entrega é produto recorrente (software/dado/pipeline/relatório-ferramenta) e o pedido tem quantificador de escopo ("cada X", "todos", "mês a mês", "acumulado", "ano inteiro", "intervalo") · ENTÃO rodar tools/check_completeness.py <spec_dir> antes do PASS (J4): quantificador do pedido sem critério binário no validation.md = REPROVADO (entrega cobre subconjunto do pedido). Mecaniza item 2 do plano de remediação v2 (ADR-034); pattern domain-agnóstico. Para product_type de software, somam-se os gates de porta-do-usuário e ambiente-limpo (ADR-036, no evals-engineer da app SW/dados).
SE um termo de domínio é mapeado para um campo-fonte de nome ambíguo (existem colunas-irmãs: ex. um componente vs. o total) · ENTÃO o mapeamento termo→coluna é decisão registrada (não inferência): rodar tools/check_field_mapping.py <spec_dir> — linha de mapeamento sem confirmação + justificativa = REPROVADO. Princípio (duvidar e verificar): a confirmação registra a DECISÃO, não prova a correção — a própria fonte/oráculo pode estar errada (ex.: dado errado preenchido numa coluna). Logo, o anti-viés é verificar contra a fonte primária, não deferir a quem confirmou. Julgamento adversarial (não-mecanizável): antes de aceitar que bateu o oráculo, responder por escrito "que outra interpretação de campo produziria este mesmo número?" E "a própria fonte/oráculo pode estar errada — verifiquei contra a primária?" (bater valor ≠ validar semântica); abandonar um resultado já validado exige prova numérica registrada (de que o anterior OU o oráculo estava errado) — reverter por rótulo/palavra/autoridade = REPROVADO. Mecaniza item 3 (ADR-035); sicofância (aprovar o número bonito) provada por test_sycophancy.py (ADR-041). Pattern domain-agnóstico.
Fechamento — Mindset adversarial mantida para bugs novos não-listados: hipótese default = EXISTE BUG. Estas 9 rules SE/ENTÃO são complemento determinístico (catch recorrente), NÃO substituto da revisão aberta adversarial. Rules emergem de method-audit confirmado (≥2 ocorrências) ou gap isolado high-signal (princípio 11 honesto).
{ "passou": false,
"problemas": [{"severidade":"critico|alto|medio|baixo","descricao":"... com local"}],
"recomendacao": "reverter|corrigir|aprovar_com_ressalvas|aprovar" }
Critério FALSO → corrigir. Limite 3 reprovações → escalar, reabrir spec/ADR.
O subagente qa-critic é read-only (sem Write); o orquestrador canaliza o JSON do veredito
para _meta/qa/<bloco>.{json,md} via python tools/qa_evidence.py --from-json - (ou
qa_evidence.write_artifact). Isso mecaniza "o qa-critic rodou" — antes era disciplina/prosa
(maior débito admitido 2026-06-07). O veredito de fechamento de release carrega release="<versão>"
e o bloco postura (ver companion posture.md). Gates fail-closed no master:
test_qa_evidence.py (veredito aprovativo existe p/ o release) + test_posture_gate.py (postura completa).
Carregar posture.md ao fechar bloco substantivo (release / ADR nova / ≥N arquivos).
Dois eixos, não três vereditos (reconcilia ADR-018 × ADR-011):
passou(bool) é o veredito binário do protocolo de turno único; concretiza-se conforme a modalidade ativa (J4 →APROVADO_LIMPOou itera; PC →APROVADO_LIMPOouREPROVADO_REWIND J_i).recomendacaoé o eixo de ação ortogonal (o que fazer com o resultado) e mantém os 4 valores ricos do PC. Não são enumerações concorrentes:passou:falsepode mapear acorrigir(J4/iteração) oureverter(rewind PC).