Revisão em dois eixos do diff entre HEAD e um ponto fixo fornecido pelo usuário:
- Padrões — o código está em conformidade com os padrões de codificação documentados deste repositório?
- Especificação — o código implementa fielmente a issue / PRD / especificação original?
Ambos os eixos rodam como subagentes paralelos para que não poluam o contexto um do outro; em seguida, este skill agrega os resultados.
O rastreador de issues deve ter sido fornecido a você — execute /setup-matt-pocock-skills se docs/agents/issue-tracker.md estiver faltando.
Processo
1. Fixar o ponto fixo
Qualquer que seja o ponto fixo informado pelo usuário — um SHA de commit, nome de branch, tag, main, HEAD~5, etc. Se o usuário não especificou um, pergunte.
Capture o comando diff uma vez: git diff <ponto-fixo>...HEAD (com três pontos, para que a comparação seja contra o merge-base). Anote também a lista de commits via git log <ponto-fixo>..HEAD --oneline.
Antes de prosseguir, confirme que o ponto fixo resolve (git rev-parse <ponto-fixo>) e que o diff não está vazio. Uma referência inválida ou diff vazio deve falhar aqui — não dentro dos dois subagentes paralelos.
2. Identificar a fonte da especificação
Procure pela especificação original, nesta ordem:
- Referências a issues nas mensagens de commit (
#123,Closes #45, GitLab!67, etc.) — obtenha via o fluxo de trabalho emdocs/agents/issue-tracker.md. - Um caminho passado pelo usuário como argumento.
- Um arquivo PRD/especificação em
docs/,specs/, ou.scratch/que corresponda ao nome da branch ou funcionalidade. - Se nada for encontrado, pergunte ao usuário onde está a especificação. Se ele disser que não existe, o subagente Especificação será pulado e reportará "nenhuma especificação disponível".
3. Identificar as fontes de padrões
Qualquer coisa no repositório que documente como o código deve ser escrito, como CODING_STANDARDS.md ou CONTRIBUTING.md.
4. Iniciar ambos os subagentes em paralelo
Envie uma única mensagem com duas chamadas de ferramenta Agent. Use o subagente general-purpose para ambos.
Prompt do subagente de Padrões — inclua:
- O comando diff completo e a lista de commits.
- A lista de arquivos-fonte de padrões encontrados no passo 3.
- A instrução: "Relatório — por arquivo/hunk onde relevante — todos os lugares onde o diff viola um padrão documentado. Cite o padrão (arquivo + a regra). Distinga violações rígidas de julgamentos subjetivos. Pule qualquer coisa que ferramentas enforce. Abaixo de 400 palavras."
Prompt do subagente de Especificação — inclua:
- O comando diff e a lista de commits.
- O caminho ou conteúdo obtido da especificação.
- A instrução: "Relatório: (a) requisitos que a especificação pediu e que estão ausentes ou incompletos; (b) comportamento no diff que não foi solicitado (escopo extra); (c) requisitos que parecem implementados mas cuja implementação parece incorreta. Cite a linha da especificação para cada descoberta. Abaixo de 400 palavras."
Se a especificação estiver faltando, pule o subagente de Especificação e anote isso no relatório final.
5. Agregar
Apresente os dois relatórios sob os cabeçalhos ## Padrões e ## Especificação, na íntegra ou levemente limpos. Não mescle ou classifique novamente os resultados — os dois eixos são deliberadamente separados (veja Por que dois eixos).
Termine com um resumo de uma linha: total de descobertas por eixo e o pior problema dentro de cada eixo (se houver). Não escolha um único vencedor entre eixos — isso é a reclassificação que a separação existe para evitar.
Por que dois eixos
Uma alteração pode passar em um eixo e falhar no outro:
- Código que segue todos os padrões mas implementa a coisa errada → Padrões ok, Especificação falha.
- Código que faz exatamente o que a issue pediu mas quebra as convenções do projeto → Especificação ok, Padrões falha.
Relatá-los separadamente impede que um eixo mascare o outro.