kairyou/agent-tools

Gerador de Mensagens de Commit

Fluxo de Trabalho

1. Execute git diff --staged para inspecionar as alterações em staged. Se estiver vazio, informe ao usuário para executar git add primeiro e pare.
2. Determine o idioma da descrição usando a Política de Idioma abaixo.
3. Gere a(s) mensagem(ns) e as exiba para confirmação; não faça commit imediatamente. Quando mais de uma formulação for razoável, apresente-as como uma lista numerada curta (1), 2), …) para que o usuário possa escolher respondendo apenas com o número. Uma única mensagem clara pode ser exibida sozinha. O usuário também pode responder com uma edição ou seu próprio texto.
4. Execute git commit -m somente após o usuário escolher ou confirmar explicitamente — um número da lista, "commit" ou "ok" são válidos. Não execute git push a menos que o usuário peça explicitamente.

Política de Idioma

Use esta ordem de prioridade para a descrição legível por humanos após type(scope)::

1. Use o idioma explicitamente solicitado pelo usuário nesta interação.
2. Caso contrário, use a preferência do repositório em .agent-tools/config.jsonc, se definir at-commit.language.
3. Caso contrário, use a preferência global em ~/.agent-tools/config.jsonc, se definir at-commit.language.
4. Caso contrário, use o idioma do texto de invocação real do usuário quando ele contiver uma solicitação clara e independente em linguagem natural. Ignore instruções de habilidade injetadas, conteúdo citado ou colado, blocos de código, diffs e saída de ferramentas.
5. Caso contrário, corresponda ao idioma dominante nos assuntos de commits recentes do repositório.
6. Se nenhum idioma dominante for claro, use o padrão inglês.

Aplique esta ordem literalmente e pare na primeira correspondência. Verifique os itens 2 e 3 antes do item 4. Um comando de barra ou invocação de habilidade simples não tem idioma; continue para o item 5. Inspecione no máximo os 20 assuntos mais recentes.

Mantenha os tokens de sintaxe do Conventional Commits sem tradução: type, scope opcional, ! e BREAKING CHANGE. Mantenha identificadores, nomes de arquivos, nomes de pacotes, comandos, nomes de API e escopos em seu idioma original.

Preferência de Idioma Persistente

Não escreva configuração durante a geração de commit comum. Se o usuário solicitar explicitamente lembrar de um idioma de descrição de commit, ofereça-se para persistir. Pergunte sobre repositório vs global quando o escopo for ambíguo.

Para preferência de repositório, crie ou atualize .agent-tools/config.jsonc; para preferência global, use ~/.agent-tools/config.jsonc:

{
  "at-commit.language": "zh-CN"
}

Preserve chaves não relacionadas e comentários quando prático. Não exija configuração prévia do instalador.

Regras

Leia git diff --staged e gere um título no formato Conventional Commits que explique O QUE mudou e, quando útil, POR QUÊ.

• Título: type(scope): descrição, <= 74 caracteres, sem ponto final, sem prefixo, sem aspas, sem bloco de código.
• type: escolha exatamente um:
  • feat para uma funcionalidade, fix para uma correção de bug
  • refactor para reestruturação que preserva comportamento, perf para desempenho
  • docs para alterações apenas em documentação, style para alterações apenas de formatação
  • test para adicionar ou corrigir testes, build para sistemas de build ou dependências, ci para scripts/configuração de CI
  • chore para alterações diversas que não tocam em src/test, revert para reversões
• scope: nome opcional do módulo afetado. Use a convenção deste repositório. Em monorepos, use o nome do diretório do aplicativo/pacote. Omita para alterações transversais ou quando não tiver certeza.
• descrição: uma frase concisa de verbo-objeto no idioma natural selecionado. Evite preenchimento equivalente a "atualizar arquivos", "este commit", "alterações diversas" ou "várias alterações". Preserve identificadores, nomes de funções, nomes de arquivos, nomes de pacotes, comandos e APIs como escritos.
• apenas uma linha: as mensagens de commit sempre contêm apenas a linha do título. Não escreva corpo ou rodapé. Comprima o POR QUÊ necessário no título.
• alterações de quebra: marque com type(scope)!: descrição, ainda como uma linha. Não use um rodapé BREAKING CHANGE.
• pontuação: use pontuação ASCII.

Estratégia de Geração

Antes de escrever, identifique a linha condutora das alterações em staged.

• Linha principal: inclua apenas as informações necessárias para entender este commit. Não acumule nomes a menos que um seja o ponto da alteração.
• Alterações significativas: procure por alterações de lógica, contrato, build, gate de qualidade ou comportamento visível ao usuário. Use isso para escolher type e decidir se ! é necessário.

Disciplina de Conteúdo

A mensagem deve declarar fatos de código confirmados, não intenção adivinhada.

• Prefira alterações de comportamento em src e test: a documentação é apenas contexto de suporte. Não infira O QUE a partir da documentação sozinha.
• Contexto do usuário é melhor que documentação: objetivos explícitos do usuário podem ajudar a escolher POR QUÊ e a redação, mas O QUE e escopo ainda vêm do diff em staged. Não inclua alterações apenas de contexto ausentes do diff. Se contexto e diff conflitarem, siga o diff e peça confirmação.
• Exclusões e renomeações: quando o propósito não puder ser confirmado a partir das relações de código, declare apenas o que o diff comprova, como "remover X" ou "renomear X para Y". Não afirme substituição, migração ou causalidade a menos que o código comprove.
• Múltiplas alterações com um objetivo: forneça uma mensagem de resumo quando as alterações servirem claramente ao mesmo objetivo, como uma correção de qualidade ou build. Sugira divisão apenas quando melhorar materialmente a revisão ou reversão.
• Alterações em staged não relacionadas: forneça mensagens divididas para cada unidade coerente, além de uma mensagem de resumo conservadora. Deixe o usuário escolher entre dividido ou resumo, em vez de adiar o resumo para outra interação.
• Propriedade ou intenção pouco claras: liste os arquivos que precisam de confirmação em vez de forçar uma mensagem vaga. Prefira confirmação ou divisão a palavras fracas como "atualizar", "ajustar" ou "modificar" quando a intenção não for clara.