Processo · novembro de 2026
O processo e o método que usei em mais de 30 PRs de design system e dark mode em produção, e o que aprendi fazendo. Eu decido produto e visual; o Claude atua como dev sênior; a engenharia revisa e faz o merge.
Cada card vira uma sessão do Claude, numa worktree própria, com um prompt de entrada claro e dois pontos de parada: o plano e a evidência. O resto (código, validação, prints, testes, PR) o Claude executa e me mostra. Commit e PR, só quando eu peço.
O que mais mudou o resultado foi deixar explícita a fronteira de decisão: o Claude resolve sozinho o que é técnico e reversível, e me consulta quando a decisão é de produto, de visual, envolve outra pessoa ou não tem volta.
Dez passos em quatro fases. Escolha um passo na linha do tempo ou use as setas do teclado. Em amarelo, os pontos de parada: o Claude para e espera a minha decisão.
Título curto (uns 40 caracteres), escopo claro e uma lista do que não mexer. Uma PR por card. Se o escopo crescer no meio, vira outro card.
Um card que cresceu no meio virou dois: duas PRs menores, revisadas mais rápido.
Uma sessão por card, renomeada com o ID e o título, para cada uma ser achada na barra lateral. E uma worktree nova, saindo da branch principal atualizada. Nunca uma branch velha: ela mostra telas que não existem mais.
O Claude roda o setup do time: dependências, bibliotecas internas, variáveis de ambiente e banco.
DS-14 PR 3: campos do cadastro
Antes de qualquer print, conferir de onde o ambiente está rodando.
Em vez de explicar a tarefa de cabeça a cada vez, um prompt com o objetivo, a referência visual, o que fica de fora, as regras e os pontos de parada. Com a skill instalada, ele fica curto.
O gerador de prompt monta o de uma PR e o da orquestradora.
Antes de editar qualquer arquivo, o Claude manda o plano: arquivos, componentes que vai usar, o que fica igual e riscos. Eu aprovo ou corrijo. É o passo que mais evita retrabalho.
“Plano do DS-14: 3 arquivos na tela de Pedidos. Troco o fundo fixo da lista pelo token de superfície e os selos pelo Badge do design system; validação e payload ficam iguais. Risco: o aviso amarelo pode perder contraste no claro, vou conferir nos prints. Posso seguir?”
Acompanho pelo navegador do app e confiro a tela nos dois temas. Ajuste visual é decisão minha.
O esquema do comparativo e o critério de performance.
Validações do time só nos pacotes tocados: lint, tipos, testes, código morto. Se o time exige documentação para mudança visível, ela entra na mesma PR.
Checagem global e builds grandes com o ambiente no ar sobrecarregam a máquina. O que é pesado roda com o ambiente parado.
Um revisor separado (um subagente ou outra sessão no papel de revisor) olha só o diff, procurando bug. Quando há ajuste depois, roda de novo.
A segunda rodada costuma pegar efeito colateral criado pela correção da primeira.
Apontamentos do bot de revisão: o Claude corrige o que é do escopo e responde na thread.
Comentário de pessoa: a conversa é minha. O Claude traz o contexto técnico de cada ponto quando eu peço e aplica o que for combinado.
O método acima não nasceu pronto. Cada regra dele veio de algo que deu errado ou que funcionou melhor do que o esperado.
Sem o comparativo, um trabalho de correção passa despercebido: quem revisa não vê o que mudou, e quem usa nunca soube do problema. Por isso a evidência é um ponto de parada, e não um anexo.
Um script conta, a cada merge, quantos usos do componente antigo ainda existem, e uma regra de lint impede usos novos. Sem a trava, cinco arquivos novos com o componente antigo apareceram em quatro dias.
Uma rodada de performance feita com horas de intervalo mostrou uma piora de 21% que não existia. Medindo as duas branches uma depois da outra, a diferença sumiu.
Os bugs mais sérios estavam em telas que ninguém tinha pedido para olhar. Abrir cada tela para trocar o componente revela o que já estava quebrado em volta.
A IA reescreveu um conjunto de abas para deixá-las “mais limpas” e quebrou a identidade da plataforma. Isso virou regra: não reconstruir o que já existe, e reusar o componente da tela de referência.
Uma segunda sessão, olhando só o diff, encontrou um bug que já estava em produção. Desde então, a revisão roda de novo sempre que há ajuste depois dela.
O número vem antes do compromisso. E cada PR mexe numa área só, para poder voltar atrás sem desfazer o resto.
Quando o Claude erra algo que não pode se repetir, a correção vai para a memória do projeto, com o porquê. Com o tempo, o processo mora nas memórias e nos arquivos de regras, e os prompts ficam curtos.
O comparativo é sempre a mesma grade: antes à esquerda, depois à direita; claro em cima, escuro embaixo. Quem revisa encontra a diferença sem ler nada.
Exemplo: no escuro, a lista ficava com fundo claro fixo e os selos sumiam. Depois, usa o token de superfície; o claro não muda. Se a troca é invisível para quem usa, como uma biblioteca de formulários, o comparativo mostra o estado de erro: as mesmas mensagens, no mesmo lugar.
Cada PR roda na sua sessão e worktree, mas o ambiente local costuma ser um só: portas fixas, um banco. Só uma worktree fica no ar por vez. A orquestradora é a única dona dele e decide quem usa.
Trocar o ambiente à mão, PR por PR, não escalou: cada troca dependia de alguém disponível naquela hora, e as PRs ficavam esperando. Com a orquestradora dona do ambiente, a fila anda sozinha.
STATUS.md, o quadro de todas as PRsDecisões de design, commit e PR continuam vindo direto para mim.
Uma tarde com duas PRs e a orquestradora. Avance passo a passo e leia, embaixo, por que cada coisa acontece.
Cada uma com o jeito de evitar. A skill avisa o Claude de todas.
git add -A com o ambiente no ar; stage só do escopo e conferir o diff antes do push.Comece pelo A. Quando a entrega for maior que uma PR, passe para o B.
Uma PR, uma pessoa conduzindo a sessão. Não precisa de orquestração, pasta de evidência nem scripts.
A primeira configuração do ambiente local é a parte mais trabalhosa: vale fazer com alguém da engenharia.
Uma orquestradora tocando a frente inteira. Para uma área, uma migração ou um conjunto de telas. A conversa é com uma sessão só; ela faz o resto e chama nos pontos de decisão.
Faça o caminho A pelo menos uma vez antes, para conhecer as etapas que ela vai automatizar.
Grátis · sem cadastro
A skill faz o Claude seguir o processo sozinho; o guia explica cada passo em texto corrido. Copie, baixe e adapte ao seu time.
Ou instale com um comando, no terminal onde roda o Claude Code:
Depois, preencha a configuração do time no topo do arquivo (o que ficar vazio, o Claude pergunta na primeira vez) e chame pelo nome numa sessão nova: “use o processo-frontend no card DS-14” ou /processo-frontend.
Carregando…
Opcional: quer aviso quando sair uma versão nova? Só isso, sem newsletter.
Pronto. Te aviso quando sair a próxima versão.
Preencha e copie. O que falta aparece em amarelo. Os campos ficam salvos só neste navegador.
evidencias-<card>.md# Evidência · <ID> <título> ## Prints Antes (principal) à esquerda, depois (branch) à direita; claro em cima, escuro embaixo. - <tela>: padrão, erro, desabilitado ## E2E da área - Principal: <x de y> · Branch: <x de y> - Pré-existentes (já falham na principal): <teste e motivo> ## Performance (as duas em sequência, na mesma janela) | Tela | LCP antes | LCP depois | Diferença | CLS antes | CLS depois | Long tasks novas | |-|-|-|-|-|-|-| ## Comportamento - Validação, textos, payload e data-testid iguais: <como foi conferido> ## Validações - <lint, tipos, testes>: <resultado> - Não rodou, e por quê: <...> ## Revisão independente - Rodada 1: <achados e o que mudou> - Rodada 2: <se houve ajuste depois>
Os termos técnicos desta página. No texto, eles aparecem com sublinhado pontilhado: clique para ver.