BWBYB/agent-skills

Minimal Git Commit

Objetivo

Criar um ou mais commits atômicos para a tarefa atual do agente. Cada mensagem de commit gerada segue o Conventional Commits. Mantenha as submissões comuns de baixo contexto; reserve a análise completa do diff para uma solicitação explícita de modo completo.

Seleção de Modo

• Use o modo rápido por padrão.
• Use o modo completo apenas quando o usuário diz full, pede para escanear ou analisar o diff completo, ou pede explicitamente para verificar cada alteração.
• Não faça upgrade silencioso do modo rápido para o modo completo. Se o modo rápido não tiver informações suficientes, peça um resumo das mudanças ou peça ao usuário para escolher o modo completo.

Modo Rápido

Use primeiro o resumo explícito da tarefa atual fornecido pelo agente. Quando necessário, inspecione apenas:

git status --short
git diff --stat

Não leia o diff completo ou o histórico. Não adivinhe sobre mudanças ausentes do resumo. Agrupe as mudanças declaradas em commits atômicos e gere suas mensagens. Se o usuário pedir explicitamente para commitar, mostre os arquivos/mensagens planejados antes de modificar o índice ou criar commits quando o limite do arquivo não estiver claro.

Modo Completo

Leia os diffs completos relevantes da árvore de trabalho e do stage, inspecione todos os arquivos alterados e leia a referência de Conventional Commits. Verifique se há funcionalidades, testes, documentação, configuração, arquivos não relacionados, arquivos sensíveis, arquivos gerados e alterações lógicas independentes omitidas. Confirme que os arquivos gerados pertencem ao controle de versão: mantenha as saídas necessárias do projeto, como lockfiles ou migrações, e exclua artefatos de build e saídas locais. Divida funcionalidades independentes, correções de bugs, refatorações e alterações apenas de formatação em commits atômicos; mantenha as mudanças juntas quando elas estiverem fortemente acopladas e não puderem ser testadas ou revertidas independentemente. Execute verificações relevantes para os arquivos alterados usando comandos existentes do projeto. Não execute a suíte completa de testes, lint e verificação de tipos por padrão; reuse verificações já executadas durante a tarefa e expanda a verificação apenas quando solicitado ou necessário pelas mudanças. Não inspecione o histórico a menos que seja explicitamente solicitado.

Antes de git add ou git commit, preserve as mudanças do usuário que estão fora da tarefa atual. Execute essas mutações apenas quando o usuário pedir explicitamente para commitar. Nunca faça push como parte desta skill.

Regras de Commit

Use esta forma:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• Use feat para uma nova funcionalidade e fix para uma correção de bug.
• Prefira os tipos do projeto docs, style, refactor, perf, test, build, ci, chore e revert quando eles descreverem precisamente a mudança.
• Use um escopo substantivo entre parênteses apenas quando ele adicionar contexto útil.
• Marque mudanças que quebram compatibilidade com ! antes dos dois-pontos ou um rodapé BREAKING CHANGE: em maiúsculas.
• Mantenha a descrição concisa, no presente do indicativo, imperativa e preferencialmente com menos de 72 caracteres.
• Um commit representa uma mudança lógica. Separe funcionalidades independentes, correções, testes, documentação e refatorações sempre que possível.
• fix mapeia para PATCH do SemVer, feat para MINOR e qualquer mudança que quebra compatibilidade para MAJOR; não altere arquivos de versão a menos que seja solicitado separadamente.

Segurança e Confirmação

• Nunca use git add . por padrão; adicione apenas arquivos pertencentes à tarefa atual.
• Nunca commite .env, credenciais, tokens, chaves privadas ou outros segredos.
• No modo completo, revise o conteúdo em staged para segredos e confirme que os arquivos gerados ou de build são esperados pelo projeto antes de incluí-los.
• Nunca modifique a configuração do Git, pule hooks, force push ou altere um commit existente a menos que o usuário solicite explicitamente essa ação exata.
• Não misture mudanças pré-existentes do usuário com as mudanças do agente.
• Pare e pergunte quando o limite da tarefa, a propriedade do arquivo, a divisão lógica ou o status de arquivo sensível não estiver claro.
• Criar uma mensagem não é permissão para criar um commit; exija uma solicitação explícita de commit antes de git add ou git commit.

Referência

Leia references/conventional-commits.md no modo completo ou quando um tipo, rodapé, mudança que quebra compatibilidade, revert, SemVer ou pergunta de FAQ precisar de tratamento detalhado.