1 pontos por seob717 4 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp

Olá, sou um desenvolvedor que usa o Claude Code todos os dias. Conforme o CLAUDE.md foi crescendo, duas coisas continuaram me incomodando.

  1. As regras são carregadas por completo no início da sessão (t=0), mas o momento em que elas realmente são necessárias vem dezenas de turnos depois. Quando o contexto se acumula e a compactação passa uma vez, as regras explícitas são rebaixadas a um pano de fundo difuso.
  2. Documentos de referência como @docs/pr-rules.md pagam tokens adiantado em toda sessão, embora apenas algumas sessões realmente criem PRs.

Então criei um plugin que compila as regras não como uma “declaração no topo da sessão”, mas como “event listeners acoplados a ações”.

/nunchi:compile extrai regras do CLAUDE.md e dos documentos de referência, gerando arquivos de regras com gatilhos anexados (ferramenta + regex), e o hook PreToolUse lê e entrega o documento original na hora, logo antes de uma ação como gh pr create. Quando a compactação acontece, o hook SessionStart redefine o estado de entrega para que a regra seja entregue novamente no próximo gatilho (reentrega medida: 5/5). Todas as entregas são registradas em JSONL, e com /nunchi:report dá para ver “qual regra disparou quando e o que ela economizou”.

Todos os números estão publicados no repositório como experimentos pré-registrados.

  • Tokens no início da sessão: ao remover 8 documentos de regras (~76KB) do @import, caiu de 79.683 para 45.808 (−42,5%, ~34k tokens). O custo dos documentos só é pago nas sessões em que a ação correspondente realmente dispara.
  • Violações de regras após compactação: na baseline (apenas CLAUDE.md), houve 1 caso em 3 execuções, e foi a primeira violação observada em todo o experimento — exatamente no ponto em que a compactação descartou uma regra que estava em um documento @ de referência. Ainda assim, como isso não passou no gate pré-registrado, não afirmo que “o JIT tem taxa de conformidade maior” — isso ainda não foi validado, e o README também diz isso.
  • Qualidade da compilação: em 12 CLAUDE.md reais encontrados na prática (airflow, next.js, supabase etc., 166KB), validade de formato de 100%, 0 alucinações. O recall foi baixo, 35% contra um gold adversarial, e isso também não está sendo escondido: está sendo acompanhado em issues.
  • Compatibilidade com documentos em coreano: em 4 CLAUDE.md reais em coreano (incluindo pinpoint), 0 violações de formato, 0 extrações excessivas, 0 alucinações, e 88% de acerto na classificação de intensidade de expressões proibitivas (“nunca fazer commit direto”). Também há um guia de escrita para quem mantém o CLAUDE.md em coreano.

Diferença em relação às abordagens existentes: regras com escopo por caminho usam gatilho de “leitura de arquivo”, enquanto o nunchi usa gatilho de “ação” (os dois foram projetados para coexistir). Ferramentas do tipo Context Mode/RTK comprimem a saída que entra no contexto; o nunchi não comprime, ele agenda o momento da entrega. A economia de tokens é um efeito colateral; o ponto central é que as regras estão com certeza no contexto imediatamente antes da ação, e isso pode ser comprovado por logs.

No momento eu sou o único usuário real, então preciso de dados sobre como isso funciona em outros fluxos de trabalho (monorepos, equipes de outros idiomas, CLAUDE.md grandes). A instalação é em duas linhas:

/plugin marketplace add seob717/nunchi  
/plugin install nunchi@nunchi-marketplace  

Agradeço qualquer feedback: pontos em que a inferência de gatilhos erra, tipos de regra que regex não consegue capturar, coisas que você gostaria de ver a mais no relatório — tudo isso ajuda bastante.

Ainda não há comentários.

Ainda não há comentários.