🏗️ Modo Building: Filesystem + GitHub
🎯 Configuracao Para Construir Features
Quando voce esta construindo features novas, a prioridade e maximo contexto para codigo. Mantenha apenas Filesystem (acesso cross-repo) e GitHub (para ler issues com requisitos). Desconecte Browser e Database - voce nao precisa de web ou dados ao vivo para codar.
- • MCPs ativos: Filesystem (~500) + GitHub (~2.000) = ~2.500 tokens overhead
- • Contexto livre: ~197.500 tokens disponiveis para codigo e instrucoes
- • Workflow: Leia issue → Implemente → Crie PR → Linke issue
- • Otimizacao: Desconecte GitHub apos ler a issue se a sessao sera longa
📊 Por Que Este Setup
- Building precisa de maximo espaco para codigo e instrucoes complexas
- GitHub so e necessario para buscar requirements (issues) e criar PRs
- Browser e Database sao irrelevantes para construir codigo puro
💡 Dica Pratica
Workflow otimizado: 1) Conecte GitHub. 2) 'Leia issue #42 e resuma os requisitos'. 3) Desconecte GitHub (mcp remove github). 4) Code com apenas Filesystem. 5) Reconecte GitHub. 6) 'Crie PR com essas mudancas linkando issue #42'. 7) Desconecte. Overhead medio: muito menor que manter GitHub ligado o tempo todo.
✓ O que FAZER
- ✓ Manter overhead abaixo de 3.000 tokens para building
- ✓ Desconectar GitHub entre ler issue e criar PR
- ✓ Maximizar contexto para codigo
✗ O que NAO fazer
- ✗ Manter Browser ligado durante coding
- ✗ Manter Database ligado sem necessidade
- ✗ Conectar MCPs 'por precaucao'
🎨 Modo UI/Design: Filesystem + Browser
🎯 Configuracao Para Trabalho Visual
Quando trabalhando em UI, o Claude precisa VER o resultado. Browser MCP e essencial aqui mas e o mais caro. Aceite o overhead alto (~5.500 tokens) porque a verificacao visual e insubstituivel para UI.
- • MCPs ativos: Filesystem (~500) + Browser (~5.000) = ~5.500 tokens overhead
- • Contexto livre: ~194.500 tokens - menos, mas suficiente
- • Workflow: Code → Screenshot → Ajuste → Screenshot → Approve
- • Cuidado: Cada screenshot consome 5.000-15.000 tokens extras!
📊 O Trade-off Necessario
- UI sem verificacao visual e coding as cegas
- O overhead alto do Browser e justificavel aqui (unico caso de uso)
- Minimize screenshots: peca get_text quando nao precisa VER visualmente
💡 Dica Pratica
Para UI, use um fluxo de verificacao eficiente: 1) Code o componente. 2) 'Navegue para localhost:3000/pagina e tire screenshot'. 3) 'Ajuste o padding do header e o tamanho da fonte'. 4) 'Tire screenshot novamente para confirmar'. Limite a 2-3 screenshots por ciclo. Mais que isso e desperdicar tokens.
✓ O que FAZER
- ✓ Aceitar o overhead alto do Browser para tarefas UI
- ✓ Limitar screenshots a 2-3 por ciclo de ajuste
- ✓ Usar get_text para verificacoes nao-visuais
✗ O que NAO fazer
- ✗ Pedir screenshots a cada mudanca minima
- ✗ Manter Browser ligado apos fase de UI
- ✗ Fazer mais de 3-4 ciclos screenshot sem pausa
⚙️ Modo Backend/Data: Filesystem + Database
🎯 Configuracao Para Backend e Dados
Quando trabalhando com backend e dados, conecte Database MCP para acesso direto ao banco. O Claude pode explorar schemas, validar queries e debugar problemas de dados em tempo real.
- • MCPs ativos: Filesystem (~500) + Database (~1.500) = ~2.000 tokens overhead
- • Contexto livre: ~198.000 tokens - excelente para codigo backend
- • Workflow: Explore schema → Escreva query → Valide → Implemente no codigo
- • Cuidado: Use LIMIT em queries! Dados retornados consomem tokens extras
📊 Backend Com Dados Reais
- Claude escreve SQL baseado no schema REAL, nao em suposicoes
- Debug de dados ao vivo: veja os problemas acontecendo
- Migrations mais precisas: baseadas no estado atual do banco
💡 Dica Pratica
Comece toda sessao de backend com: 'liste todas as tabelas do banco e descreva as que vou trabalhar hoje: [tabela1, tabela2]'. Isso da ao Claude contexto do schema real com custo minimo. A partir dai, queries e migrations serao muito mais precisas.
✓ O que FAZER
- ✓ Comecar com exploracao de schema
- ✓ Usar LIMIT em toda query
- ✓ Desconectar Database quando terminar com dados
✗ O que NAO fazer
- ✗ SELECT * sem LIMIT em tabelas grandes
- ✗ Conectar Database durante coding de frontend
- ✗ Executar DDL sem revisar cuidadosamente
🕷️ Modo Lead Scraping: Browser + Sheets
🎯 Configuracao Para Coleta de Dados
Para lead scraping e coleta de dados da web, combine Browser (navegar e extrair) com Google Sheets (armazenar resultados). E o setup mais caro mas com alto valor de output para equipes de vendas e marketing.
- • MCPs ativos: Filesystem (~500) + Browser (~5.000) + Sheets (~800) = ~6.300 tokens overhead
- • Contexto livre: ~193.700 tokens - apertado mas funcional
- • Workflow: Navegue diretorio → Extraia dados → Salve na planilha → Repita
- • Nota: Este e o setup mais pesado - use apenas quando necessario
📊 Alto Custo, Alto Valor
- 6.300 tokens de overhead e alto, mas o output justifica
- Automatizar coleta de 50 leads pode economizar 4-8 horas de trabalho manual
- O custo em tokens e insignificante comparado ao valor dos dados coletados
💡 Dica Pratica
Para maximizar eficiencia no modo scraping, processe em batches: 'navegue para pagina 1 do diretorio, extraia os 10 primeiros resultados, salve na planilha'. Depois repita para proximas paginas. Isso evita acumular muitos dados no contexto de uma vez e permite /compact entre batches se necessario.
✓ O que FAZER
- ✓ Processar dados em batches de 10-20
- ✓ Salvar na planilha apos cada batch
- ✓ Usar /compact entre batches se contexto alto
✗ O que NAO fazer
- ✗ Tentar extrair centenas de resultados de uma vez
- ✗ Manter dados no contexto sem salvar
- ✗ Esquecer de desconectar Browser + Sheets apos scraping
🔍 Modo Code Review: Filesystem + GitHub
🎯 Configuracao Para Review
Para code review, o setup e igual ao building: Filesystem + GitHub. O Claude le o PR remoto (GitHub MCP) e o codigo local (Filesystem) para gerar reviews contextualizados.
- • MCPs ativos: Filesystem (~500) + GitHub (~2.000) = ~2.500 tokens overhead
- • Workflow: Leia PR → Leia arquivos afetados → Gere review → Poste comments
- • Combinacao: Use Skill de review (/review) + GitHub MCP para reviews completos
- • Vantagem: Review com contexto do codigo local E do PR remoto
📊 Review Com Contexto Completo
- GitHub MCP: le o diff, comments e descricao do PR
- Filesystem: le os arquivos completos para contexto
- Skill de review: aplica checklist padrao da equipe
- Resultado: review mais completo que humano comum faria
💡 Dica Pratica
O workflow ideal: 1) 'Leia o PR #15 e seus comments'. 2) 'Leia os arquivos modificados no meu projeto local'. 3) 'Execute /review com foco em seguranca e performance'. 4) 'Gere comments formatados para postar no PR'. A combinacao de MCP + Skill produz reviews de qualidade senior.
✓ O que FAZER
- ✓ Combinar GitHub MCP com Skill de review
- ✓ Ler arquivos locais para contexto completo
- ✓ Gerar comments formatados para o PR
✗ O que NAO fazer
- ✗ Fazer review so com diff do PR (sem contexto local)
- ✗ Postar comments sem revisar o que o Claude gerou
- ✗ Manter GitHub conectado apos o review
🧠 Mentalidade de Operador
🎯 Pense em Modos, Nao em MCPs
Operadores profissionais nao pensam 'quais MCPs eu tenho'. Pensam 'qual modo estou e quais MCPs esse modo precisa'. A fase de trabalho dita a configuracao, nao o contrario. Trocar de modo e trocar de MCPs em bloco.
- • Building: Filesystem + GitHub (~2.500 tokens)
- • UI/Design: Filesystem + Browser (~5.500 tokens)
- • Backend/Data: Filesystem + Database (~2.000 tokens)
- • Lead Scraping: Filesystem + Browser + Sheets (~6.300 tokens)
- • Code Review: Filesystem + GitHub (~2.500 tokens)
📊 A Mudanca de Mentalidade
- De: 'vou adicionar esse MCP' → Para: 'vou entrar em modo UI'
- De: 'quais MCPs tenho ligados?' → Para: 'qual fase do trabalho estou?'
- De: gerenciar MCPs individuais → Para: trocar entre configuracoes pre-definidas
💡 Dica Pratica
Crie aliases no shell para cada modo: alias modo-build='claude mcp remove browser; claude mcp remove postgres; claude mcp add github -- npx -y @anthropic/mcp-github'. alias modo-ui='claude mcp remove github; claude mcp remove postgres; claude mcp add browser -- npx -y @anthropic/mcp-puppeteer'. Trocar de modo vira um unico comando.
✓ O que FAZER
- ✓ Pensar em modos/fases de trabalho
- ✓ Criar aliases ou scripts para cada modo
- ✓ Trocar de modo quando mudar de fase
✗ O que NAO fazer
- ✗ Gerenciar MCPs individualmente sem estrategia
- ✗ Ficar no mesmo modo quando a fase de trabalho mudou
- ✗ Acumular MCPs sem relacao com a tarefa atual
📋 Resumo do Modulo
Proximo:
6.10 - Troubleshooting