Codifique o processo, não a resposta: cinco plugins do Claude Code que uso todo dia

Faz alguns meses que venho construindo plugins para o Claude Code. Não porque a experiência nativa seja ruim. Ela é boa. Construí porque eu ficava fazendo as mesmas coisas na mão, sessão após sessão, até cansar.

Em algum momento você para de narrar o mesmo contexto toda vez e começa a se perguntar por que o processo simplesmente não está codificado.

Então eu codifiquei. O resultado é uma coleção pequena de cinco plugins que uso diariamente. São abertos, instaláveis em dois comandos, e mudaram de verdade a forma como eu trabalho. Aqui vai o que cada um faz e por que existe.

O problema das ferramentas de IA baseadas em chat

Toda sessão começa do zero. Você explica o projeto, as convenções, o que acabou de acontecer, o que está tentando fazer. Se você é disciplinado, mantém um CLAUDE.md. Se é menos disciplinado, cola o mesmo parágrafo sobre sua stack quinze vezes por semana.

Enquanto isso, o ciclo real de desenvolvimento (pegar a issue, escrever testes, implementar, consertar o CI, responder aos comentários de review, fazer o merge) são doze passos que exigem disciplina para executar direito. O Claude consegue fazer tudo isso, mas só se você ficar apontando a direção.

Eu queria parar de apontar.

claude-memory: um cérebro de três camadas

A primeira coisa que construí foi um sistema de memória. Não um caderno, não um arquivo markdown. Um sistema multicamada de verdade, inspirado de longe em como funciona a memória humana.

A camada 1 é episódica. No fim de cada sessão, um hook captura o estado do git, um snapshot do transcript e alguns metadados mecânicos. Nenhum LLM envolvido, só um shell script. Roda rápido e nunca falha.

A camada 2 é a consolidação semanal. Um comando /claude-memory:consolidate dobra as capturas episódicas em resumos narrativos: decisões, becos sem saída, lições aprendidas. É aqui que o LLM faz trabalho de verdade. Ele lê as capturas cruas, escreve algo coerente e redige qualquer coisa que pareça segredo ou dado pessoal.

A camada 3 são as abstrações duráveis. Heurísticas destiladas como “nunca resolver conflito de migration automaticamente” ou “sempre ler o package.json antes de rodar qualquer comando”. Essas carregam em toda sessão.

O hook de início de sessão injeta as memórias relevantes da camada 3 mais os últimos resumos da camada 2. Quando o Claude abre uma sessão, ele já sabe o que a gente estava fazendo, o que decidiu e por quê.

Tudo é armazenado localmente, por projeto. Sem serviço externo, sem sincronização, sem necessidade de API key.

delivery-workflow: codificando o ciclo da feature

Este faz o trabalho de desenvolvimento propriamente dito. Tem quatro skills.

O dev-workflow é um ciclo TDD de oito passos que roda a partir do número de uma issue do GitHub. Ele cria a branch, analisa a issue, escreve testes que falham, implementa, roda cobertura, faz uma passada de code review, corrige os problemas e roda uma revisão de segurança. Nessa ordem, toda vez, sem atalho. Um stop hook bloqueia a saída se você tem arquivos TypeScript não commitados e um script test:cov, então não dá para pular o passo de cobertura sem querer.

O epic-workflow opera numa altitude maior. Você dá um Epic do GitHub e ele navega a hierarquia de Epic, Features e Tasks, atualizando o board do GitHub Project conforme avança. Limite rígido de três subagentes em paralelo, com validação obrigatória dos critérios de aceite antes de qualquer coisa ser marcada como Done.

O pr-autoheal monitora os checks de CI num PR aberto, baixa os logs que falharam e despacha um subagente de diagnóstico para achar a causa raiz (rebase desatualizado, chamadas não atualizadas, erros de tipo, violações de lint). Ele aplica a correção, verifica localmente e faz o push. Até cinco iterações. Se não conseguir resolver em cinco, escala com o log completo das iterações.

O pr-review-fix busca todos os comentários abertos de review de um PR (usando REST e GraphQL para pegar o estado das threads corretamente), planeja as correções, mostra o plano, executa um commit por problema e posta respostas inline em cada thread resolvida.

issue-ops: a issue do GitHub como API

Duas skills aqui.

O bug-rca pega uma issue do GitHub e roda uma investigação somente leitura: grep pela string de erro, rastreia o caminho do código, checa o git blame, inspeciona mudanças recentes e, opcionalmente, consulta backends de observabilidade como Datadog, Sentry, GCP Cloud Operations ou Loki. Depois sintetiza uma análise de causa raiz com prioridade (P0 a P3) e estimativa de tamanho (XS a XL), e atualiza o título e o corpo da issue com os achados. Ele nunca toca em arquivo fonte. A saída é a issue.

O spec-to-issues pega um documento de especificação (um PRD, um bundle do OpenSpec, ou só uma pasta de docs) e cria uma hierarquia completa de Epic, Spec e Task no GitHub. Ele interpreta a estrutura, detecta o repositório e o board, roda um preview em dry-run para aprovação e cria as issues em ordem. Dependências entre tarefas são rastreadas como relações de blocked-by.

context-docs: carregando o contexto do projeto sob demanda

Este gera documentação modular em docs/context/. Não um README monolítico, mas um conjunto de arquivos autocontidos que cada agente pode carregar de forma independente.

Existe um INDEX.md que é sempre carregado, mais architecture.md, ADRs, padrões, convenções, testes, exemplos, troubleshooting e tooling. Cada arquivo é dimensionado para ser lido rápido. O gerador varre arquivos de configuração, código, testes, CI/CD e histórico do git para descobrir sua stack e suas convenções, e então escreve a documentação a partir do que observa. Ele sinaliza ambiguidades explicitamente em vez de chutar.

A ideia é que um agente trabalhando num bug de rota não precisa do arquivo de padrões de teste. Ele carrega o índice, vê que existe um architecture.md, carrega aquele e segue. O contexto fica enxuto.

design-to-ui: do mockup ao componente

O mais novo. Você dá uma fonte de design (uma URL do Google Stitch, um handoff do Claude Design, ou só um screenshot) e ele converte aquilo em componentes de UI nativos do seu framework.

Ele detecta automaticamente seu framework (React, Vue, Svelte, Angular e outros), seu sistema de estilos (Tailwind, CSS Modules, styled-components), sua biblioteca de ícones e seu diretório de componentes. Depois decompõe o design em camadas atômicas: átomos, moléculas, organismos, templates. Ele varre seus componentes existentes e reaproveita o que dá, criando os que faltam em ordem de dependência.

O desenho de “fonte plugável, destino plugável” significa que ele não se importa com como você obteve o mockup nem com o que você está construindo. Se conseguir ler o design e detectar o projeto, funciona.

Como instalar

Os cinco plugins vivem num único repositório. Dois comandos para começar:

/plugin marketplace add edusouza/claude-plugins
/plugin install delivery-workflow@claude-plugins

Troque delivery-workflow por qualquer um dos outros: claude-memory, issue-ops, context-docs, design-to-ui.

O código está em github.com/edusouza/claude-plugins. Issues e PRs são bem-vindos. São ferramentas que uso em projetos reais e mantenho ativamente.

O que eu aprendi

Os plugins mais úteis não são os mais chamativos. O claude-memory é só hooks e shell scripts. O context-docs é só um escritor de arquivos disciplinado. Mas eles eliminam a fricção que, de outro jeito, me faria pular o passo por completo.

Alguns padrões se repetem. Codifique o processo, não a resposta. Dê ao agente o contexto certo no momento certo, não todo o contexto o tempo todo. Deixe o LLM fazer o trabalho difícil de diagnóstico e síntese, e mantenha o mecânico (git hooks, escrita de arquivos, chamadas de API) determinístico.

Esses plugins são a versão externalizada dos hábitos que eu tentava segurar na cabeça. Funcionam melhor lá fora.