salve

name

salve

description

Use quando o usuario disser "salve" (ou /salve) para entregar e persistir o trabalho atual de uma vez. Persiste contexto, commita, sobe no GitHub, abre e mergeia um PR na branch principal, dispara/confirma o deploy se o projeto tiver, atualiza a checkout local com fast-forward e reporta evidencia. Dizer "salve" e o OK explicito do usuario para mergear na branch principal e deployar. Variantes - "salve doc" (so-doc, usa [skip ci], sem redeploy) e "salve sem deploy" (push + PR, NAO mergear em producao).

salve - ship + persistir o trabalho atual

Gatilho: o usuario escreve salve (ou /salve). Dizer "salve" e o OK explicito do usuario para mergear na branch principal e deployar. E a unica aprovacao que o skill precisa; nao perguntar de novo, executar os passos e reportar.

Executar os passos NA ORDEM. Aplicar julgamento (mensagem de commit, resolucao de conflito). Se um passo falhar, PARAR e reportar, nao seguir cego.

0. Pre-flight

• git status e git branch --show-current. Ver o que mudou.
• Identificar a branch principal do projeto (main, master, ou a que o repo usar).
• Se mudou codigo (nao for so-doc): rodar os testes do projeto ANTES (ex.: npm test, pytest, go test). Se RED, PARAR e reportar. Nunca subir codigo quebrado.

1. Persistir contexto

• Atualizar as notas do proprio projeto pra proxima sessao continuar: uma secao de status num CLAUDE.md / README / NOTES.md (o que foi feito, o que falta), se o projeto mantiver.
• git add so do trabalho (nunca segredos; .env e credenciais ficam gitignored).
• Commit com subject claro + corpo. [skip ci] SO no modo salve doc.

2. Subir no GitHub

• git push -u origin HEAD.
• Em branch de feature: gh pr create --base <principal> e depois gh pr merge <#> --squash (o subject do squash carrega [skip ci] se for salve doc).
• Conflito de merge bloqueando: git fetch origin <principal> -> git merge origin/<principal> -> resolver -> push -> re-mergear.
• Ja na branch principal: push direto (ou branchar antes se o projeto exige PR).

3. Deploy (so se o projeto tiver)

• Se o host auto-deploya no push pra branch principal (Render, Vercel, Fly, Railway, etc.), confirmar que rodou - ver o dashboard de deploy ou um endpoint de health (ex.: curl -s -o /dev/null -w "%{http_code}\n" <prod-url>/health).
• Se o host NAO auto-deploya, disparar o deploy via CLI / API / dashboard dele. salve deploya por padrao.
• Se o projeto nao tem deploy, pular este passo.
• salve sem deploy: pular o merge-pra-producao - so push e abrir o PR, nao mergear.

4. Atualizar a checkout local

• Na checkout principal: git -C <raiz-do-projeto> pull --ff-only origin <principal>.
• Confirmar behind=0, ahead=0.

5. Reportar evidencia

• Commit SHA, PR #, merge SHA, estado do deploy/health, sync local. Rollback concreto (git revert <sha>).

Variantes

• salve doc - mudanca so-de-doc: usar [skip ci] no commit/merge, nao redeploya.
• salve sem deploy - push + persistir + abrir PR, NAO mergear na branch principal (deixa o PR pro usuario).

Seguranca

• Testes antes do merge. Red = parar.
• Nunca commitar segredos.
• Merge-na-principal + deploy so acontecem porque o usuario disse salve. Alem disso (rotacionar segredos, migracao destrutiva) continua sendo escalada - perguntar.

Notas

• Configurar uma vez por projeto: dizer ao skill a branch principal, o alvo de deploy (ou "nenhum") e a URL de health, e ele segue. Defaults sensatos (main, auto-deploy-no-push, /health).
• Trabalho original, licenca MIT.