3 pontos por weedroot 28 일 전 | 1 comentários | Compartilhar no WhatsApp

Criei uma pequena ferramenta chamada ConfigDeck (https://configdeck.dev/ko).
Geradores de arquivos de configuração em si são um tema comum, mas a forma como eu a construí foi um pouco experimental, então quis compartilhar a experiência.

O que é

Toda vez que eu começava um projeto, era incômodo ficar copiando e colando arquivos de configuração como .eslintrc, prettier.config e tsconfig de projetos anteriores, então criei algo em que você escolhe as opções e faz o download.

  • Suporte a 9 tipos de arquivos de configuração: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
    .gitignore, .editorconfig, .env.example
  • Presets de stack: React+Vite, Next.js, Astro, Node.js etc., gerando vários arquivos de uma vez
  • Migração de .eslintrceslint.config.mjs (conversão para Flat Config)
  • Suporte a coreano / inglês
  • Site 100% estático (Cloudflare Pages, 0KB de JS nas páginas de conteúdo)
  • Os valores inseridos são processados apenas no navegador, sem envio para fora

Stack técnica: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict

Como foi feito — deixei bastante coisa por conta da IA

Desta vez, tentei organizar o próprio processo de desenvolvimento usando o Claude Code.
O que foi feito por humanos ficou mais no direcionamento do planejamento e em checkpoints intermediários, e a implementação foi delegada à IA tanto quanto possível. Houve partes que funcionaram bem e muitos erros e ajustes no caminho, mas achei que valia organizar e compartilhar o processo para servir de referência a quem estiver tentando algo parecido.

Deixei públicas todas as configurações usadas no diretório .claude/ do repositório:
https://github.com/jsg3121/configDeck/tree/main/.claude

  • Documentação do harness (CLAUDE.md, conventions, ADR etc.)
  • Agentes por domínio (config-maker, ui-publisher, ux-designer,
    qa-agent, seo-specialist etc.)
  • Habilidades com barra (/lint-check, /code-review, /seo-audit, /research etc.)
  • Registro das decisões técnicas com ADR
  • Hooks de automação (formatação em PostToolUse, validação de build/lint em Stop)

Ao escrever isso, o principal cuidado foi algo como "Why-First". Em vez de registrar só as regras, percebi que, ao escrever também o motivo por trás delas, a IA parecia tomar decisões mais consistentes em edge cases.

Os agentes foram configurados para colaborar mais ou menos neste fluxo:

product-plannerux-designerui-publisherqa-agent
(planejamento) (design) (implementação) (validação)

No QA, há subagentes unit-tester / e2e-tester / static-analyzer, e o qa-agent reúne os resultados e monta um relatório.

Tentativas e erros

Pontos positivos

  • Como as decisões ficam registradas em ADR, mesmo depois de um tempo ficou mais fácil retomar o "por que isso foi feito assim?".
  • Ao documentar as convenções no harness, os resultados parecem sair relativamente consistentes mesmo quando a sessão muda.
  • Separar os agentes por domínio ajudou a não misturar planejamento e implementação no mesmo contexto, o que facilitou acompanhar o processo.

Dificuldades

  • No começo, como ainda não havia harness, o estilo dos resultados variava a cada vez, e foram necessárias várias rodadas de refinamento até chegar ao formato atual.
  • O custo de tokens pesou mais do que eu esperava, então hoje uso um guia separado para escolher entre conversa principal / skill / agente conforme o tamanho do trabalho.
  • Como às vezes a IA reportava que algo tinha dado certo quando não tinha, foi útil deixar a verificação automática de build / lint no hook Stop.

Ainda é difícil dizer que encontrei a resposta certa, e acho que pode haver formas melhores.

Links

1 comentários

 
heycalmdown 27 일 전

Que ideia interessante. Como nem sempre estamos trabalhando apenas em projetos greenfield, também seria legal se, ao contrário, você pudesse inserir um arquivo de configuração já bagunçado e ele explicasse o que é cada opção, além de permitir ativar e desativá-las.