Claude Code: o fluxo importa mais que a lista de comandos

Toda ferramenta de agente ganha, em algum momento, a sua cartilha de comandos. Elas são úteis por umas quatro semanas. Depois a versão muda, dois comandos somem, três nascem, e a cartilha vira desinformação com aparência de guia.

A parte que não envelhece é outra: em que ordem usar, e por quê. Essa parte a documentação oficial não escreve, porque ela depende de como você trabalha.

Quatro tipos, não uma lista

Antes de decorar comando, vale separar o que você está olhando. Os quatro tipos se comportam de forma diferente, e confundi-los gera expectativa errada.

Built-in. Lógica fixa e determinística. /clear, /compact, /rewind, /init, /help. Fazem exatamente a mesma coisa toda vez.

Skills empacotadas. Também vêm de fábrica, mas são instruções que o modelo segue — /code-review, /security-review, /simplify. O resultado varia com o contexto, e isso é característica, não defeito.

Suas skills. Você escreve. Hoje são a mesma coisa que as empacotadas, só que moram no seu repositório.

MCP. Vêm dos conectores que você plugou. Aparecem e somem conforme a conexão.

A diferença prática: built-in você chama e confia. Skill você chama e verifica, porque a saída depende do que o modelo entendeu do seu código.

O fluxo

Essa é a sequência que evita a maior parte das dores:

1. Planejar — modo plano. Você aprova antes de qualquer arquivo ser tocado.
2. Implementar.
3. Limpar — /simplify. Reúso, simplificação, eficiência. Não caça bug.
4. Revisar — /code-review. Aceita nível de esforço; use alto no que for sensível.
5. Segurança — /security-review, sempre que a mudança tocar autenticação, permissão ou qualquer caminho onde a IA acessa dado.
6. Provar — subir a aplicação e olhar. "Compila" não é "funciona".
7. Publicar.

O passo que quase todo mundo pula é o 6. Compilar é uma afirmação sobre sintaxe; funcionar é uma afirmação sobre o mundo. Só a segunda importa.

A rede de segurança é o que muda o jogo

Trabalhar com agente sem rede de segurança é o que faz a experiência parecer arriscada. Com rede, ela deixa de ser aposta.

Modo plano é a rede mais barata. Numa tarefa que encosta em oito arquivos, ver o plano antes custa dois minutos e economiza uma tarde de desfazer.

/rewind desfaz o estado da sessão. Saber que existe muda o comportamento: dá para deixar o agente tentar algo ousado, porque o custo do erro caiu.

/permissions define a fronteira de confiança — o que roda sem perguntar. Vale ajustar cedo: interrupção a cada comando cansa e leva a aprovar no automático, que é o pior dos dois mundos.

O CLAUDE.md é o item de maior alavancagem

De tudo, é o que mais rende — e o mais ignorado.

/init escaneia o projeto e gera o arquivo. Ele é lido toda vez que a sessão abre, então é ali que moram as coisas que você não quer repetir: convenções do projeto, o que nunca deve ser alterado sem revisão, qual shell você usa, o que já deu errado antes.

Sem ele, toda sessão começa do zero e você reexplica o contexto. Com ele, o contexto é infraestrutura.

Vale tratá-lo como código: versionado, revisado, discutido. É documentação que alguém realmente lê — inclusive uma máquina.

Suas skills

O formato recomendado hoje é uma pasta por skill:

.claude/skills/<nome>/SKILL.md

Com frontmatter declarando nome, descrição e as ferramentas permitidas:

---
name: publicar
description: Publica o projeto. Use apenas depois de code-review e
  security-review passarem.
allowed-tools: Bash, Read
---

# Publicar

Confirme antes:
1. /code-review sem achado crítico
2. /security-review, se a mudança tocou autenticação ou permissão
3. A aplicação subiu e foi verificada de verdade

Depois, execute os passos de publicação do projeto.

A vantagem sobre o formato antigo de comandos é que a description permite ao agente acionar a skill sozinho quando o contexto pede. Uma descrição vaga desperdiça isso.

Se você fixar o modelo na skill, confira o identificador contra a documentação da versão instalada. Identificador de modelo é a coisa que mais rápido fica desatualizada em exemplo copiado da internet.

Cinco pegadinhas

Não encadeie comandos numa mensagem só. Pedir revisão, compactação e continuação no mesmo prompt produz resultado pior que fazer um de cada vez.

Compacte antes de travar, não depois. Em sessão longa, rodar /compact antes de começar uma tarefa pesada é diferente de rodar quando o contexto já estourou.

Trocar de modelo no meio da sessão bagunça o contexto. Prefira abrir sessão nova já no modelo certo.

O menu é a fonte da verdade. Digitar / mostra o que a sua instalação tem. Qualquer lista escrita — inclusive esta — está desatualizada em algum grau no momento em que você lê.

Segurança não é etapa opcional. Se a mudança encosta em autenticação, permissão ou no caminho que dá acesso a dado, a revisão de segurança deixa de ser zelo e passa a ser requisito.

O que sobra

A lista de comandos vai mudar. O fluxo — planejar, implementar, limpar, revisar, provar, publicar — é o mesmo que se usa sem agente nenhum.

O que o agente muda é a velocidade de cada passo, não a existência deles. Quem trata a ferramenta como atalho para pular etapa descobre isso em produção.

---

Este texto reflete a versão que eu uso hoje, em agosto de 2026. Antes de copiar qualquer comando daqui, rode /help e confira o que está ativo na sua instalação.