Claude Code CLI: 7 dicas de produtividade e automacao na pratica

O teste falhou pela 18a vez na janela do terminal. Se eu tivesse conhecido o comando /clear antes, nao teria precisado chegar ate esse ponto.

Dados oficiais mostram que o Claude Code consegue resolver autonomamente 80,9% dos problemas de codigo no SWE-bench. Mas a pergunta e: voce esta usando de verdade as capacidades centrais dele? Muita gente abre o Claude Code, roda o comando claude, conversa um pouco, altera algum codigo e encerra. De mais de 50 comandos, usa apenas 3 a 5, desperdicando 90% do potencial de eficiencia.

Este artigo compartilha 7 dicas de CLI e 3 casos praticos de automacao, organizados por contexto: dos comandos basicos a gestao de contexto, passando por configuracao de Hooks e integracao CI/CD. Ao final, voce sai do nivel “sei usar” para “uso de forma realmente eficiente”.

Capitulo 1: o trio basico da CLI — inicializacao, modos e comandos

Primeiro, firme a base. As tecnicas avancadas so fazem sentido depois disso.

1.1 Tres formas de iniciar, cada uma com seu uso

claude              # inicia a interface interativa no diretorio atual
claude -c           # continua a conversa mais recente
claude --print "verifique a definicao de tipo desta funcao"  # faz uma consulta unica e sai

Muita gente so conhece a primeira forma. Na pratica, a segunda, -c, e especialmente util: quando voce acabou de fechar uma sessao e percebe que ainda ha um problema pendente, claude -c retoma o contexto anterior sem precisar explicar o projeto desde o inicio.

A terceira, --print, eu uso para consultas rapidas. Por exemplo, quando quero confirmar se a definicao de um tipo esta correta, resolvo com um unico comando, sem entrar no modo interativo completo. Economiza tempo.

1.2 Tres modos de trabalho para alternar conforme o contexto

Este e um conceito central da documentacao oficial, e aquele artigo aprofundado da Alibaba Cloud tambem fala dele:

No modo Default, cada modificacao de arquivo e cada comando executado precisam de confirmacao manual. E mais trabalhoso, mas seguro. Combina com momentos em que voce esta fazendo reconhecimento em um projeto desconhecido.

No modo Auto-Accept, modificacoes em arquivos sao executadas automaticamente, enquanto comandos shell ainda precisam de confirmacao. Quando voce faz uma refatoracao em lote no proprio projeto, esse modo deixa o Claude alterar tudo de uma vez, e voce revisa no final. A eficiencia dobra.

Eu gosto de usar o modo Plan para analisar problemas complexos. Deixo o Claude ler o projeto inteiro e produzir um plano de execucao detalhado. Nesse momento, nada e modificado; e apenas planejamento. Se o plano parecer confiavel, ai sim alterno para Auto-Accept e executo.

1.3 Tres comandos de barra que voce precisa lembrar

A documentacao oficial tem mais de 50 comandos, mas a maioria das pessoas usa menos de 10%. Estes tres sao os que eu mais uso:

/init     # escaneia o projeto e gera o arquivo de configuracao CLAUDE.md
/clear    # limpa o historico da conversa
/compact  # comprime o contexto para economizar tokens

Use /init na primeira vez que abrir um projeto novo. O Claude escaneia toda a base de codigo e gera um arquivo de configuracao com a estrutura do projeto, dependencias e convencoes. Depois, todas as operacoes passam a se apoiar nessa configuracao.

Vou falar especificamente sobre /clear mais adiante, porque foi o maior ganho de eficiencia que encontrei.

Use /compact quando o contexto acumular historico demais. O Claude preserva informacoes importantes, remove o que e redundante e economiza tokens. Funciona bem quando voce fez muitas rodadas de alteracoes na mesma sessao.

Capitulo 2: a arte de gerenciar contexto — limpar, comprimir e paralelizar

Esta parte veio de uma intuicao que tirei daquele artigo pratico da Builder.io: eles diziam que /clear e “o maior ganho de produtividade”. Testei por uma semana e confirmei.

2.1 O jeito certo de usar /clear

Quando limpar a conversa?

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Ao trocar de tarefa.

Imagine que voce acabou de corrigir um bug, conversou vinte rodadas com o Claude e localizou o problema. De repente, seu chefe pede para voce cuidar de outra issue urgente. Muita gente faz assim: continua na mesma conversa e muda de assunto.

Errado.

Nesse momento, voce deve rodar /clear primeiro e apagar todo o historico da conversa anterior. Por que? Porque essas mensagens antigas ocupam tokens e nao tem relacao nenhuma com a nova tarefa. O Claude fica “contaminado” pelo contexto antigo, e a qualidade de entendimento do novo problema cai.

Meu habito: quando mudo de uma tarefa para outra, primeiro uso /clear, depois explico brevemente o contexto da nova tarefa. O resultado e muito melhor do que continuar na conversa antiga.

2.2 Quando usar /compact

Quando voce faz muitas rodadas de alteracao dentro da mesma tarefa, muda uma dezena de arquivos e conversa mais de trinta mensagens, o contexto ja esta longo.

/compact comprime esse historico, preservando informacoes importantes, como arquivos modificados e decisoes principais, e removendo dialogo redundante.

Quando acionar? Criei uma regra simples para mim: se a conversa passar de 30 mensagens, faco um compact. Nao precisa ser exato; quando voce sentir que “esta ficando longo”, comprima.

2.3 Estrategia de sessoes paralelas

Esta tecnica vem do Help Center oficial do Claude: rode 3 a 5 sessoes ao mesmo tempo, cada uma em um git worktree diferente, cuidando de partes diferentes da base de codigo.

O que e git worktree? Em termos simples, e criar varios diretorios de trabalho para o mesmo repositorio, cada um podendo apontar para uma branch diferente.

# cria worktrees
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# inicia o Claude em worktrees diferentes
cd ../feature-A && claude
cd ../feature-B && claude

Assim, voce pode trabalhar em duas janelas de terminal ao mesmo tempo: uma pede para o Claude escrever o codigo da feature-A, e a outra pede para ele tratar a feature-B. As duas sessoes nao interferem uma na outra; cada contexto fica independente.

Ha tambem uma dica pratica de terminal: pressionar Ctrl+B move um comando bash de longa duracao para segundo plano. E util quando o Claude esta executando algo demorado, como npm install ou uma bateria longa de testes, e voce nao quer que a interface da conversa fique bloqueada.

Capitulo 3: as tres pecas da automacao — Hooks, Routines e CI/CD

As dicas anteriores eram manuais. A partir daqui entramos em automacao: deixar o Claude fazer parte do trabalho repetitivo enquanto voce segue tocando a tarefa.

3.1 Mecanismo de Hooks: gatilhos de tarefa

Hooks sao o nucleo de automacao do Claude Code. Existem tres tipos principais:

O mais pratico e o PostToolUse. Voce configura um hook para rodar uma bateria de testes toda vez que o Claude terminar de alterar codigo.

// exemplo de configuracao em settings.json
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

O efeito dessa configuracao: sempre que o Claude modificar um arquivo com a ferramenta Write, npm test roda automaticamente. Se o teste falhar, o Claude ve a saida e corrige o problema por conta propria.

3.2 Routines: definir fluxos repetitivos

Routines servem para definir fluxos de tarefa que se repetem.

O exemplo da documentacao oficial e este: quando o Claude detecta certa condicao, como a existencia de um arquivo, ele executa automaticamente uma serie de comandos predefinidos.

A configuracao concreta e um pouco complexa, e eu ainda nao usei em grande escala em producao. Mas a direcao vale a exploracao: transformar “aquelas verificacoes que sempre precisam ser feitas” em algo fixo, sem precisar lembrar o Claude manualmente toda vez.

3.3 Integracao CI/CD: pratica com GitHub Actions

Este e o modo headless fornecido oficialmente: claude -p.

No GitHub Actions, ele permite que o Claude trate automaticamente PR review, implementacao de issues e auditoria de seguranca.

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Aquele blog oficial da GitLab descreveu tres fluxos de trabalho:

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

1. criar um MR a partir de uma issue
2. analisar regressao de desempenho
3. implementar diretamente uma funcionalidade e deixar o CI validar

Ainda estou estudando essa direcao, mas o potencial ja e visivel: incorporar o Claude Code ao fluxo inteiro de desenvolvimento e torna-lo parte do seu pipeline de CI/CD.

Capitulo 4: casos praticos — da configuracao a automacao

Falamos dos principios. Agora vamos ver como isso funciona na pratica.

Caso 1: resolver um git commit com uma frase

Este e o cenario que mais uso.

O jeito tradicional: git add, git status, escrever a commit message, git commit. Tudo isso leva alguns minutos.

Com Claude Code:

claude
> commit these changes

Uma frase. O Claude le automaticamente suas alteracoes atuais, gera uma commit message adequada e faz o commit. Ele analisa o conteudo modificado, entende a intencao central da mudanca e escreve uma mensagem com significado.

Nos meus testes, a qualidade da message gerada foi melhor que a minha, porque ele realmente leu o diff em vez de escrever algo generico.

Caso 2: PostToolUse Hook rodando testes automaticamente

Voltando a configuracao de hook de antes, aqui esta a versao completa que uso:

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" indica que apenas a ferramenta Write, usada para modificar arquivos, sera monitorada. npm run test:related e um comando que defini para rodar somente testes relacionados aos arquivos alterados, nao a suite inteira. E muito mais rapido.

Resultado: cada vez que o Claude termina de alterar codigo, em ate 30 segundos eu vejo o resultado dos testes. Se falhar, o Claude recebe a saida e corrige automaticamente.

Eu ja cai em uma armadilha: no inicio configurei a suite completa com npm test, que era lenta demais e vivia estourando timeout. Ao mudar para testes relacionados, o problema desapareceu.

Caso 3: PR Review automatico no GitHub Actions

Esta configuracao vem da documentacao oficial:

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Esse workflow dispara quando um PR e criado ou atualizado. Ele pede ao Claude para revisar o codigo automaticamente e comentar no PR. O Claude consegue verificar qualidade de codigo, bugs potenciais, vulnerabilidades de seguranca e problemas de desempenho.

Usei por um mes e percebi que ele encontrou mais bugs do que minhas revisoes manuais, porque ele nao relaxa: olha cada arquivo com atencao.

Capitulo 5: dicas para multiplicar produtividade — simplificar configuracao e integrar ferramentas

As ultimas dicas eu aprendi em artigos da Marmelab e da Builder.io. Elas tratam de como deixar o fluxo inteiro mais fluido.

5.1 A filosofia de manter o CLAUDE.md curto

Muita gente escreve arquivos CLAUDE.md extremamente detalhados: contexto do projeto, stack tecnica, convencoes de estilo, proibicoes, e por ai vai. Sao milhares de palavras.

A recomendacao da Marmelab vai na direcao oposta: mantenha o CLAUDE.md o mais curto possivel.

Por que? Porque quanto mais longa a configuracao, mais facil o Claude “seguir demais” as regras. Ele consulta a configuracao a cada operacao, e isso acaba limitando a flexibilidade. Alem disso, uma configuracao longa tambem consome tokens.

A forma recomendada e escrever apenas 3 a 5 convencoes centrais, tratando a configuracao como uma “funcao obrigatoria que simplifica a base de codigo”. Por exemplo:

# CLAUDE.md
- Modo estrito de TypeScript; todas as variaveis precisam ter tipo
- Arquivos de componentes ficam em src/components/
- Arquivos de teste ficam no mesmo diretorio dos arquivos-fonte
- Nao use var; use apenas const e let

So isso. Ja basta.

5.2 Estrategia de Bash Wrapper

Um ponto daquele artigo da Builder.io ficou marcado para mim: nao escreva documentacao longa; escreva scripts bash wrapper.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Por exemplo, se voce quer ajudar membros da equipe a iniciar o projeto rapidamente, em vez de escrever um README complexo dizendo “primeiro rode npm install, depois configure variaveis de ambiente, depois inicie o dev server”, escreva um script:

#!/bin/bash
# dev.sh - inicia rapidamente o ambiente de desenvolvimento

npm install
source .env.local
npm run dev

Depois, dentro do Claude Code, basta dizer “run dev.sh”. Simples, sem exigir esforco mental.

Essa logica tambem se aplica ao proprio Claude: encapsule combinacoes frequentes de comandos em aliases ou scripts. Assim, voce nao precisa digitar uma sequencia longa toda vez.

5.3 Integracao com MCP Server: verificacao de seguranca e filtragem de saida

Por fim, ferramentas ligadas ao MCP (Model Context Protocol).

Dois exemplos praticos:

Snyk MCP Server: permite que o Claude verifique automaticamente vulnerabilidades de seguranca e problemas de dependencia enquanto escreve codigo. Voce nao precisa lembra-lo manualmente; sempre que uma nova dependencia entra, ele roda uma varredura de seguranca.

ferramenta rtk: filtra e comprime a saida de comandos. Ha uma tecnica especifica mencionada no GitHub sobre isso: muitos comandos CLI geram saidas muito longas, como logs de npm install, e isso consome muitos tokens. O rtk pode comprimir essas saidas e manter apenas as informacoes essenciais.

Ainda nao integrei totalmente essas duas ferramentas, mas a direcao e clara: fazer o Claude Code nao apenas escrever codigo, e sim se conectar a toda a cadeia de verificacao de seguranca e gestao de dependencias.

Resumo

Depois de tudo isso, os pontos centrais sao poucos:

Domine os comandos basicos: tres formas de iniciar e tres modos de trabalho, alternando conforme o contexto. Nao use apenas a forma mais simples.

Nao negligencie a gestao de contexto: ao trocar de tarefa, use /clear; quando a conversa ficar longa, use /compact. Esses dois habitos economizam muitos tokens.

Automacao vale o investimento: Hooks e integracao com GitHub Actions exigem algum tempo de aprendizado no inicio, mas o tempo economizado depois volta multiplicado.

Mantenha a configuracao simples: escreva um CLAUDE.md curto e encapsule fluxos complexos em scripts. Documentacao maior nao e necessariamente melhor.

Minha sugestao:

1. Teste hoje mesmo: digite /clear na conversa atual e sinta como e trabalhar com um contexto limpo
2. Tarefa desta semana: configure um hook PostToolUse para fazer o Claude rodar testes automaticamente sempre que alterar codigo
3. Meta de longo prazo: incorpore o Claude Code ao seu fluxo de CI/CD e transforme-o em uma ferramenta padrao da equipe

Se voce quiser se aprofundar na otimizacao de configuracao do Claude Code, leia o primeiro artigo da nossa serie, “Pare de deixar o Claude escrever codigo sem rumo: um arquivo de configuracao que aumenta a precisao da IA em 10%” (sobre como escrever o CLAUDE.md). Para entender o mecanismo de Subagent, veja o segundo artigo, “Claude responde de forma prolixa? Use Subagent para criar sua propria equipe de IA”. Este e o setimo artigo da serie, focado em tecnicas de CLI.

Aprendi todas essas tecnicas depois de tropeçar bastante. Espero que, depois de ler, voce tropece menos e consiga elevar sua eficiencia mais cedo.