菜单
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. Genérico.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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. Genérico.
Núcleo SSoT do método metacognitivo reutilizável. Carregar quando precisar decompor um problema, validar antes de entregar, aplicar a cláusula anti-loop, resolver precedência de instruções, ou registrar checkpoint/transferência. O roteador (framework v2.3) decide QUANDO; este arquivo guarda o COMO. NÃO carregar para bate-papo casual.
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). Genérico e agnóstico de domínio.
Aplicação SW/dados (ADR-023). Ativar quando o produto entregue precisa de validação SISTEMÁTICA — gold-set, métricas pass/fail, teste de regressão, reprodutibilidade (notebook de dados, modelo/ML, pipeline, produto que vai a produção). Distinto do qa-critic (adversarial, 1 turno): aqui é sistemático e reexecutável. NÃO ativar para script descartável, protótipo sem critério formal, ou no lugar do qa-critic adversarial. Ativado pelo product_type do mission-gate (ADR-022).
Aplicação SW/dados (ADR-023). Ativar quando o produto entregue tem INTERFACE humana (gui-app, CLI interativo, dashboard, notebook com visualização). Especifica a UX (ux-spec: fluxos, componentes, estados, critérios de aceite de UX) — é AUTOR de spec, NÃO constrói a GUI (isso é developer). A GUI é do PRODUTO, não do framework. NÃO ativar para pipeline headless, biblioteca sem UI, script sem interface. Ativado pelo product_type do mission-gate (ADR-022).
Ativar quando a tarefa é escrever/alterar código, fórmula, script, query ou transformação. Saída sempre passa por qa-critic. Genérico — a sintaxe específica vem da aplicação.
| 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. Genérico. |
| 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 genérico 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.
Fechamento — Mindset adversarial mantida para bugs novos não-listados: hipótese default = EXISTE BUG. Estas 7 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.
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).