amanjotx/Skills-de-Agente

/ship

Faça commit do trabalho atual, envie-o e abra um pull request. Invocar esta habilidade é permissão explícita para criar/alternar branches, commitar, enviar e executar gh pr create.

Regras rígidas

• Siga o protocolo de segurança git do usuário: nunca altere a config do git; nunca pule hooks; nunca force-push para main/master; faça amend apenas quando as regras de amend do usuário forem totalmente satisfeitas.
• Nunca commite segredos (.env, credenciais, chaves privadas, tokens). Avise e exclua-os se presentes.
• Faça stage apenas de arquivos que pertencem a esta alteração. Não use git add . / git add -A de forma genérica, a menos que a árvore esteja claramente intencional e limpa de lixo.
• Use HEREDOC para mensagens de commit e corpos de PR.
• Mantenha este fluxo de trabalho agnóstico a projetos. Infira comandos de verificação e layout a partir do repositório; não codifique nomes de aplicativos ou pacotes.
• Retorne a URL do PR quando terminar.

Prefixos de commit convencionais

Use Commits Convencionais de nível de produção. Escolha um tipo principal:

Prefixo	Quando
feat	Nova funcionalidade voltada ao usuário
fix	Correção de bug
refactor	Reestruturação interna sem mudança de comportamento
perf	Melhoria de performance
chore	Manutenção, ferramentas, dependências, tarefas internas
docs	Apenas documentação
test	Apenas testes
ci	Configuração / pipelines de CI
build	Mudanças no sistema de build ou bundler
style	Formatação / alterações de lint sem mudança de lógica
revert	Reverter um commit anterior

Formato:

tipo(escopo-opcional): resumo imperativo

Corpo opcional: por que esta alteração existe (1–2 frases).

Exemplos: feat(auth): add refresh token rotation, fix: prevent double-submit on checkout, chore: bump lint config.

Fluxo de trabalho

1. Inspecionar (executar em paralelo)

• git status
• git diff e git diff --staged
• git branch -vv (branch atual + tracking)
• git log -8 --oneline (estilo das mensagens)
• Branch base padrão (main preferido, senão master ou padrão do repositório)
• Estado da sincronização remota (git status -sb, commits não enviados)

Se não houver nada a commitar e nenhum commit não enviado relevante para este trabalho, pare. Não abra um PR vazio.

2. Garantir o branch correto

Objetivo: colocar o trabalho em um branch de feature dedicado baseado na base mais recente.

1. Determine se o branch atual é destinado a estas alterações:

   • Sim se já é um branch de tópico descritivo para este trabalho (feat/…, fix/…, chore/… ou claramente correspondente à intenção da mudança) e não é o branch padrão.
   • Não se estiver em main/master/padrão, um branch de tópico incompatível, um branch não relacionado desatualizado ou um HEAD destacado.

2. Se o branch atual não é destinado a estas alterações:

   • Se a árvore de trabalho estiver suja, faça stash com uma mensagem clara (padrão; não pergunte a menos que seja impossível fazer stash).
   • git checkout <base>
   • git pull --ff-only (ou equivalente atualização fast-forward do tracking remoto)
   • Crie e checkout de um novo branch descritivo, ex. feat/short-topic, fix/short-topic, chore/short-topic
   • git stash pop para o novo branch; resolva conflitos se houver.

3. Se o branch atual é destinado a estas alterações:

   • Permaneça nele.
   • Antes de commitar, atualize a partir da base quando necessário (rebase ou merge da base mais recente conforme as normas do repositório; prefira opções não destrutivas; não force-push a menos que o usuário peça explicitamente).

Nunca construa um PR diretamente do branch padrão.

3. Commit

• Prefira um commit coerente, a menos que o usuário tenha solicitado divisão.
• A mensagem usa um prefixo convencional adequado e um resumo imperativo.
• Corpo (opcional): foque no porquê, não em uma lista de arquivos.
• Após o commit, execute git status para confirmar o estado esperado.
• Se um hook falhar: corrija o problema e crie um novo commit. Não faça amend a menos que as regras de amend estejam totalmente satisfeitas.

4. Push

git push -u origin HEAD

Solicite permissões necessárias quando sandbox/rede/gh bloquear a operação.

5. Abrir o PR

Analise todos os commits que serão mesclados na base (não apenas o mais recente).

Título: mesmo espírito do resumo do commit — claro, específico, convencional quando ajuda. Sem títulos vagos.

Template do corpo (obrigatório):

## Resumo

- 2–5 bullets sobre o que é enviado e por que é importante

## Por quê

- Problema, motivação ou gatilho para esta mudança

## O que mudou

- Bullets agrupados por preocupação (comportamento, API/contratos, dados, UI, infra, testes, docs)
- Explique explicitamente mudanças de quebra, migrações ou alterações de comportamento de autenticação/sessão

## Arquitetura / fluxo

Inclua pelo menos um:

1. Diagrama Mermaid (sequência, fluxograma ou estado) para o caminho principal
2. Diagrama ASCII para estrutura, camadas ou antes → depois

Use Mermaid para fluxo de controle; ASCII para árvores ou mapas de camadas.
Os diagramas devem corresponder ao diff real — não invente arquitetura.

## Risco / rollback

- Modos prováveis de falha
- Notas de reversão segura / mitigação

## Plano de testes

- [ ] Passos concretos que um revisor pode executar
- [ ] Comandos de verificação apropriados ao repositório descobertos a partir do projeto

Crie com gh pr create e um corpo HEREDOC. Defina --base explicitamente quando necessário.

6. Relatar de volta

Mantenha curto:

• nome do branch
• resumo do commit
• título do PR
• URL do PR
• quaisquer arquivos intencionalmente não commitados