ship — colocar o trabalho em produção (git + gh)
Fluxo de trabalho ship independente de plataforma. Sem desvios, sem atalhos.
Pré-push: pipeline CI local (tudo verde antes de enviar)
- Formatação —
cargo fmt --check/prettier --check/ruff format --check - Lint —
cargo clippy -- -D warnings/eslint/ruff check - Type-check —
cargo check/npx tsc --noEmit - Testes —
cargo test/npm test/pytest(saída exibida) - Build —
cargo build/npm run build
Se uma etapa falhar: corrija e execute todas as verificações novamente. Nunca envie com falhas conhecidas.
Sequência
- Branch dedicada (nunca trabalhe diretamente em
main). - Commit por fase, mensagens convencionais e baseadas em evidências (SHA/PR/CI).
git pushda branch.- Abrir PR: Resumo + Plano de testes (template de 5 seções se o repositório usar um).
- Acompanhar CI:
gh pr checks <n>— tudo SUCESSO antes de prosseguir. - Merge: apenas merge-commit (nunca squash, nunca rebase — preserva o histórico para agentes paralelos).
- Pós-merge: deletar a branch, fazer fast-forward da
mainlocal, reportar o SHA do merge commit.
Portões humanos (PARE — pergunte primeiro)
- Merge para
mainque impacta branch-protection / segurança / licença / infraestrutura de release (#1) - Force-push para
main(#2) — sempre proibido sem confirmação explícita - CI não totalmente verde → não faça merge de nada pendente/com falha
Comentários de revisão
Cada comentário (humano ou bot) deve ser analisado, compreendido e resolvido adequadamente — nunca
resolva em silêncio, nunca um "conserto" que apenas toca na linha citada ignorando o conteúdo.
Responda no tópico com o que fez e porquê, depois resolva. Veja skills/review.