Marcussyl/cursor-skills

Commitar em lotes

Divida o trabalho não commitado em commits lógicos. Cada commit deve ser revisável por si só e incluir todos os arquivos necessários para que aquela parte faça sentido.

Segurança (sempre)

• Nunca atualize a configuração do Git.
• Nunca faça force-push, hard reset ou outras operações destrutivas no Git, a menos que o usuário peça explicitamente.
• Nunca pule hooks (--no-verify, etc.), a menos que o usuário peça explicitamente.
• Nunca adicione segredos (.env, credenciais, chaves) ao stage. Avise e exclua-os.
• Nunca use git commit --amend a menos que as regras do usuário para amend sejam totalmente atendidas.
• Se um hook de commit falhar, corrija o problema e crie um novo commit; não altere um commit com falha.
• Não adicione Co-authored-by: Cursor às mensagens de commit.

1. Inspecionar

Execute em paralelo quando possível:

• git status
• git diff e git diff --staged
• git log -5 --oneline para o estilo da mensagem
• git remote -v e rastreamento de branch (git status -sb)

Se não houver nada para commitar, pare e informe.

2. Planejar lotes

Agrupe as alterações por propósito, não apenas por tipo de arquivo. Exemplos:

• Uma funcionalidade ou comportamento voltado ao usuário + seus testes e documentos
• Uma correção de bug + apenas os arquivos que a corrigem
• Refatoração que fique isolada sem misturar funcionalidades não relacionadas
• Tarefa de manutenção ou ferramenta com escopo em uma área (dependências, CI, configuração)

Regras:

• Não misture funcionalidades não relacionadas em um único commit.
• Inclua arquivos complementares no mesmo lote (ex.: esquema + entidade + migração + chamadas para uma alteração).
• Se um arquivo tocar em duas preocupações, prefira o lote dominante ou mencione a compensação antes de commitar.
• Liste os lotes em ordem: fundamentos primeiro (tipos compartilhados, configuração), depois funcionalidades, e por último apenas documentos se dependerem de commits anteriores.

Mostre ao usuário um plano curto: número do lote, arquivos ou caminhos, assunto do commit convencional proposto. Em seguida, prossiga a menos que ele se oponha.

3. Commitar cada lote

Para cada lote, sequencialmente:

1. Faça stage apenas desse lote (git add caminhos específicos; evite git add -A a menos que toda a árvore seja um lote).
2. Verifique novamente com git diff --staged se nada não relacionado entrou.
3. Escreva um assunto de Commit Convencional (feat, fix, chore, docs, refactor, test, etc.) focado no porquê.
4. Se o nome da branch contiver um ID de issue, anexe #<issue> ao assunto (estilo GitLab).
5. Faça commit. No Windows PowerShell, use git commit -m 'assunto' (ou vários -m para um corpo curto). No bash, um HEREDOC para a mensagem é aceitável.
6. Repita até que a árvore de trabalho esteja limpa para as alterações pretendidas.

4. Push para o GitHub (ou remoto)

Após todos os lotes:

• Se origin (ou o remoto nomeado pelo usuário) existir e a branch deve ser publicada, execute git push -u origin HEAD quando o upstream estiver ausente, caso contrário git push.
• Nunca force-push para main ou master.
• Se o push for rejeitado, relate o erro e sugira pull/rebase; não force a menos que o usuário solicite explicitamente.
• Se não houver remoto, informe que os commits são apenas locais e pergunte se deseja adicionar um remoto.

5. Relatório

Resuma:

• Cada hash de commit e assunto (do mais novo ao mais antigo ou em lista numerada).
• Resultado do push (URL ou branch, se disponível).
• Qualquer item deixado sem stage propositalmente (segredos, arquivos locais).

Relação com commit-msg

commit-msg sugere uma linha com base em arquivos já em stage e não faz commit. Esta skill planeja, faz stage, commita em várias etapas e faz push.