check

Visão geral do skill check

O que o skill check faz

O skill check é um fluxo de revisão e validação para diffs de código, PRs, triagem de issues, prontidão para release, pushes e auditorias de projeto. Ele é ideal para quem quer uma resposta rápida, mas disciplinada, para perguntas como: “Isso está seguro para publicar, o que está quebrado e o que eu preciso corrigir antes de fazer merge?”

Quando o skill check é a melhor escolha

Use o skill check quando você precisar revisar um conjunto concreto de mudanças, seja antes do merge, antes do release ou ao validar artefatos gerados e ações de acompanhamento. Ele é especialmente útil quando você quer que o agente inspecione primeiro o worktree, evite mudanças locais ocultas e separe problemas corrigíveis de itens que exigem confirmação humana.

O que torna o check diferente

O skill check não é um prompt genérico de “olhe este código”. Ele traz gates explícitos de segurança para worktrees sujos ou com arquivos não rastreados, um fluxo claro de revisão em primeiro lugar e encaminhamento para revisão especializada quando há riscos de arquitetura ou segurança. Isso o torna mais robusto do que um prompt pontual para check for Code Review, porque reduz a incerteza sobre quando inspecionar, o que inspecionar e quando parar.

Como usar o skill check

Instalar e acionar o check

Instale com:

npx skills add tw93/Waza --skill check

Depois, invoque o skill quando tiver um alvo de revisão concreto: um diff, branch, PR, candidato a release, intervalo de commits ou uma solicitação de auditoria do repositório. Para check usage, dê ao agente um escopo específico, como “revise os últimos 3 commits”, “verifique este PR antes do merge” ou “audite a prontidão do release após updates de dependências”.

Dê a entrada certa para o skill

A melhor entrada para o check não é “isso está bom?”, e sim uma tarefa delimitada com contexto. Bons exemplos:

• “Verifique este PR quanto a regressões de segurança e arquitetura antes do merge.”
• “Revise o worktree atual e me diga o que bloqueia o release.”
• “Audite os arquivos gerados e me diga se eles batem com as mudanças na source.”

Inclua a branch, o intervalo de commits, o release pretendido e quaisquer restrições, como “não modifique arquivos” ou “inspecione apenas o contexto público do repositório”. Isso ajuda o skill a evitar um comportamento de revisão amplo e vago.

Leia estes arquivos primeiro

Comece com SKILL.md e depois inspecione references/project-context.md e references/persona-catalog.md para entender a profundidade da revisão, o encaminhamento para especialistas e as expectativas de release. Use agents/reviewer-security.md e agents/reviewer-architecture.md quando o diff tocar limites de confiança, APIs, imports ou estrutura de módulos. references/public-reply.md é importante quando o fluxo inclui follow-up com mantenedores em issues ou PRs.

Dicas práticas de fluxo de trabalho

Antes da revisão, o skill espera uma checagem de segurança do worktree via git status --short --branch -uall. Isso importa porque mudanças sujas ou não rastreadas podem alterar o significado da revisão. Se você quiser um resultado melhor de check guide, diga ao agente se ele deve apenas reportar achados, se pode corrigir problemas seguros e qual comando de verificação deve ser usado após as mudanças.

FAQ do skill check

O check serve só para revisão de código?

Não. O skill check também cobre prontidão para release, pushes, artefatos publicados, triagem de issues e PRs, e auditorias de todo o projeto. Ele é uma escolha melhor do que um prompt comum quando a tarefa exige julgamento de “pronto para publicar”, e não apenas leitura de código.

Quando eu não devo usar o check?

Não use o check para exploração aberta de ideias, investigação de causa raiz ou edição de texto. O skill foi pensado para diffs concretos e revisão operacional, não para brainstorming nem feedback narrativo.

O check é amigável para iniciantes?

Sim, desde que você consiga nomear o alvo e o resultado esperado. Quem está começando costuma ter os melhores resultados quando diz exatamente o que mudou, o que quer que seja revisado e se quer apenas achados ou também correções seguras. Sem isso, o check install pode ser fácil, mas o check usage fica amplo demais para ser confiável.

Em que ele é diferente de um prompt comum?

Um prompt comum geralmente pede uma revisão subjetiva. O check adiciona um caminho disciplinado: preflight de segurança, controle de escopo, expectativa de verificação e encaminhamento especializado para segurança ou arquitetura. Isso o torna mais confiável para check for Code Review do que uma solicitação de revisão improvisada.

Como melhorar o skill check

Forneça um briefing de revisão mais preciso

As entradas mais úteis são: o que mudou, por que mudou, o que não pode quebrar e que tipo de revisão você quer. Por exemplo: “revise só o caminho de autenticação”, “foque nos artefatos de release” ou “verifique se este refactor altera APIs públicas”. Isso estreita a busca e melhora o sinal.

Deixe claras as restrições difíceis

Conte ao skill sobre regras de empacotamento, arquivos gerados, paths protegidos e comandos de verificação obrigatórios. Se o repositório tiver uma source of truth para build ou release, mencione isso logo de cara. Isso reduz falsa confiança e ajuda o skill check a identificar drift, artefatos ausentes ou follow-through inseguro.

Itere a partir dos achados, não dos elogios

Depois da primeira passada, responda com os achados exatos que você quer reavaliar ou com o patch que você aplicou. O skill melhora quando você pede uma segunda passada em uma área de risco por vez, como segurança, arquitetura ou prontidão para release. Se a saída parecer ampla demais, estreite o escopo em vez de pedir “mais detalhes”.