القائمة
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).