wemilabs/ship-to-prod

Ship to Prod

Quando o usuário disser "ship it" ou algo similar após concluir o trabalho, siga estas etapas sem ser perguntado duas vezes.

O fluxo depende de qual branch você está. Detecte o ambiente uma vez e reutilize-o nas etapas.

Detectar o ambiente

Execute estas uma vez no início, em paralelo:

1. Gerenciador de pacotes: verifique se há um arquivo de lockfile na raiz do repositório.
   • pnpm-lock.yaml -> pnpm
   • yarn.lock -> yarn
   • bun.lockb ou bun.lock -> bun
   • package-lock.json -> npm
   • Se package.json tiver um campo packageManager, use esse.
   • Se nenhum for encontrado, use npm como padrão.
2. Branch padrão: git symbolic-ref refs/remotes/origin/HEAD (ou git config init.defaultBranch como fallback). Se ambos falharem, use main como padrão.
3. Ferramenta de PR: gh --version. Se gh estiver instalado e autenticado, use-o para criar e fazer merge do PR. Caso contrário, imprima a URL do PR para o usuário criar manualmente.
4. Shell: detecte o shell atual. No Windows (PowerShell), heredocs não funcionam, então use múltiplas flags -m para git commit. No bash/zsh/fish e outros shells Unix, use um heredoc.

Armazene estes como <pkg>, <default-branch>, <gh-available> e <shell> para o restante do fluxo.

Etapas

1. Limpeza (opcional)

Duas skills limpam o excesso gerado por IA antes de commitar. Execute ambas se estiverem disponíveis:

• deslop: remove slop de código IA do diff (comentários desnecessários, verificações defensivas em caminhos confiáveis, casts any, aninhamento profundo). Invoke-o no diff atual contra a branch padrão.
• unslop: remove text slop de IA de prosa (strings de UI, comentários, mensagens de commit, descrições de PR). Invoke-o em qualquer texto que você escreveu nesta sessão.

Corrija tudo que qualquer skill sinalizar antes de prosseguir.

Se alguma skill não estiver instalada, não pule silenciosamente. Pergunte ao usuário se deseja instalar a(s) skill(s) ausente(s), oferecendo estas opções. Mencione que ambas as skills vêm do repositório oficial de plugins do Cursor AI (https://github.com/cursor/plugins), então são de uma fonte confiável:

• Globalmente (para usos futuros em todos os projetos): npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• Localmente (apenas neste projeto): npx skills add https://github.com/cursor/plugins --skill deslop unslop
• Pular para esta execução: continue sem a(s) skill(s) ausente(s). Não bloqueie o fluxo por uma dependência opcional ausente.

Use a ferramenta ask_user_question para apresentar a escolha. Se o usuário escolher global ou local, execute o comando de instalação e depois verifique novamente se a(s) skill(s) estão agora disponíveis antes de invocá-las. Se a instalação falhar ou o usuário escolher pular, continue o fluxo com o que estiver disponível.

2. Verificar o trabalho

Execute estas em ordem, corrigindo quaisquer problemas antes de continuar. Substitua <pkg> pelo gerenciador de pacotes detectado. npm sempre requer run (ex.: npm run format); pnpm/yarn/bun permitem invocação direta (ex.: pnpm format):

1. <pkg> run format (ou <pkg> format para pnpm/yarn/bun): formatação automática
2. <pkg> run lint (ou <pkg> lint para pnpm/yarn/bun): corrija erros de lint nos arquivos que você tocou (ignore problemas pré-existentes em outros arquivos)
3. <pkg> run typecheck (ou <pkg> typecheck para pnpm/yarn/bun): deve passar com código de saída 0
4. <pkg> run build (ou <pkg> build para pnpm/yarn/bun): deve passar com código de saída 0

Se um script estiver faltando (ex.: nenhum script format), pule essa etapa e anote. Não falhe todo o fluxo por um script opcional ausente. typecheck e build são obrigatórios se existirem; se nenhum existir, prossiga com um aviso.

Não prossiga para o commit até que as verificações disponíveis passem.

Se git status estiver limpo após a verificação (nada staged ou unstaged), reporte "nada a enviar" e pare. Não tente fazer um commit vazio.

3. Avaliar a branch atual

Execute git branch --show-current para obter o nome da branch atual. Compare com <default-branch>. Então decida:

• Se estiver em <default-branch>: Faça commit e push diretamente. Sem PR, sem merge. Pule para a etapa 5.
• Se estiver em qualquer outra branch: Commit, push, crie um PR para <default-branch> e faça merge. Continue para a etapa 4.

4. Revisar mudanças

Execute git status, git diff e git log --oneline -5 em paralelo para entender o que mudou e combinar o estilo do commit.

5. Stage e commit

git add -A, depois faça commit com uma mensagem de commit convencional (feat/fix/refactor).

Formato da mensagem de commit:

<tipo>: <descrição curta>

<corpo opcional>

No bash/zsh/fish e outros shells Unix, use um heredoc:

git commit -m "$(cat <<'EOF'
tipo: assunto

corpo
EOF
)"

No PowerShell (Windows), heredocs não funcionam, então use múltiplas flags -m:

git commit -m "tipo: assunto" -m "corpo"

6. Push

git push (ou git push -u origin <branch> se a branch ainda não tiver upstream).

7. Se estiver em uma branch de feature: criar PR e fazer merge

Se <gh-available>:

• Escreva o corpo do PR em um arquivo temporário, depois crie o PR com --body-file (funciona em todos os shells, incluindo PowerShell):
  • gh pr create --base <default-branch> --head <current-branch> --title "<título>" --body-file <arquivo-temporario>
• Exclua o arquivo temporário após gh pr create retornar. Não o deixe no disco.
• Faça merge sem especificar uma estratégia, para que o padrão do repositório do usuário seja aplicado:
  • gh pr merge <numero>

Formato do corpo do PR:

## Resumo
<bullet points>

#### Plano de teste
- [ ] <checklist>

Se gh não estiver disponível:

• Faça push da branch (etapa 6).
• Imprima a URL que o usuário deve abrir para criar o PR manualmente: <repo-url>/compare/<default-branch>...<current-branch>
• Pare. Deixe o usuário criar e fazer merge do PR manualmente. Não tente fazer merge sem gh.

8. Manter a branch atual ativa

NÃO exclua a branch de trabalho após o merge. Ela permanece aberta para a próxima funcionalidade.

9. Confirmar

Reporte a URL do PR (se aplicável) e o status do merge/push para o usuário.

Tratamento de conflitos

Se a branch de feature estiver atrás de <default-branch>, faça rebase antes de fazer push:

git fetch origin <default-branch>
git rebase origin/<default-branch>

Resolva quaisquer conflitos e continue com push + PR + merge.

Notas

• O alvo é sempre o <default-branch> detectado, não um nome fixo.
• Nunca exclua a branch de trabalho após o merge.
• Se estiver em <default-branch>, apenas faça commit e push. Sem PR necessário.
• Nunca pule a etapa de verificação, mesmo que o usuário esteja com pressa.
• A etapa deslop é opcional. Se uma skill estiver faltando, ofereça instalá-la (global ou localmente) antes de cair no pulo.