Skill /test-and-ship pro Claude Code

O problema

Três cenas que você já viveu.

O PR está com o check verde. Ninguém percebe que o verde significa "nenhum
teste rodou" — o job foi pulado, e job pulado conta como sucesso. O bug entra em
produção com selo de aprovado.

O repositório tem Jest, mas não tem E2E. Tem lint, mas não mede complexidade.
Ninguém sabe se há dependência circular, código morto ou componente sem
acessibilidade, porque nenhuma ferramenta olha pra isso. Cada tipo de bug que não
tem gate é um tipo de bug que chega no usuário.

O agente escreve o código, você pede "roda os testes", ele reporta 14 falhas e
devolve a bola. Consertar vira o seu trabalho — que era exatamente o que você
queria delegar.

A causa comum: testar e shippar são tratados como etapas separadas, com um humano
de cola entre elas. Esta skill funde as duas e tira o humano do meio.

Como funciona

Três fases, sempre na mesma ordem.

Fase 0 — instala o que falta. Na primeira execução o agente inventaria o
repositório: quais gates existem, quais não. Test runner, E2E, mutação,
complexidade, arquitetura, código órfão, auditoria de dependências. O que faltar,
ele instala e configura com padrões mínimos que funcionam. Você não escreve um
jest.config na vida.

Fase 1 — testa e conserta. Quatro subagentes em paralelo. O tester roda os
gates do mais rápido ao mais caro e conserta cada falha em loop até verde — não
devolve lista de erros, devolve o diff que os elimina. O doc-checker edita a
documentação que a mudança tornou stale. O frontend-checker e o
knowledge-curator são read-only por construção, então não brigam com quem
edita. Vermelho que exige decisão de produto vira uma pergunta objetiva pra você.

Fase 2 — shippa. Só existe se o tester terminou 100% verde. Um shipper
dedicado: feature branch, commit apenas dos arquivos da tarefa (allowlist — nada
de git add .), push, PR com a evidência dos testes no corpo, merge quando o CI
fechar. E o orquestrador valida o shipper antes de confiar nele: confere que o
commit existe, que a allowlist inteira entrou (comparação de conjuntos, não leitura
a olho), que o merge aconteceu e que o conteúdo chegou na branch de destino. Nunca
commita direto na principal.

O que vem no pacote

Cinco versões da skill, uma por tipo de projeto — e cada uma é uma skill
multiagente completa: o SKILL.md (orquestrador: fases, gates, política de
autonomia, protocolo de ship e relatório) mais uma pasta agents/ com o prompt
integral de cada subagente.

Seu projeto	Pasta
Monorepo TypeScript (pnpm/Turbo, vários apps)	monorepo-typescript
App Next.js único	nextjs-app
SPA React com Vite	react-spa-vite
API Node/TypeScript (Express, Fastify, Nest)	api-node
Backend Python (Django ou FastAPI)	python-django-fastapi

Mais o Catálogo de Gates (os 12 tipos de teste, um a um), a Proposta de
Valor e o Como Usar. Instalação é uma linha: copia a pasta da sua variante
pra .claude/skills/test-and-ship e roda.

De onde ela vem

Não nasceu num tutorial. É a versão portável do fluxo que opera um monorepo de
produção com cinco aplicações Next.js, mais de 25 features migradas e dezenas de
sessões de agente rodando em paralelo na mesma máquina. Cada regra existe porque a
ausência custou caro uma vez:

• Verde que significa "não verifiquei" é indistinguível de verde que significa
  "verifiquei". O GitHub estampa "All checks have passed" mesmo com todos os jobs
  pulados. A skill lê o contador de skipped, não a frase.
• Piso de cobertura nunca desce. Três reduções de threshold em dois dias, cada
  uma com justificativa plausível por escrito. As três eram falsas ou evitáveis.
• Commit por allowlist, e depois a prova por comparação de conjuntos — um
  commit "de sucesso" já saiu com dois arquivos a menos e ninguém viu.
• Não confie no relato do subagente. Um shipper já reportou o commit antigo
  como novo e um merge que não aconteceu.

O que ela NÃO faz

Não é code review: gate verde quer dizer "compila e passa nos testes que existem",
não "está bom". Não escreve teste que não existe por decisão de produto. Não desfaz
nada — revert e force-push só se você pedir. E se o conserto honesto for grande,
ela para e devolve o problema em vez de calar o erro com any. De propósito.

Pra quem não é

Projeto descartável, spike, prova de conceito: o gate custa minutos por ship, e num
protótipo isso é peso morto. E time que não quer merge automatizado por política —
dá pra usar no modo "abre o PR e para", mas você perde metade do ganho.