Claude Code no seu fluxo de desenvolvimento diário

O salto do "uso pessoal" para "parte do pipeline"

A maioria dos desenvolvedores descobre o Claude Code escrevendo código num fim de semana, fica impressionada, e volta pro trabalho na segunda-feira usando ele como um chat sofisticado — abre o terminal, cola um erro, recebe uma solução. Útil, mas passageiro. O problema é que esse modo de uso não escala: não persiste entre sessões, não compartilha com o time, não se integra à infraestrutura que já existe.

O salto qualitativo acontece quando o Claude Code deixa de ser um "assistente que eu chamo" e vira "parte do fluxo que já roda sozinho". É a diferença entre usar um martelo e ter uma oficina montada. Este artigo mostra os três eixos em que essa integração acontece — git, hooks e MCP — e como começar sem quebrar o que já funciona.

Se você ainda está no modo "chat sofisticado", volte ao guia definitivo do Claude Code para o panorama completo antes. O texto abaixo assume que você já domina slash commands, skills e o básico do CLI.

CLAUDE.md: a base que torna o resto possível

Antes de falar de integração, uma confissão: a peça que mais aumenta a qualidade do Claude Code não é nenhuma feature exótica. É o arquivo CLAUDE.md no raiz do projeto.

O Claude Code lê esse arquivo toda vez que abre uma sessão naquele diretório. Ele é a forma canônica de contar ao agente coisas que ele não conseguiria inferir do código: comandos para rodar/testar/deployar, convenções do time, nome do produto, decisões arquiteturais, o que evitar.

Um CLAUDE.md bom tem quatro seções, nessa ordem:

1. Status atual — em que fase está o projeto, o que está vivo, o que é legado.
2. Commands — os comandos exatos que o agente deve usar (npm run build, npm run deploy). Escrever aqui evita que ele invente comandos errados.
3. Architecture & Conventions — stack, estrutura de pastas, nomenclatura, padrões de código.
4. Constraints — restrições do ambiente (ex: "static export, sem middleware", "Cloudflare free tier, sem Workers").

Escrever 100 linhas de CLAUDE.md paga-se no primeiro dia. Sem isso, as próximas integrações são construídas em cima de areia — o agente vai adivinhar detalhes e errar. A disciplina mais alta para ergonomia pessoal via slash commands e skills pressupõe um CLAUDE.md honesto como ponto de partida.

Eixo 1: Git

Git é a integração mais imediata e a que mais impacta o dia a dia. O Claude Code já sabe rodar git status, git diff, git log, git commit, git push e abrir PRs via gh. O que você precisa é só dar convenções claras para ele não inventar mensagens aleatórias.

Um fluxo padrão que funciona: um slash command /commit que lê o diff, analisa as mudanças, escolhe o tipo (feat, fix, refactor, chore) e escreve uma mensagem de 1-2 linhas no formato conventional commits. Outro /pr que compara com a branch base, redige título, descrição e plano de teste, e abre via gh pr create.

Para a primeira vez que você automatiza commits e PRs — incluindo como lidar com pre-commit hooks, assinatura de commit, e a diferença entre criar commit novo e usar --amend — leia Git + Claude Code: automatizando commits e PRs. É o artigo que mais economiza cliques por dia na vida prática.

Eixo 2: Hooks

Hooks são shell commands executados automaticamente pelo harness em momentos pré-definidos: antes/depois de cada Edit, antes de Bash, ao iniciar uma sessão, quando um subagent termina, ao submeter um prompt. Eles são configurados em .claude/settings.json e rodam sem intervenção.

Três casos que pagam muito rápido:

• Format-on-edit. Depois de qualquer Edit ou Write, rode biome format <file> ou prettier -w <file>. O código sai já formatado; o agente não gasta tokens discutindo estilo.
• Lint gate. Depois de Edit, rode npm run lint -- <file>. Se falhar, o hook devolve a mensagem de erro ao agente, que tenta arrumar sozinho antes de você ver.
• Audit log. Registrar toda chamada Bash num arquivo .claude/audit.log. Barato de implementar, valioso quando algo dá errado e você precisa reconstruir o que aconteceu.

Hooks são do projeto ou do usuário — no projeto eles viajam com o repo e são compartilhados; no usuário eles aplicam a todo projeto. A explicação completa de cada evento disponível, com exemplos prontos de settings.json e armadilhas de permissão, está em Hooks do Claude Code: automação de eventos.

Eixo 3: MCP servers

Se hooks são automação interna, MCP servers são a porta pro mundo externo. Um Model Context Protocol server expõe ferramentas por um protocolo padronizado — o Claude Code se conecta e ganha ações novas sem que você precise escrever código no CLI.

Os casos que mais aparecem:

• Issue trackers — Linear, Jira, GitHub Issues. O agente lê e cria issues direto do terminal.
• Bancos de dados — um MCP Postgres deixa o agente consultar schemas reais antes de escrever migrations. Evita 100% dos "campo não existe" que vêm de alucinação.
• Mensageria — Slack, Telegram, Discord. Você avisa o canal do time quando o deploy sobe, sem sair da conversa.
• Calendário e docs — Google Calendar, Google Drive, Notion. Contexto organizacional que não existe no repo.

O ponto crítico de MCP é autorização. Todo MCP que conecta a um serviço externo é, por definição, um vetor de risco. Ler do Linear é seguro; criar issue em produção é outro nível de autorização. Os trade-offs completos, como escolher MCPs confiáveis e como restringir escopos, estão em MCP Servers: conectando ferramentas externas ao Claude Code.

O quarto eixo: CI/CD

Tudo que foi mostrado até agora assume uso interativo — você no terminal, olhando. O Claude Code também roda em modo headless dentro de CI: um workflow do GitHub Actions pode disparar um agente para revisar um PR, rodar testes, corrigir typos, gerar release notes, tudo automaticamente e sem humano no loop.

Aqui as regras mudam. Você não pode contar com aprovação interativa — precisa usar --allowedTools restrito, --permission-mode plan para tarefas arriscadas, e hooks que abortem se algo sair do script. Montar esse pipeline com segurança tem armadilhas específicas (secrets, rate limits, timeout, custo por run) que cobri em Claude Code em pipelines CI/CD.

Como começar sem explodir nada

A ordem importa. Quem tenta ligar tudo de uma vez quebra algo e culpa o Claude Code. A progressão segura:

1. Escreva o CLAUDE.md — 50-100 linhas, real, versionado no repo. Hoje.
2. Crie 2-3 slash commands — comece por /commit e /review, use por uma semana.
3. Ligue 1 hook — só format-on-edit, o mais inócuo. Se isso funcionar sem estranhezas, você entendeu o modelo mental.
4. Conecte 1 MCP server — o que você mais usa fora do editor, com leitura somente no começo.
5. Só então pense em CI — quando o uso interativo já está estável e você tem skills + hooks do time maduros.

Próximos passos

Este artigo fecha os três galhos principais da série — você já tem o mapa dos sete pilares do Claude Code, sabe personalizar o fluxo com slash commands e skills e conhece o modelo de integração. O próximo passo depende da sua prioridade: se quer economizar cliques hoje, comece pelo eixo de git. Se quer automação que roda sozinha, siga para hooks. Se o objetivo é conectar o Claude Code ao resto do seu ferramental, vá para MCP servers. E quando o time inteiro estiver adotando, amarre tudo em pipelines CI/CD.