Claude Code /simplify e /batch

Problema: Acabaste uma funcionalidade no Claude Code. Os testes passam. Também sabes que algumas funções se repetem, um helper foi reinventado, e há pelo menos um loop a fazer mais trabalho do que devia. Voltar a corrigir tudo à mão significa reler cada ficheiro que tocaste, identificar os pontos a melhorar tu mesmo, e corrigi-los um a um. Envia assim e a dívida técnica come-te no próximo sprint. Nenhuma opção parece boa.

Ganho Rápido: Logo depois de uma funcionalidade estar pronta, escreve /simplify. Lança três agentes de revisão ao mesmo tempo. Um vigia a reutilização de código. Um vigia a qualidade. Um vigia a eficiência. Juntam as notas, aplicam as correções, e devolvem-te um diff limpo. Sem prompt para escrever. Apenas o comando.

# After implementing a feature
/simplify
 
# Focus on a specific concern
/simplify focus on memory efficiency

Novo no Claude Code? O guia de introdução cobre o básico. Tens algo maior em mãos, como mover um codebase inteiro de um framework para outro ou aplicar uma mudança em dezenas de ficheiros? É para isso que serve o /batch. Ambos os comandos chegaram no Claude Code v2.1.63, e entre eles cobrem dois fluxos de trabalho que antes precisavam de prompting cuidadoso em múltiplos passos.

O Que o /simplify do Claude Code Faz

/simplify é um comando de limpeza pós-implementação. Quando o código já funciona, o /simplify relê o diff e melhora-o.

O primeiro passo é uma chamada a git diff (ou git diff HEAD) para ver o que mudou. Sem mudanças git? Recorre aos ficheiros tocados mais recentemente. A partir daí, três agentes de revisão vão em simultâneo. Cada um vê o diff completo:

Os três correm em paralelo. Quando terminam, o /simplify junta as notas, corrige cada problema real diretamente, e descarta silenciosamente o que parece um falso positivo. Recebes um resumo curto das correções, ou uma nota confirmando que o código já estava em forma.

Boris Cherny, o PM do Claude Code, enquadrou bem: estes comandos integrados "automatizam muito do trabalho que costumava ser necessário para levar um pull request à produção." O /simplify é o passe de revisão automatizado entre "funciona" e "está pronto para fazer merge."

Quando Usar /simplify

O ponto ideal é logo após a implementação, antes de abrir um PR:

• Depois de terminar uma funcionalidade -- limpa antes da revisão
• Depois de uma correção de bug -- certifica-te que a correção não introduziu atalhos
• Depois de um protótipo -- aperta o código experimental que queres manter
• Antes de um PR -- apanha problemas que um revisor sinalizaria

Queres estreitar o foco? Podes passar texto opcional:

/simplify focus on error handling
/simplify check for unnecessary dependencies
/simplify look at the database query patterns

É útil quando sabes que uma área está crua mas não queres escrever um prompt completo para descrever o codebase. O comando já sabe quais os ficheiros que se moveram.

O Que o /simplify Não É

O /simplify não é um linter. Também não é um formatter. Trabalha a um nível mais alto do que isso, olhando para decisões de arquitetura, estrutura de código, e escolhas de algoritmo. O ESLint e o Biome mantêm-se no loop. O /simplify trata as preocupações que essas ferramentas não conseguem apanhar. Para validação de conformidade, os hooks já existem.

Também não é uma ferramenta de refatoração geral. A atenção fica no que mudou recentemente, não no projeto inteiro. Para uma mudança a nível do codebase, queres o /batch.

O Que o /batch do Claude Code Faz

O comando /batch do Claude Code coordena grandes mudanças em todo o projeto, em paralelo. A interface para o utilizador é deliberadamente simples. Nada mais do que uma descrição e alguns exemplos de uso:

/batch migrate from react to vue
/batch replace all uses of lodash with native equivalents
/batch add type annotations to all untyped function parameters

Dizes o que tem de mudar. O /batch passa-o a um agente de orquestração mais profundo que faz a pesquisa, a decomposição, a execução, e a criação do PR. Nos bastidores, o orquestrador corre um loop de três fases.

Fase 1 -- Pesquisa e Plano. O orquestrador entra em modo de plano. Lança agentes Explore para traçar cada ficheiro, padrão, e call site que a instrução toca. A partir daí, divide o trabalho em 5 a 30 unidades autónomas, dimensionadas em relação ao codebase e à mudança. Cada unidade tem de ser implementável por si só dentro de uma worktree, e fazer merge por si só sem esperar que outra unidade chegue primeiro. O orquestrador também elabora uma receita de verificação de ponta a ponta, seja automação de browser, um teste de CLI, ou a tua suite de testes existente. Se não conseguir descobrir como verificar o trabalho, para e pergunta-te.

Fase 2 -- Lançar Workers. Depois de aprovares o plano, o orquestrador lança um agente em segundo plano por unidade. Todos saem num único bloco de mensagem, por isso o paralelismo é real. Cada agente corre com isolation: "worktree" para uma worktree git limpa. O prompt de cada agente é autónomo: o objetivo geral, a tarefa específica, e as convenções do codebase recolhidas durante a pesquisa. Também transporta a receita de teste de ponta a ponta e as instruções do worker. Depois de escrever o código, cada worker corre /simplify no seu próprio diff, corre a suite de testes, faz commit, push, e abre um PR com gh pr create.

Fase 3 -- Acompanhar o Progresso. O orquestrador renderiza uma tabela de estado e mantém-na atualizada à medida que os agentes terminam, extraindo URLs de PR da saída de cada worker. No final recebes uma linha de resumo como "22/24 unidades entregues como PRs."

O isolamento de worktree é a peça que faz tudo isto funcionar. Cada agente tem o seu próprio branch e a sua própria cópia de trabalho, o que significa que nenhum agente pode interferir com outro. Os conflitos de merge nunca aparecem. Cada unidade mantém-se testável e revisável de forma independente.

# Large-scale migration
/batch migrate src/ from Solid to React
 
# Pattern application
/batch add input validation to all API endpoints
 
# Convention enforcement
/batch rename all database columns from camelCase to snake_case
 
# Dependency update
/batch update all axios calls to use the new fetch wrapper

O Passo de Plano

Antes de um único ficheiro mudar, o /batch apresenta o plano. Vês cada unidade de trabalho, quais os ficheiros que planeia tocar, e o que a mudança envolve. Nada corre até aprovares.

É isso que torna o /batch previsível. Não estás a entregar o teu projeto a um processo autónomo e a cruzar os dedos. A decomposição é visível. Verificas que faz sentido. Depois deixas-o solto.

Se o plano estiver errado (talvez tenha perdido alguns ficheiros, talvez tenha agrupado as coisas mal), dizes-lhe para ajustar antes de a execução começar. É o mesmo espírito que os modos de plano para tarefas individuais, só que escalado para o repo inteiro.

Requisitos

O /batch precisa de um repositório git. Sem exceções. Cada unidade de agente corre dentro da sua própria worktree git, e cada uma abre um pull request no final. Fora de um repo git, o /batch recusa-se a começar.

A regra da worktree é também o que mantém as tuas mudanças seguras. O trabalho de cada agente fica no seu próprio branch. Se uma unidade falhar ou produzir código mau, as outras continuam. Os bons PRs fazem merge. Os maus são descartados.

Quando Usar /batch

O /batch destina-se a trabalho que paraleliza facilmente. Ou seja, dezenas ou centenas de ficheiros precisam todos do mesmo tipo de edição, e nenhuma edição individual depende de outra.

Bons casos de uso:

• Migrações de framework -- converter componentes de um framework para outro
• Mudanças de contrato de API -- atualizar todos os callers quando uma interface muda
• Conformidade de convenções -- aplicar convenções de naming, adicionar tratamento de erros, ou padronizar padrões em todo o codebase
• Trocas de dependências -- substituir uma biblioteca por outra em todos os sites de uso
• Geração de testes -- adicionar cobertura de testes a módulos não testados

Maus casos de uso:

• Mudanças fortemente acopladas onde o ficheiro A depende da nova saída do ficheiro B (estas não são unidades independentes)
• Refatoração exploratória onde ainda não sabes o estado final
• Mudanças de ficheiro único que não justificam decomposição

Se o trabalho precisa que os agentes se coordenem entre si, digamos que o agente A cria um utilitário partilhado e o agente B tem de o importar, o /batch é a ferramenta errada. Sessões regulares do Claude Code ou equipas de agentes tratam esse tipo de comunicação cruzada.

/simplify vs /batch: Quando Usar Cada Comando

Os dois comandos resolvem problemas diferentes a escalas diferentes. Framework de decisão:

Uma imagem mental útil: no Claude Code, o /simplify é o teu revisor de código. O /batch é a tua equipa de migração.

Também se combinam por design. Cada worker do /batch corre o /simplify nas suas próprias mudanças antes de fazer commit. Por isso, cada PR que sai do /batch já passou pelo passe dos três agentes. Sem encadeamento manual. A integração já está incluída.

Exemplos de Fluxos de Trabalho Práticos

Exemplo 1: Ciclo de Desenvolvimento de Funcionalidade

Acabaste de ligar um novo fluxo de autenticação em 4 ficheiros:

# 1. Implement the feature (normal Claude Code session)
"Add JWT authentication with refresh tokens to the API"
 
# 2. Clean up with /simplify
/simplify
 
# 3. Focus on specific concerns if needed
/simplify focus on security patterns in the auth flow

Os três agentes de revisão vasculham o código de auth à procura de lógica de validação de tokens duplicada, de problemas de qualidade como respostas de erro inconsistentes, e de problemas de eficiência como descodificação desnecessária de tokens.

Exemplo 2: Migração de Framework

O teu frontend tem 45 componentes de classe React que precisam de se tornar componentes funcionais com hooks:

# 1. Describe the migration
/batch convert all React class components in src/components/ to functional components with hooks
 
# 2. Review the plan (batch shows 15 units of ~3 components each)
# 3. Approve
# 4. Each agent creates a PR with its batch of conversions
# 5. Review and merge PRs individually

Cada PR é independente para revisão e merge. Se uma conversão ficar complicada e precisar de toque humano, esse PR fica de lado enquanto os restantes continuam.

Exemplo 3: Padronização de API

Os teus endpoints de API usam formatos de resposta de erro inconsistentes:

/batch standardize all API error responses to use { error: string, code: number, details?: object } format

O /batch encontra cada endpoint, agrupa-os em unidades independentes (geralmente por ficheiro de rota ou domínio), e lança cada agente nas suas rotas atribuídas. Cada unidade corre a suite de testes existente depois das edições, por isso sabes rapidamente se algo quebrou.

Comandos Integrados vs. Slash Commands Personalizados

/simplify e /batch são comandos integrados do Claude Code. Vêm com cada instalação e funcionam imediatamente. Os slash commands personalizados são o outro tipo: prompts específicos do projeto que escreves tu mesmo, seja na tua configuração CLAUDE.md ou em .claude/commands/, muito como as skills que defines para o teu próprio fluxo de trabalho. Os comandos integrados são mantidos pela Anthropic e enviam atualizações com cada versão do Claude Code.

A diferença importa porque os comandos integrados acedem a capacidades internas que os comandos personalizados não conseguem. O /batch pode lançar agentes em worktrees isoladas e abrir PRs automaticamente. O /simplify pode disparar o seu pipeline de revisão de três agentes sem tu escreveres uma única linha de cola de orquestração.

Dito isso, os dois lados complementam-se. Os comandos personalizados têm as coisas específicas do projeto (o teu processo de deploy, as tuas convenções de teste, os teus padrões de geração de código). Os comandos integrados têm as coisas universais (revisão de código, edições em todo o codebase) que se aplicam a qualquer projeto.

Construíste os teus próprios fluxos de trabalho de sub-agentes que fazem manualmente um passe de revisão multi-agente? O /simplify pode substituí-los completamente. Tens vindo a escrever scripts para aplicar edições repetitivas em ficheiros? O /batch é a versão nativa do Claude desse script.

Dicas para Usar /simplify e /batch Eficazmente

Corre /simplify antes de cada PR. Torna-o um hábito. O passe dos três agentes apanha coisas que vais perder depois de horas de trabalho com a cabeça metida na implementação. Na prática, o /simplify apanha consistentemente 3 a 5 problemas por branch de funcionalidade que de outra forma apareceriam durante a revisão de código. O agente de eficiência em particular é forte a apanhar iterações desperdiçadas e oportunidades de concorrência perdidas.

Sê específico com as descrições do /batch. "Atualiza o codebase" é demasiado vago. "Substitui todas as importações de moment.js por dayjs, atualizando as chamadas de API para corresponder à sintaxe do dayjs" dá ao planeador contexto suficiente para decompor o trabalho corretamente.

Verifica o plano do /batch com atenção. O passo de decomposição é onde a maioria dos problemas aparece. Se uma unidade cobre demasiados ficheiros ou mistura mudanças independentes, pede uma divisão diferente antes de aprovar.

Usa o texto de foco opcional do /simplify. Quando sabes que uma área está crua, talvez porque tomaste um atalho durante a prototipagem, aponta o /simplify diretamente para lá. Uma revisão direcionada dá melhores resultados do que uma varredura genérica.

Combina /batch com a tua suite de testes. Cada agente do /batch corre testes depois de editar. Certifica-te que esses testes realmente apanham regressões. Testes fracos significam que os agentes do /batch vão "passar" código quebrado.

FAQ

O /simplify modifica ficheiros automaticamente?

Sim. O /simplify escreve correções diretamente na tua cópia de trabalho. Revê-as com git diff antes de fazer commit. Correção errada? git checkout no ficheiro para a reverter.

O que acontece se um worker do /batch falhar?

Um worker falhado não deita abaixo os outros. Cada um corre na sua própria worktree git, no seu próprio branch. A falha aparece na tabela de estado, e ou retentas essa unidade ou tratas-a à mão. Os PRs que já chegaram ficam intactos.

Que versão do Claude Code inclui estes comandos?

/simplify e /batch chegaram no Claude Code v2.1.63. Corre claude --version para verificar. Numa build mais antiga, claude update os traz.

O /batch funciona em monorepos?

Sim. O /batch funciona em qualquer repositório git. Dentro de um monorepo, sê específico sobre quais os pacotes ou diretórios a visar na tua descrição para que o planeador decomponha o trabalho corretamente.

Como é que o /simplify difere de um linter?

Os linters apanham problemas de sintaxe e estilo. O /simplify apanha problemas de arquitetura: lógica duplicada, abstrações perdidas, ineficiências de performance, e padrões que um revisor humano sinalizaria. Cobrem camadas diferentes.

Próximos Passos

• Lê sobre git worktrees no Claude Code para entender o modelo de isolamento que o /batch usa
• Vê como o /simplify e o /batch se encaixam no sistema completo de slash commands do modo interativo, incluindo controlos de sessão, atalhos de teclado, e perguntas laterais /btw
• Aprende como as equipas de agentes funcionam para tarefas multi-agente coordenadas que o /batch não consegue tratar
• Explora slash commands personalizados para construir fluxos de trabalho específicos do projeto ao lado destes integrados
• Revê as melhores práticas de sub-agentes para desenhar os teus próprios padrões multi-agente
• Vê o guia de loops de feedback para construir ciclos de revisão no teu processo de desenvolvimento
• Vê o changelog completo do v2.1.63 para tudo o mais que chegou com estes comandos
• Precisas de instalar ou atualizar o Claude Code? O guia de instalação cobre a configuração em todas as plataformas, incluindo os comandos de instalação numa linha

/simplify e /batch mostram para onde o Claude Code está a caminhar: fluxos de trabalho multi-agente integrados que tratam padrões de engenharia comuns imediatamente. Ainda revês cada diff. Ainda aprovas cada plano. Mas o trabalho de orquestração, o lançamento de agentes em paralelo, a gestão de worktrees, a agregação de resultados, já não é algo que precisas de montar tu mesmo. Espera mais comandos integrados nesta linha à medida que a plataforma amadurece.

Queres um framework de desenvolvimento com orquestração de agentes pré-construída, slash commands personalizados, e padrões multi-agente que se encaixem ao lado destes comandos integrados? O ClaudeFast Code Kit vem com 18 agentes especializados e um pipeline desenhado exatamente para este tipo de fluxo de trabalho.