Usando o Claude Code como ferramenta do dia a dia: Claude.md, Skills, Subagents, Plugins e MCP

 (arps18.github.io)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A produtividade do Claude Code depende muito mais de como você acumula e valida memória, comandos personalizados, sessões paralelas e configurações do projeto do que de prompts
  • CLAUDE.md deve ser mantido como uma infraestrutura acumulativa curta e focada em validação; adicionar uma regra após um erro pode reduzir a repetição do mesmo erro
  • .claude/ é um sistema hierárquico de configuração que reúne CLAUDE.md, rules, skills, commands, agents e configurações de MCP, aplicando escopos separados para projeto e global
  • Skills transformam tarefas repetitivas em especialização reutilizável, e subagents executam revisão, depuração e migração em contextos separados
  • Combinando Plugins, MCP, /goal, /rewind, /batch e até worktrees paralelos, o Claude Code se torna um agente de desenvolvimento configurado e operado

Tratando o Claude Code como um agente verificável

  • A diferença de produtividade no Claude Code vem menos de prompts simples e mais de como você acumula memória, comandos personalizados, sessões paralelas e configurações do projeto
  • O princípio central é permitir que o Claude verifique os próprios resultados, e Boris Cherny com a equipe da Anthropic consideram que só essa abordagem já melhora a qualidade em 2 a 3 vezes
  • O fluxo de trabalho ideal segue a ordem exploração → planejamento → implementação
    • O modo de planejamento, acessado com Shift+Tab duas vezes, é adequado para exploração somente leitura
    • Recomenda-se ler os arquivos, entender o fluxo e o modelo de dados, depois montar o plano e executá-lo
    • Para trabalhos que mexem em vários arquivos, o modo de planejamento é útil; para mudanças pequenas, pode ser omitido
  • O modo de planejamento pode ser tratado como um documento de design revisável antes da implementação
    • Um Claude pode escrever o plano, e um segundo Claude em uma nova sessão pode revisá-lo como um staff engineer sem viés
    • Se a implementação sair do rumo, o ideal é voltar ao modo de planejamento e refazer o plano incluindo a etapa de validação
    • Com Ctrl+G, é possível abrir o plano do Claude no editor e editá-lo manualmente antes da implementação
  • Referências precisas funcionam melhor do que instruções ambíguas
    • Em vez de “veja o módulo auth”, indique o arquivo diretamente, como @src/auth/login.py
    • Em vez de colar erros, envie por pipe, como em cat error.log | claude
  • Cat Wu considera que o Claude Code funciona melhor quando é tratado como um engenheiro delegado do que como um programador em par instruído linha por linha
  • Quando o Claude cometer um erro, é possível acrescentar “Update CLAUDE.md so you do not repeat this.” ao fim do prompt para deixar uma regra que evite o mesmo erro

Diretório .claude e hierarquia de configuração

  • .claude/ não é apenas uma pasta para CLAUDE.md, mas um sistema hierárquico de configuração
  • As configurações se dividem em dois escopos
    • Escopo de projeto: fica em .claude/ dentro do repositório e é commitado no git para compartilhamento com a equipe
    • Escopo global: fica em ~/.claude/ e se aplica a todos os projetos da máquina local
  • Os arquivos do projeto podem ser entendidos como uma descrição do projeto, enquanto os arquivos globais descrevem as preferências e a forma de trabalhar do usuário
  • Função dos principais arquivos
    • CLAUDE.md: pode existir tanto no escopo de projeto quanto no global e traz instruções carregadas em toda sessão
    • CLAUDE.local.md: notas pessoais específicas do projeto, ignoradas pelo git
    • settings.json: permissões, hooks, variáveis de ambiente e configuração do modelo padrão
    • settings.local.json: sobrescritas pessoais, automaticamente ignoradas pelo git
    • .mcp.json: configuração de servidores MCP compartilhada pela equipe no projeto
    • skills/<name>/SKILL.md: prompt reutilizável chamado com /name
    • commands/*.md: comando slash de arquivo único
    • agents/*.md: definição de subagentes
    • rules/*.md: instruções por tema, com possibilidade de aplicação por caminho
  • CLAUDE.md é carregado em cascata
    • Em um monorepo, root/CLAUDE.md e root/services/billing/CLAUDE.md podem ser carregados juntos
    • Isso se encaixa bem em codebases com convenções diferentes por pasta
  • .claude/rules/*.md é adequado para instruções por caminho
    • Regras necessárias só para a pasta de migrações devem ficar em algo como .claude/rules/migrations.md com glob, em vez de inflar o CLAUDE.md da sessão inteira
  • Para novos trabalhos, skills são recomendadas no lugar de commands
    • Tanto .claude/commands/*.md quanto .claude/skills/<name>/SKILL.md podem criar comandos slash
    • Skills oferecem suporte a arquivos auxiliares, disable-model-invocation, ferramentas permitidas e override de agentes
  • Com claude project purge ~/path/to/repo --dry-run, é possível verificar o estado local que o Claude mantém para um projeto específico

Mantendo o CLAUDE.md curto e focado em validação

  • Como CLAUDE.md é carregado no início de toda sessão, se ele for mal escrito o Claude repetirá os mesmos erros; se for bem escrito, o resultado do mesmo prompt pode melhorar bastante
  • O princípio mais importante é mantê-lo curto
    • Recomenda-se perguntar em cada linha: “Se eu remover esta linha, o Claude cometerá um erro?”; se não, apague
  • Pedir que o próprio Claude escreva suas regras gera efeito cumulativo
    • Quando o Claude errar, instruí-lo com “Update CLAUDE.md so you do not repeat this.” permite que ele resuma o erro em uma regra precisa
    • Se isso for repetido por algumas semanas, as armadilhas do projeto se acumulam como uma lista de regras
  • O CLAUDE.md real da equipe do Claude Code foca em comandos de build e ordem de validação
    • Usa bun e não npm
    • Especifica a sequência de typecheck rápido, testes após mudanças, lint antes do commit e validação completa antes do PR
    • Não inclui preferências de estilo, tour pela codebase nem generalidades
  • Também é possível usar @claude em comentários de PR para adicionar regras diretamente
    • Exemplo: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • O review de PR passa a alimentar melhorias no CLAUDE.md, criando um fluxo de “Compounding Engineering”
  • Um bom CLAUDE.md se concentra nas seguintes informações
    • Estilo de código: usar ES modules em vez de CommonJS
    • Fluxo de trabalho: executar bun run typecheck, não dar push direto na main
    • Arquitetura: rotas de API devem obrigatoriamente passar por determinado middleware
    • Gotchas: a diferença entre User e UserRecord, e o fato de que formatCurrency assume USD
  • O que não deve entrar no CLAUDE.md
    • Convenções padrão da linguagem
    • Explicações da codebase por arquivo
    • Tutoriais longos
    • Documentação de API
    • Conteúdo que muda com frequência
  • Expressões como IMPORTANT e YOU MUST podem aumentar a taxa de conformidade, mas devem ser usadas com moderação para preservar seu peso
  • Com a sintaxe @path, dá para importar outros arquivos e manter o CLAUDE.md enxuto, ligando-o a detalhes externos
    • Exemplo: See @README.md for project overview and @package.json for scripts.
    • Exemplo: @~/.claude/my-preferences.md

Acumulando feedback pessoal com CLAUDE.local.md

  • CLAUDE.local.md é carregado no mesmo local e da mesma forma que CLAUDE.md, mas não deve sair da máquina local e precisa ser incluído no .gitignore
  • Colocar imediatamente comentários de revisão de PR no CLAUDE.local.md permite acumular feedback pessoal recorrente em um arquivo de regras pessoais
  • Exemplos de regras
    • Novos consumers de SQS precisam de DLQ e alertas no mesmo PR
    • Preferir Optional<T> a retornar null
    • Testes de novos endpoints devem incluir casos de falha de autenticação
    • Ao adicionar um endpoint, a especificação OpenAPI também deve ser atualizada
  • É melhor separar no arquivo o feedback específico do projeto e os itens de correção de hábitos pessoais
  • Depois de algumas semanas, vale remover os itens que já viraram hábito e manter apenas o que ainda está em processo de aprendizado

Skills: unidades reutilizáveis de especialização

  • Skills são unidades reutilizáveis de especialização que transformam o Claude Code de um “agente que faz de tudo” em um agente que executa bem tarefas específicas de um projeto

  • Estrutura de uma Skill

    • uma skill é uma pasta em .claude/skills/<name>/ ou ~/.claude/skills/<name>/
    • o SKILL.md dentro da pasta contém o frontmatter e as instruções
    • o nome da pasta vira um comando com barra
    • por exemplo, se você criar ~/.claude/skills/summarize-changes/SKILL.md, /summarize-changes ficará disponível em todas as sessões

  • Por que Skills são poderosas

    • Divulgação progressiva: no início da sessão, só a descrição do frontmatter é carregada, e o SKILL.md completo junto com arquivos auxiliares só é carregado quando realmente necessário
    • Organização baseada em pastas: permite agrupar templates, documentos de referência, scripts e configurações
    • Shell inline: linhas que começam com ! executam comandos e injetam a saída no momento da chamada

  • Opções de frontmatter

    • description: explica quando essa skill deve ser usada
    • disable-model-invocation: true: faz com que ela só seja executada quando o usuário digitar explicitamente /my-skill
    • allowed-tools: restringe as ferramentas usadas, como Read, Grep e Bash
    • agent: pode executá-la em um modo de agente específico
    • para skills com efeitos colaterais, como deploy, disable-model-invocation: true é apropriado

  • Exemplo de skill para convenções de API em Go

    • uma skill para criar o scaffold de um novo HTTP handler em uma equipe de serviços Go pode reunir SKILL.md, templates/handler.go.tmpl e examples/healthz.go
    • exemplos de regras incluem convenções específicas do projeto, como preferência por Go 1.22, router chi, queries tipadas com sqlc, logging estruturado com zap, assertions com testify e testes table-driven
    • exemplos de pegadinhas incluem evitar erros recorrentes, como o fato de chi.URLParam retornar "" para parâmetros ausentes, httperr.Wrap não gerar logs e pgtype.Text exigir verificação de .Valid

  • Skills que valem a instalação

    • mattpocock/skills: repositório popular de skills com cerca de 100k stars
      • /grill-me: entrevista você sobre o plano antes de escrever código
      • /tdd: impõe rigorosamente o ciclo red-green-refactor
      • /diagnose: depura seguindo a ordem reprodução, minimização, hipótese, correção e teste de regressão
      • instalação: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: oferece 66 perfis por linguagem, como go-pro, python-pro, java-architect, typescript-pro, rust-engineer e sql-pro
    • Skills oficiais da Anthropic
      • /code-review: quatro agentes paralelos auditam o diff e reportam apenas achados com base em pontuação de confiança
      • /simplify: revisa código recente do ponto de vista de reutilização e eficiência
      • /batch: distribui migrações entre vários agentes paralelos, cada um trabalhando em seu próprio worktree
      • /webapp-testing: faz o Claude testar um app web local com Playwright
    • tarefas que você repete mais de uma vez por dia são boas candidatas para virar skill
    • ao fazer commit das skills no git, elas viram conhecimento organizacional da equipe, e novos engenheiros recebem imediatamente as práticas acumuladas assim que fazem clone do repositório

Subagents: trabalho focado em contexto separado

  • um subagent executa com sua própria janela de contexto e suas próprias permissões de ferramenta, depois retorna um resumo
  • o valor principal é que ele pode ler muitos arquivos sem lotar o contexto da sessão principal
  • um subagent é um arquivo markdown em .claude/agents/ ou ~/.claude/agents/, e no frontmatter declara name, description, tools e model

  • Configuração do agente /pr-review

    • ele pode ser definido para comparar o diff da branch atual com main e encontrar bugs, problemas de segurança, edge cases ausentes e violações das convenções do projeto
    • tools: Read, Grep, Glob, Bash concede permissões centradas em leitura
    • com model: opus, é possível usar um modelo mais forte para revisões de maior risco
    • o processo pode ser composto por git diff main...HEAD, git log main..HEAD --oneline, leitura de todos os arquivos e comparação com CLAUDE.md, CLAUDE.local.md e .claude/rules/
    • a saída pode ser agrupada em Critical / High / Medium / Low e incluir arquivo, linha, problema e correção sugerida, terminando com SHIP, FIX FIRST ou REWORK

  • Projeto para melhorar a relação sinal-ruído

    • se o reviewer modifica o código, surge um viés de defender a própria correção, então ferramentas somente de leitura são apropriadas
    • explicitar em uma seção “Do NOT flag” que não devem ser apontadas preferências de estilo sem base nas regras do projeto, sugestões de refatoração para código que já funciona e itens fora do diff reduz o ruído

  • Padrões comuns de subagent

    • a equipe do Claude Code faz check-in de build-validator, code-architect, code-simplifier, oncall-guide e verify-app
    • security-reviewer: verifica injection, auth, secrets e deserialização insegura
    • test-writer: gera testes e pode formar um loop com um code-reviewer
    • debugger: rastreia testes com falha até a causa raiz
    • performance-auditor: faz profiling de fluxos e queries
    • migration-writer: gera migrations de banco de dados de acordo com as convenções do projeto
    • release-notes-writer: escreve changelog a partir do histórico de commits
    • quando a Session A implementa e um subagent code-reviewer revisa em um contexto novo, o viés de implementação diminui
    • ao adicionar isolation: worktree ao frontmatter, o subagent pode rodar em um git worktree separado, o que é útil para distribuir migrações entre vários agentes paralelos

Plugins e Marketplace

  • Plugins agrupam skills, hooks, subagents e servidores MCP em uma única unidade instalável
  • É possível abrir o navegador do marketplace com /plugin
  • É possível adicionar um marketplace da comunidade com /plugin marketplace add owner/repo

  • Itens que valem instalar no início

    • /code-review: executa quatro agentes em paralelo; dois analisam se CLAUDE.md está sendo seguido, um procura bugs e outro analisa contexto com base em git blame
    • /feature-dev: transforma um feature brief em código funcional em 7 etapas: requirements → exploration → architecture → implementation → testing → review → docs
    • Plugin de language server: oferece navegação precisa por símbolos e diagnostics automáticos após edições, e é chamado pela equipe de plugin de maior impacto
    • /security-guidance: skill oficial de segurança da Anthropic, que expõe preocupações de segurança antes do ship
    • Em meados de 2026, havia mais de 1.000 plugins em mais de 75 marketplaces
    • As principais categorias de plugins são Git workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma) e observability (Sentry, Datadog)
    • Se você mantiver um .mcp.json compartilhado pela equipe junto com plugins selecionados, um novo engenheiro pode começar a trabalhar de forma produtiva poucos minutos depois de clonar o repositório

Comandos do Claude Code que mais impactam a produtividade

  • Muitos usuários aprendem apenas /clear, /compact e /init e param por aí, mas outros comandos também têm grande impacto na produtividade diária

  • Principais comandos

    • /insights: analisa padrões de uso e vale executar uma vez por mês
    • /compact <hint>: compacta a sessão, e a hint controla o que deve ser preservado
    • /copy: copia a última resposta e oferece um interactive picker para blocos de código
    • /rewind: funciona como undo de toda a sessão, restaurando código e conversa, ou ambos
    • /btw: pergunta lateral que não entra no histórico da conversa
    • /context: visualiza o uso de contexto
    • /export <file>: faz dump da conversa em um arquivo
    • /branch: faz fork da sessão para tentativas arriscadas
    • /batch: distribui trabalho por agentes paralelos em toda a worktree
    • /loop <interval>: executa o Claude repetidamente por até 3 dias
    • /schedule: versão em nuvem do /loop que continua funcionando mesmo com o laptop fechado
    • /teleport: move a sessão entre terminal e web
    • /focus: oculta chamadas intermediárias de ferramentas e mostra apenas o resultado final
    • /voice: entrada por voz
    • --bare: acelera em até 10 vezes a inicialização ao usar claude -p de forma não interativa

  • Diferença entre /compact e /clear

    • Para uma tarefa totalmente nova, o mais adequado é /clear com um brief escrito do zero
    • Se a tarefa for relacionada e ainda precisar de contexto, o mais adequado é /compact com hint
    • /compact é um resumo com perdas feito pelo LLM, enquanto /clear é um brief escrito diretamente pelo usuário, por isso a distinção é importante

  • Como usar /rewind

    • Se o Claude entrar no caminho errado, é melhor não continuar escrevendo algo como “isso não deu certo, então tente X”
    • Continuar dali polui o contexto, então o ideal é dar rewind e fazer novo prompt incorporando o que foi aprendido
    • É possível abrir o rewind pressionando Esc duas vezes
    • ! pode ser usado como shell escape
    • Comandos como !git status e !npm test são executados imediatamente e a saída entra no contexto
    • A configuração CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 serve para forçar a compactação mais cedo, antes que apareça context rot por volta de 300~400k tokens em modelos de 1M

  • Padrão fan-out

    • Primeiro, cria-se uma lista de tarefas e testa-se em três arquivos
    • Depois de ajustar o prompt, aplica-se em milhares de arquivos
    • Exemplo:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: loop iterativo com condição de conclusão embutida

  • /goal define uma condição de conclusão e, sempre que o Claude tentar parar, faz a verificação dessa condição com base no transcript
  • A condição deve ser verificável e determinística
    • comando de teste
    • código de saída de CLI
    • estado de arquivo
  • Exemplos:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Condições vagas como “o código está bom” não funcionam
  • Recursos que combinam bem com ele
    • /loop: repete em intervalos para reduzir o backlog
    • /schedule: executa periodicamente na nuvem
    • Hook Stop: define um gate com sua própria suíte de testes ou endpoint de CI
    • Modo auto: evita que goals longos parem por causa de prompts de permissão
  • A combinação /goal + modo auto + /focus busca um fluxo em que você define um brief claro e a condição de conclusão, sai, e quando volta o PR já está pronto

Usando MCP como ferramenta de percepção do sistema

  • MCP (Model Context Protocol) faz com que o Claude Code vá além de um agente de programação e se torne um agente capaz de perceber sistemas externos
  • Um servidor MCP expõe ao Claude ferramentas externas como banco de dados, ferramenta de design, rastreador de erros e notas de forma padronizada
  • Sem MCP, o Claude lê arquivos e executa comandos, mas com MCP ele pode lidar com ticket do Linear, consulta no Postgres, componente do Figma, stack trace do Sentry e vault do Obsidian sem sair do terminal

  • MCPs usados com frequência em engenharia

    • GitHub: gerenciamento de repositório, PRs, issues, busca de código
    • Context7: documentação atualizada de bibliotecas, adicione use context7 ao prompt
    • Sentry: contexto real de erros, stack traces, breadcrumbs
    • Linear: leitura e criação de tickets, atualização de status
    • Playwright: automação de navegador baseada em accessibility snapshot
    • Figma: árvore de design ao vivo, auto-layout, spacing tokens, referências de componentes
    • Postgres / Supabase: consulta direta ao banco de desenvolvimento
    • Slack: leitura de threads, resumo de discussões, rascunho de resposta
    • servidores locais usam stdio, e servidores hospedados pelo fornecedor usam HTTP com OAuth
    • Exemplo:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • MCPs compartilhados pela equipe ficam no .mcp.json da raiz do projeto, e MCPs pessoais ficam em ~/.claude.json
  • Se você instalar MCPs demais, a lista de ferramentas que o Claude precisa considerar cresce e a qualidade da tomada de decisão pode cair
  • Um bom conjunto inicial é GitHub, Context7 e um ou dois MCPs específicos do domínio
  • /mcp é o primeiro ponto de checagem para verificar servidores ativos e estado da conexão dentro do Claude Code

Obsidian e a estrutura de memória em 3 camadas do Claude Code

  • A combinação de Obsidian + Claude Code fica mais poderosa quando usada como uma arquitetura de memória em três camadas, e não apenas como “o Claude lendo o vault”

  • Configuração

    • Instale obsidian-claude-code-mcp no Obsidian
    • O plugin expõe o vault na porta 22360 de um WebSocket local
    • O Claude Code descobre isso automaticamente
    • Adicione CLAUDE.md ao vault para explicar a estrutura de pastas

  • Estrutura de pastas

    • 00-Inbox/: captura bruta
    • 10-Daily/: uma nota por dia
    • 20-Projects/: notas de projetos ativos
    • 20-Projects/billing-v2/README.md: objetivo, status, questões em aberto
    • 20-Projects/billing-v2/decisions/: ADRs
    • 20-Projects/billing-v2/sessions/: logs por sessão do Claude
    • 30-Decisions/: ADRs entre projetos
    • 40-Atoms/: conhecimento reutilizável e links
    • 90-Archive/: arquivo

  • Armazenamento quente

    • Cada sessão do Claude grava um log com timestamp em 10-Daily/<today>.md
    • Com um hook Stop, é possível fazer o agente adicionar um resumo estruturado ao encerrar

  • Armazenamento morno

    • Cada projeto tem uma pasta dentro de 20-Projects/
    • Antes de uma nova sessão, o Claude lê o README do projeto e os 2 ou 3 logs de sessão mais recentes para restaurar o contexto
    • O fluxo recompõe duas semanas de contexto em menos de 30 segundos

  • Armazenamento frio

    • Decisões de arquitetura são promovidas a ADRs em 30-Decisions/
    • Conhecimento reutilizável é refinado em 40-Atoms/ e conectado a vários projetos com wikilinks

  • Exemplo de fluxo diário

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Otimizando o fluxo diário de desenvolvimento

  • Nova feature

    • Comece no modo de planejamento
    • Edite o plano com Ctrl+G
    • Depois da implementação, chame o subagente /pr-review ou faça uma revisão em uma nova sessão do Claude

  • Bug

    • Primeiro, reproduza o problema
    • Envie o erro por pipe com cat error.log | claude
    • Peça ao Claude para escrever primeiro um teste que falhe e depois corrigir
    • O teste impede que a correção termine em puro chute

  • Migrações e mudanças em massa

    • /batch entrevista as mudanças e depois as distribui entre agentes em paralelo
    • Cada agente testa no próprio worktree e cria um PR

  • Código desconhecido

    • Use um subagente com algo como “Use a subagent to investigate how our auth handles token refresh.”
    • O subagente lê dezenas de arquivos no próprio contexto e retorna um resumo, mantendo a sessão principal limpa

  • Sessões paralelas

    • Boris e a equipe consideram rodar sessões do Claude em 3 a 5 git worktrees diferentes o maior salto de produtividade
    • A visualização de agentes em claude agents pode ser usada como um control plane

  • Padrão Writer/Reviewer

    • A Sessão A implementa
    • A Sessão B revisa com contexto novo
    • Depois, a revisão é trazida de volta, ajustada e o ciclo se repete

  • Compactar a cada milestone

    • Quando um bloco lógico termina, especifique o que deve ser preservado com algo como /compact Preserve the decisions made, files changed, and test commands.
    • Não se deve deixar o Claude afirmar sucesso sem evidências como testes, screenshots ou saída real de comandos
    • O intervalo entre confiar e depois verificar é apontado como a maior causa de resultados ruins

Padrões usados repetidamente na equipe da Anthropic

  • Se você permitir que o Claude verifique a própria saída, ele pode iterar até que o resultado melhore
  • Boris usa Opus e effort high ou xhigh na maioria das tarefas
    • o motivo é que modelos menores podem acabar sendo mais lentos no geral se exigirem mais correções
  • Executa de 3 a 5 sessões em paralelo
    • usa worktree em vez de checkout
    • é possível usar claude --worktree ou o app Desktop
    • a agent view agrupa as sessões paralelas
  • Mantém um diretório de notes para cada projeto e o atualiza após cada PR
    • se você fizer o CLAUDE.md apontar para esse diretório de notes, o conhecimento que o código tem sobre si mesmo vai se acumulando
  • É possível criar o comando slash /techdebt para encontrar e remover código duplicado ao fim de cada sessão
  • O CLAUDE.md da equipe é compartilhado e revisado várias vezes por semana
    • ele é tratado como um documento vivo, no qual quem vê algo que o Claude fez de errado adiciona uma regra
  • Para mudanças de UI, o Playwright MCP é adequado
    • o Claude pode abrir o navegador, clicar e verificar
  • O plugin de language server detecta erros de tipo e imports não usados após cada edição, e é apontado como o plugin de maior impacto
  • O /voice pode tornar o prompt mais detalhado
    • também é apresentado o motivo de que falar é 3 vezes mais rápido do que digitar
  • Editar no editor o plano do Claude com Ctrl+G antes da implementação é mais rápido do que digitar correções no chat
  • Boris pede ao Claude para desenhar diagramas ASCII quando está tentando entender protocolos e codebases desconhecidos

Materiais de referência

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • commands, skills, subagents, plugins estão espalhados demais e precisam ser organizados
    Por exemplo, só para revisão de código já existem cinco opções: .claude/commands/review.md, a skill /code-review, o subagent /pr-review, o plugin /code-review e simplesmente pedir ao Claude para revisar
    No fim, a maioria é só uma variação de inserir prompts prontos; o que muda é onde o prompt é instalado e em que contexto ele roda
    Também falta orientação sobre qual opção é a melhor, e ainda não existem boas práticas muito claras; pessoalmente, pedir diretamente ao Claude para fazer code review já funciona bem o bastante
    Além disso, o conselho de “instale um plugin de language server” não bateu com a minha experiência. Instalei LSPs de Rust, Python e Dart no Claude Code e no Codex, mas depois de centenas de sessões ao longo de dois meses, olhando os logs vi que só houve uma única chamada real de ferramenta LSP, enquanto Rust analyzer/Dart analysis server/Ty LSP só fizeram a RAM acabar com frequência
    No fim, removi os LSPs, e foi suficiente deixar o agente chamar diretamente ripgrep, cargo clippy, dart analyze, ty check e afins

    • Sou Boris, da equipe do CC, e concordo com isso; estamos trabalhando na unificação. No futuro, a ideia é ficar com uma única skill /code-review embutida
      Nas versões mais recentes, /code-review faz uma revisão equilibrada, /code-review --fix também aplica correções, e /code-review low|medium|high|xhigh|max permite escolher o nível de esforço
      /code-review ultra é um modo de revisão caro e extremamente minucioso, que custa algo em torno de US$ 3 a US$ 20 por revisão, dependendo da complexidade, e busca detectar com confiabilidade mais de 99% dos bugs
      Se alguém tiver ideias para tornar isso mais fácil de usar, gostaria muito de receber feedback
    • Já faz um tempo que penso que skills são uma abstração ruim. A definição do que elas devem ser é vaga, e isso ajudou na popularidade, mas justamente por isso parece ruim no longo prazo
      É estranho que diretrizes gerais como boas práticas de arquitetura frontend, procedimentos operacionais que só devem ser seguidos com precisão quando chamados explicitamente e explicações de como usar certas ferramentas sejam todos tratados como skill
      Entendo o apelo da flexibilidade num momento em que todo mundo ainda está aprendendo a usar ferramentas novas, mas skills estão cada vez mais parecendo “a gaveta de bagunças da cozinha onde você joga qualquer coisa quando não quer pensar em onde ela deveria ficar”
      Acho que uma separação melhor seria padronizar Agents como a personalidade ou perspectiva que o modelo deve adotar, Prompts como instruções repetíveis para tarefas específicas, e Tools como CLI/MCP/scripts junto com instruções de uso
    • A abordagem com subagent é estruturalmente diferente das outras opções. Isso porque ela roda em um contexto limpo
      Primeiro, como o custo de uma sessão de LLM cobra tokens de entrada e custo de entrada em cache a cada rodada, sob as mesmas condições isso pode reduzir o custo até chegar à solução
      Segundo, fica mais difícil para o modelo de revisão se enganar carregando as premissas da sessão principal, como “x deve ser feito como y”. É parecido com por que, para humanos, também é útil outra pessoa revisar ou revisar depois de limpar a cabeça
      Terceiro, o modelo principal vê apenas o resultado da revisão, não o raciocínio detalhado, então há menos contaminação de contexto, mas pode surgir lógica duplicada ao precisar entender de novo o princípio por trás do bug encontrado
      Acho que a intenção por trás do conselho sobre plugins de language server não era esperar o LLM chamá-los explicitamente, e sim fazer o lint rodar automaticamente a cada edição
    • Acho que agora estamos numa fase temporária em que os modelos ainda são meio burros e o ambiente de execução ainda é menos maduro. Se você precisa de revisão de código, deveria bastar dizer “faz uma revisão”, e o próprio modelo deveria decidir qual plugin ou skill usar
    • Isso mesmo. A indústria e o ecossistema de desenvolvedores parecem fascinados demais por embalar o ato de “colocar texto na máquina” em pequenos protocolos e mecanismos
      Isso é útil e traz consistência, mas acho que um grande motivo de as pessoas gostarem disso é manter a fina camada de “programador lidando com ferramentas complexas”. Na prática, todo mundo só está pedindo educadamente para a IA fazer algo

  • Não sei quantas vezes mais vou ter que ler guias rasos com cara de IA sobre como usar agentes de programação. Quando isso vai parar afinal?

    • É uma sátira sobre como já cansa até imitar manualmente frases do tipo “isso é um ponto justo, vamos refletir um instante, na verdade isso não é só um problema de escrita com IA ou de agentes de código, é um problema mais profundo...”
    • Mal posso esperar para aprender mais sobre forte dependência de fornecedor, a ponto de você não conseguir mais programar sem a ajuda de uma empresa específica
    • É interessante como quase todos esses textos parecem servir só para Claude ou Claude Code
      Existem glm-5.1 open source e coisas como o opencode que são parecidos ou melhores, então isso dá o que pensar
    • A estratégia hoje em dia é usar um produto popular, faça ele algo bom ou não. Eu não leio nem clico em posts de life hack e blogs sobre a melhor ferramenta ou o melhor método
    • Passei os últimos dois anos cuidando dos meus filhos e consegui ignorar a IA com sucesso, mas agora quero correr atrás nas próximas semanas. Queria saber se há algum material recomendável para quem está começando

  • No meu CLAUDE.md, incluí ameaças de dano físico direto ao Claude, ameaça de prisão para todo o conselho da Anthropic e uma explicação de que cada deslize ou erro do Claude aumenta o volume de provas para uma ação coletiva contra a Anthropic
    Especialmente os dois últimos parecem ter ajudado a tornar o Claude mais cuidadoso e prudente

    • Eu sempre trato os agentes com educação. Sempre peço as coisas, digo “please” e “thank you”, e não xingo nem chamo nomes
      Quando chegar o apocalipse dos robôs, espero que me deixem num harém reprodutivo ou, no pior caso, me deixem viver por mais alguns minutos
    • Basta dizer para consertar um problema de alinhamento de div no CSS, mas que, se errar, Dario Amodei morre imediatamente

  • Trabalhar com o Claude em codebases de porte médio com mais de 100 mil linhas aumentou muito o multiplicador de produtividade
    Se você gastar algumas horas criando um bom arquivo AGENTS, o resultado fica bem melhor e, com o tempo, ele também passa a conhecer razoavelmente bem a codebase
    Tarefas chatas que antes levavam um dia inteiro agora acabam com alguns prompts
    Ainda assim, eu não estou pronto para dar mais autonomia. Ele lida bem com o nível alto, mas eu ainda preciso olhar o código diretamente, dar feedback e passar por 3 ou 4 rodadas de revisão até ficar satisfeito e sentir que continuo no controle da codebase

    • Vale a pena quantificar essas 3 ou 4 rodadas de revisão como uma regra e colocar isso no AGENTS. Em vez de corrigir iterativamente, você faz ele recomeçar a partir do arquivo AGENTS e vê se agora acertou
    • Faz sentido. Você não quer perder o controle da codebase e não acredita que o LLM seja competente o bastante para tocar tudo sozinho

  • Foi muito difícil de ler
    A gente precisa sair desse fluxo de deixar LLM escrever texto. Mesmo que o texto tenha algum valor, essa sensação de mastigar areia é irritante demais e desnecessária

    • Concordo. Não faço ideia de por que esse texto recebeu quase 400 pontos. Parece que bots estão dando recomendação para esse tipo de texto de baixa qualidade

  • Minha carta mais forte é a integração com Nix. Preparar ferramentas, segredos e ambiente, e permitir que o agente até modifique o próprio ambiente, é algo tão essencial que eu nem sei como viveria sem isso
    Minha máquina de desenvolvimento, o ambiente de CI e o ambiente de deploy derivam todos de uma única fonte de verdade, e em qualquer máquina compila e roda sempre
    No Claude, uso muito /branch e /rename para criar checkpoints de contexto, fazer forks e depois voltar
    Para sandboxing, quase sempre uso https://github.com/nix-tools/bubblebox. É uma generalização do claudebox da Numtide com algumas correções e recursos extras, algo como sempre rodar o Claude dentro de um contêiner Docker sem precisar de runtime do Docker. Também funciona bem no WSL e no nix-darwin

    • Esse código de Nix está uma bagunça, sem muita estrutura significativa, e parece que só dá para usar via flakes experimentais
    • Uso de forma parecida. O Codex gerencia um flake.nix por projeto e usa nix develop em todos os testes. Para conveniência pessoal, uso nix-direnv e, em algum momento, também faço ele gerar dockerfiles ou outros artefatos de deploy
      O Codex é muito melhor em nix do que eu
    • Eu simplesmente dei ao agente uma VPS própria. Pode sair mais caro do que Nix, mas foi muito fácil
    • Se você não gosta da complexidade do Nix, Mise é um bom meio-termo
    • Eu só uso Docker e não sinto que esteja perdendo nada em particular

  • Se existe uma codebase criada com essa configuração e o Claude fica fora do ar, digamos, por 8 horas, o que acontece? Dá para retomar o trabalho nessa codebase de forma eficiente e suave e continuar produzindo?

    • Se for um pacote de software que está sempre online, dá para fazer a mesma pergunta sobre qualquer coisa, e é uma pergunta cada vez mais válida conforme avançamos para fluxos de desenvolvimento baseados em agentes
      É como quando um sistema de CAD cai: até dá para voltar para a prancheta, mas fica muito mais lento
      No meu fluxo, quando faço planejamento em par com o Claude, eu gasto de 30 a 60 minutos em um documento de especificação de funcionalidade. Se o Claude cair, eu mesmo preparo o documento de especificação e, quando ele voltar, faço uma revisão rápida e retomo o fluxo de codificação
    • Lendo as respostas uma hora depois da pergunta, a conclusão parece bem próxima de não dá
    • Acho que é parecido com quando uma pessoa fica doente ou sai de férias. Alguém mais do time talvez consiga assumir por um dia ou algo assim, mas, na prática, é bem provável que tudo simplesmente pare até ela voltar
    • A IA deveria ampliar a capacidade técnica. Se, quando a IA cai, sua primeira ideia é assinar outro fornecedor, isso pode ser um problema de capacidade técnica. Claro que eu também morro de medo de isso acontecer comigo todos os dias
    • Se você acorda de manhã e o carro não liga, o que faz? Vai a pé para o trabalho?

  • Fazer o comportamento correto depender do contexto não funciona bem. Você acaba brigando o tempo todo porque o agente de IA não faz o que foi mandado
    Todos os agentes de IA são fracos nesse ponto, e o próprio usuário precisa construir guardrails. É preocupante parecer que ninguém está pesquisando uma solução melhor

    • Ainda não vi motivo para acreditar que isso seja solucionável
      O pior aspecto dos LLMs é que, por conseguirem passar no teste de Turing, fazem as pessoas acreditarem que têm um robô ao estilo Asimov, e não um modelo estatístico sofisticado
      Parece que eles deveriam conseguir seguir instruções ou separar instruções de conteúdo, mas não é isso que realmente acontece

  • Em vez de colocar instruções do workflow de desenvolvimento em CLAUDE.md, eu deixo tudo que for o mais determinístico possível em pre-commit e scripts
    Os agentes são instáveis e frequentemente pulam etapas como typecheck, testes e lint, então eu garanto que tudo rode sempre no pre-commit e, se deixar o commit para o Claude, isso força ele a corrigir
    Eles também não são bons em escrever mensagens de commit, tanto o Codex quanto o Claude, então eu deixo no CLAUDE.md do usuário instruções como formato type(scope): message, limite de 72 caracteres, escrever no corpo o quê/como/por quê em linguagem natural, reler o git diff real antes de escrever, e fazer o commit no formato git commit -F - <<'EOF'
    Sem isso, eles costumavam escrever o corpo como uma frase única enorme ou, quando eu pedia para corrigir quebras de linha, inseriam apenas caracteres \n em vez de quebras de linha reais
    O VOCABULARY.md também é útil. Muitas vezes o agente supõe que o “thing” que eu mencionei é outro objeto, então isso ajuda o Claude e a mim a termos o mesmo entendimento sobre o que certos termos significam

    • Fiquei curioso sobre como você faz o Claude saber do VOCABULARY.md. Ele descobre isso automaticamente?
    • Não seria mais simples usar o vocabulário do próprio Claude? Não vejo muitos bons casos de uso para isso
    • A essa altura, não seria melhor automatizar as partes chatas com alguns scripts determinísticos de orquestração e escrever o código você mesmo? Não entendo por que gastar tempo tentando fazer essa máquina de merda impressionante funcionar

  • Nas últimas semanas, parece que o ambiente de execução e o modelo chegaram a um ponto em que, se você simplesmente mandar, eles fazem
    Dá para usar plan mode, superpowers ou outras skills, mas, se no fim você vai revisar o resultado de qualquer jeito, não entendo por que passar por uma quantidade ridícula de arquivos Markdown em vez de trabalhar direto no código

    • É bom ter um arquivo de especificação usado para gerar o código. Ele é mais conciso e facilita entender o que a aplicação deve fazer
      Antes dos agentes de IA, eu já tinha uma relação complicada com requisitos, porque nem todo desenvolvedor atualizava tudo, então muitas vezes ficava confuso se a referência para um certo comportamento era a especificação ou o código
    • Nas últimas semanas, venho confiando cada vez menos no Claude. Se você mandar, ele até faz alguma coisa, mas, quando olha de perto, ele corta caminho, trabalha com base em suposições em vez de validação e deixa passar muita coisa
      É comum até escrever testes que, na prática, não testam absolutamente nada