dev-shiplisted

# /dev-ship — Pronto é estado verificado, não sensação Task ✅ ≠ feature ✅. Esta skill é a barreira entre "terminei as tasks" e "isso pode ir pra produção". Roda no fim de um PLAN.md ou standalone sobre qualquer diff que o usuário queira fechar. ## Processo ### 1. Verificação dura (must_pass global) Rode, na ordem, o que o projeto tiver (CLAUDE.md diz quais): 1. Typecheck / build 2. Suite de testes completa (não só os módulos tocados) 3. Lint **Qualquer vermelho para o ship aqui.** Vermelho vira fix-task (ou `/dev-fix`) — nunca "é flaky, ignora". ### 2. Must-Haves do PLAN.md (goal-backward) Se existe `.plans/<feature>/PLAN.md`: - **Truths:** cheque cada behavior listado — idealmente via smoke test, não inspeção visual - **Artifacts:** cada arquivo existe? min_lines? exports/contains corretos? - **Key Links:** rode os regex declarados — devem casar - **Demo script:** execute os passos. A feature demonstra em 60s ou não demonstra? Falhou qualquer um → diagnostique por que a task "completed" não satisfez o goal, crie fix-task no PLAN.md, execute, re-verifique. **Loop até verde. Não mascare.** ### 3. Revisão do diff (você é o reviewer agora) Leia o diff completo da feature (`git diff <base>...HEAD` ou working tree) com olhos de reviewer, não de autor: **Caçada a restos:** - `console.log` / `print` / `dbg!` de debug, prefixos `[DEBUG-*]` - `TODO`/`FIXME`/`HACK` novos sem issue ou justificativa - Código comentado, imports não usados, arquivos órfãos - Dependência adiciona