critique

Visão geral da skill critique

O que a critique faz

A skill critique é um fluxo de revisão para avaliar um trabalho concluído com múltiplos juízes especializados, debate e consenso. Ela foi pensada para code review e outras tarefas de revisão de mudanças em que você quer mais do que uma opinião de passagem única.

Para quem ela é

Use a critique se você quer que um agente avalie correção, qualidade e problemas deixados passar antes do merge. Ela é indicada para revisores, mantenedores e builders que precisam de uma skill de critique estruturada, em vez de um prompt genérico para Code Review.

Por que isso importa

O principal valor está na consistência sob incerteza: os juízes analisam o trabalho de forma independente, validam suas próprias conclusões e conciliam divergências. Isso reduz elogios rasos, pontos cegos e feedback unidimensional.

Onde ela funciona melhor

Esta skill é mais forte quando o trabalho já existe e o objetivo é julgá-lo, não reescrevê-lo. Se você precisa de implementação, refatoração ou correção automática, critique é a ferramenta errada.

Como usar a skill critique

Instale a skill critique

Instale com npx skills add NeoLabHQ/context-engineering-kit --skill critique. O caminho do repositório é plugins/reflexion/skills/critique, então a skill foi feita para ser usada dentro desse context-engineering kit, e não como uma utilidade independente.

Dê à skill um alvo de revisão claro

O padrão de uso da critique funciona melhor quando você fornece um escopo concreto: arquivos alterados, um intervalo de commits, um link de PR ou uma preocupação específica. A dica встроída aceita caminhos de arquivos, commits ou contexto, e só cai para mudanças recentes se você não informar nada.

Comece pelos arquivos certos

Leia primeiro SKILL.md e depois inspecione quaisquer arquivos próximos de workflow ou metadata no repositório. Neste plugin não há auxiliares em scripts/, references/, resources/ ou rules/, então as instruções centrais de operação ficam no próprio arquivo da skill.

Escreva prompts que definam a intenção da revisão

Um pedido mais forte soa assim: “Critique src/auth.ts e src/session.ts quanto a segurança, risco de regressão e lacunas de cobertura de testes.” Um pedido mais fraco como “revise este código” deixa os juízes adivinhando quais padrões importam, o que reduz o valor do guia de critique.

FAQ da skill critique

A critique é só para code review?

Não. Ela vai além de um simples code review e pode avaliar trabalho concluído, decisões de design ou qualidade de implementação. Ainda assim, funciona melhor quando o resultado esperado é um relatório de revisão, e não um patch.

Em que a critique é diferente de um prompt comum?

Um prompt normal geralmente produz uma única opinião. A skill critique adiciona um processo estruturado com múltiplos agentes, validação independente e construção de consenso, o que é melhor quando você se importa com confiabilidade e interpretações concorrentes.

A critique é amigável para iniciantes?

Sim, desde que o escopo seja específico. Iniciantes conseguem melhores resultados quando nomeiam os arquivos exatos ou o conjunto de mudanças e pedem os critérios mais importantes, em vez de esperar que a skill deduza tudo.

Quando não devo usar critique?

Não use quando precisar que as alterações sejam aplicadas automaticamente, quando a tarefa for trivial ou quando o escopo da revisão estiver amplo demais para uma avaliação justa. Nesses casos, um prompt direto de implementação ou um fluxo direcionado de lint/testes é mais rápido.

Como melhorar a skill critique

Forneça critérios de revisão mais fortes

O maior salto de qualidade vem de dizer à critique o que otimizar: correção, segurança, performance, manutenibilidade, compatibilidade de API ou completude dos testes. Sem isso, os juízes podem dar peso demais a problemas óbvios e deixar passar os riscos que realmente importam para você.

Enxugue o escopo antes de pedir

Se o alvo da revisão for grande, divida-o em um commit, módulo ou fatia de funcionalidade. A skill critique funciona melhor quando a entrada é delimitada, porque o debate pode se concentrar em trade-offs reais em vez de resumir o repositório inteiro.

Inclua evidências que os juízes possam verificar

Informe caminhos de arquivos relevantes, comportamento esperado, restrições e quaisquer modos de falha já conhecidos. Isso ajuda a critique a validar as alegações em vez de adivinhar a intenção, o que é especialmente importante para critique for Code Review.

Itere sobre o primeiro relatório

Use a primeira passada para expor divergências e, depois, peça uma segunda critique sobre os achados de maior risco ou as áreas com evidência fraca. Esse ciclo iterativo transforma a critique em um apoio de decisão mais preciso, em vez de um resumo de uso único.