Quando Usar
Carregue esta skill ao decidir o que deve pertencer a cada commit ou PR.
Use-a para:
- Dividir uma funcionalidade em trabalho revisável.
- Preparar commits antes de abrir um PR.
- Transformar uma grande alteração em PRs encadeados ou empilhados.
- Manter a carga cognitiva do revisor saudável.
- Aplicar tarefas SDD sem produzir acidentalmente um PR com mais de 400 linhas alteradas.
Regras Críticas
| Regra | Requisito |
|---|---|
| Commitar por unidade de trabalho | Um commit representa uma unidade de comportamento, correção, migração ou documentação entregável. |
| Não commitar por tipo de arquivo | Evite modelos, depois serviços, depois testes se nenhum funcionar sozinho. |
| Manter testes com o código | Testes pertencem ao mesmo commit que o comportamento que verificam. |
| Manter documentação com a alteração visível ao usuário | A documentação pertence à funcionalidade ou fluxo que explica. |
| Contar uma história | Um revisor deve entender por que cada commit existe a partir de seu diff e mensagem. |
| Pronto para PR futuro | Cada commit deve ser um candidato a PR encadeado quando a alteração crescer. |
| Proteção de carga SDD | Se as tarefas SDD preveem uma alteração >400 linhas, agrupe commits em fatias de PR encadeado antes da implementação. |
| Orçamento não é código-golfe | Nunca reduza um diff excluindo comentários, linhas em branco, documentação ou testes, ou comprimindo código, para caber no orçamento de revisão (400 por padrão, ou review_budget_lines da sessão). Fatias por unidade de trabalho ou reporte o excesso. |
Lista de Verificação da Unidade de Trabalho
Antes de commitar, confirme:
- O commit tem um propósito claro.
- O repositório ainda faz sentido após aplicar apenas este commit.
- Testes ou documentação para esta unidade estão incluídos quando relevantes.
- O rollback é razoável sem reverter trabalho não relacionado.
- A mensagem do commit explica o resultado, não a lista de arquivos.
Exemplos de Divisão
| Divisão fraca | Melhor divisão em unidade de trabalho |
|---|---|
adicionar modelos | feat(auth): adicionar modelo de domínio de validação de token e testes |
adicionar serviços | feat(auth): integrar validação de token no fluxo de login |
adicionar testes | Testes incluídos em cada commit de comportamento |
atualizar docs | Documentos incluídos com a alteração voltada ao usuário que explicam |
Relação com PRs
Use commits de unidade de trabalho como base para PRs encadeados:
- Construa a menor unidade de trabalho independente.
- Inclua verificação para essa unidade.
- Commite com uma mensagem de commit convencional.
- Se o PR se aproximar de 400 linhas alteradas, promova commits ou grupos de commits em PRs encadeados.
Relação com SDD
Quando as sdd-tasks produzem uma Previsão de Carga de Revisão:
- Baixo risco: mantenha commits de unidade de trabalho dentro de um PR.
- Médio risco: commite por unidade de trabalho e monitore as linhas alteradas antes da criação do PR.
- Alto risco: siga a
delivery_strategydo SDD — pergunte emask-on-risk, fatie automaticamente emauto-chain, exijasize:exceptionemsingle-pracima do orçamento, ou registresize:exceptionaceito emexception-ok. - A divisão é limitada: após uma passagem honesta de fatiamento, se nenhuma divisão de unidade de trabalho coesa caber no orçamento, pare e reporte a menor contagem honesta com uma recomendação de
size:exception. Não itere encolhendo o código para atingir o número.
Cada unidade de trabalho SDD deve mapear-se claramente para um commit ou PR com:
- estado inicial claro,
- estado final claro,
- verificação na mesma unidade,
- rollback que não remova trabalho não relacionado.
Comandos
# Revisar a história antes de commitar
git diff --stat
git diff --cached --stat
# Verificar o estilo do commit recente
git log --oneline -5