xieshuai0817-hub/LanceSkill

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 são executados como subagentes paralelos para não poluir o contexto um do outro, e então esta habilidade agrega suas descobertas.

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 ele não especificou um, peça por ele.

Capture o comando diff uma vez: git diff <ponto-fixo>...HEAD (com três pontos, para que a comparação seja contra a merge-base). Observe também a lista de commits através de git log <ponto-fixo>..HEAD --oneline.

Antes de prosseguir, confirme que o ponto fixo é resolvido (git rev-parse <ponto-fixo>) e que o diff não está vazio. Uma referência inválida ou diff vazio deve falhar aqui — e não dentro dos dois subagentes paralelos.

2. Identificar a fonte da especificação

Procure pela especificação original, nesta ordem:

1. Referências a issues nas mensagens de commit (#123, Closes #45, GitLab !67, etc.) — busque através do fluxo de trabalho em docs/agents/issue-tracker.md.
2. Um caminho passado pelo usuário como argumento.
3. Um arquivo PRD/especificação em docs/, specs/ ou .scratch/ que corresponda ao nome da branch ou funcionalidade.
4. Se nada for encontrado, pergunte ao usuário onde está a especificação. Se ele disser que não há, o subagente de Especificação irá pular e relatar "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.

Além do que o repositório documenta, o eixo de Padrões sempre carrega a linha de base de code smells abaixo — um conjunto fixo de code smells de Fowler (Refactoring, cap. 3) que se aplica mesmo quando o repositório não documenta nada. Duas regras o vinculam:

• O repositório se sobrepõe. Um padrão documentado no repositório sempre vence; onde ele endossa algo que a linha de base sinalizaria, suprima o smell.
• Sempre um julgamento. Cada smell é uma heurística rotulada ("possível Feature Envy"), nunca uma violação definitiva — e, como qualquer padrão aqui, pule qualquer coisa que as ferramentas já imponham.

Cada smell lê o que é → como corrigir; combine-o com o diff:

• Nome Misterioso — uma função, variável ou tipo cujo nome não revela o que faz ou contém. → renomeie-o; se nenhum nome honesto vier, o design está obscuro.
• Código Duplicado — a mesma forma lógica aparece em mais de um bloco ou arquivo na alteração. → extraia a forma compartilhada, chame-a de ambos os lugares.
• Inveja de Atributos — um método que acessa mais os dados de outro objeto do que os seus próprios. → mova o método para o dado que ele inveja.
• Agrupamentos de Dados — os mesmos poucos campos ou parâmetros continuam viajando juntos (um tipo querendo nascer). → agrupe-os em um único tipo, passe-o.
• Obsessão por Primitivos — um primitivo ou string representando um conceito de domínio que merece seu próprio tipo. → dê ao conceito seu próprio tipo pequeno.
• Switches Repetidos — o mesmo switch/if-cascata no mesmo tipo recorre na alteração. → substitua por polimorfismo ou um mapa que ambos os locais compartilhem.
• Cirurgia com Espingarda — uma alteração lógica força edições espalhadas por muitos arquivos no diff. → reúna o que muda junto em um único módulo.
• Alteração Divergente — um arquivo ou módulo é editado por várias razões não relacionadas. → divida para que cada módulo mude por uma única razão.
• Generalidade Especulativa — abstração, parâmetros ou ganchos adicionados para necessidades que a especificação não tem. → remova-o; volte a in-line até que uma necessidade real apareça.
• Cadeias de Mensagens — longa navegação a.b().c().d() da qual o chamador não deveria depender. → esconda a caminhada atrás de um método no primeiro objeto.
• Intermediário — uma classe ou função que principalmente apenas delega adiante. → corte-a, chame o alvo real diretamente.
• Herança Recusada — uma subclasse ou implementador que ignora ou sobrescreve a maior parte do que herda. → remova a herança, use composição.

4. Criar 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 que você encontrou no passo 3, mais a linha de base de smells do passo 3 colada na íntegra — o subagente não tem outro acesso a ela.
• A instrução: "Relatório — por arquivo/bloco onde relevante — (a) cada lugar onde o diff viola um padrão documentado: cite o padrão (arquivo + a regra); e (b) qualquer smell da linha de base que você detectar: nomeie-o e cite o bloco. Distinga violações definitivas de julgamentos — violações de padrões documentados podem ser definitivas, mas smells da linha de base são sempre julgamentos, e um padrão documentado do repositório se sobrepõe à linha de base. Pule qualquer coisa que as ferramentas já imponham. Menos 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 que estão ausentes ou parciais; (b) comportamento no diff que não foi solicitado (aumento de escopo); (c) requisitos que parecem implementados, mas onde a implementação parece errada. Cite a linha da especificação para cada descoberta. Menos de 400 palavras."

Se a especificação estiver faltando, pule o subagente de Especificação e observe 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 reordene as descobertas — 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 os eixos — isso é a reordenaçã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 aprovado, Especificação reprovado.
• Código que faz exatamente o que a issue pediu mas quebra as convenções do projeto → Especificação aprovado, Padrões reprovado.

Relatá-los separadamente impede que um eixo mascare o outro.