3 puntos por weedroot 28 일 전 | 1 comentarios | Compartir por WhatsApp

Hice una pequeña herramienta llamada ConfigDeck (https://configdeck.dev/ko).
Los generadores de archivos de configuración en sí son un tema común, pero la forma de construirlo fue un poco experimental, así que quería compartir la experiencia.

Qué es

Como era molesto copiar y pegar archivos de configuración como .eslintrc, prettier.config, tsconfig desde proyectos anteriores cada vez que arrancaba uno nuevo, lo hice en un formato donde eliges opciones y luego descargas el resultado.

  • Soporta 9 tipos de archivos de configuración: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
    .gitignore, .editorconfig, .env.example
  • Presets de stack: React+Vite, Next.js, Astro, Node.js, etc., para generar varios archivos de una sola vez
  • Migración de .eslintrceslint.config.mjs (conversión a Flat Config)
  • Soporte en coreano / inglés
  • Sitio 100% estático (Cloudflare Pages, 0 KB de JS en páginas de contenido)
  • Los valores ingresados se procesan solo dentro del navegador, sin envío externo

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

Cómo lo hice — delegué bastante a la AI

Esta vez intenté organizar el propio proceso de desarrollo usando Claude Code.
Lo que hizo la persona fue definir la dirección de producto y hacer revisiones intermedias; la implementación se la dejé a la AI tanto como fue posible. Hubo partes que salieron bien y también muchos tropiezos, pero pensé que si hacía público el proceso podría servirle como referencia a quienes estén probando algo parecido.

Dejé públicas todas las configuraciones usadas en el directorio .claude/ del repositorio:
https://github.com/jsg3121/configDeck/tree/main/.claude

  • Documentación del harness (CLAUDE.md, conventions, ADR, etc.)
  • Agentes por dominio (config-maker, ui-publisher, ux-designer,
    qa-agent, seo-specialist, etc.)
  • Slash skills (/lint-check, /code-review, /seo-audit, /research, etc.)
  • Registro de decisiones técnicas con ADR
  • Hooks de automatización (formateo en PostToolUse, validación de build/lint en Stop)

Lo principal que cuidé al escribirlo fue el enfoque "Why-First". En vez de anotar solo reglas, al escribir también el porqué, sentí que la AI tomaba decisiones un poco más consistentes en edge cases.

Configuré la colaboración entre agentes más o menos con este flujo:

product-plannerux-designerui-publisherqa-agent
(planificación) (diseño) (implementación) (validación)

Para QA, puse subagentes unit-tester / e2e-tester / static-analyzer, y qa-agent reúne los resultados para generar un reporte.

Tropiezos y aprendizajes

Lo bueno

  • Como las decisiones quedaban registradas en ADR, incluso con el paso del tiempo era fácil volver a entender "¿por qué lo hice así?".
  • Al dejar las convenciones escritas en el harness, parece que los resultados salen relativamente consistentes incluso si cambia la sesión.
  • Al dividir los agentes por dominio, planificación e implementación no se mezclaban en un mismo contexto, así que era más fácil seguir el proceso.

Lo difícil

  • Al principio no tenía harness, así que el estilo del resultado cambiaba cada vez, y lo fui puliendo varias veces hasta llegar a la forma actual.
  • El costo de tokens resultó más pesado de lo esperado, así que según el tamaño del trabajo estoy usando una guía aparte para elegir entre conversación principal / skill / agente.
  • A veces la AI reportaba como si todo estuviera bien, así que fue útil dejar una validación automática de build / lint con el hook Stop.

Todavía no puedo decir que haya encontrado la respuesta correcta, y seguramente existan maneras mejores.

Enlaces

1 comentarios

 
heycalmdown 27 일 전

Es una idea divertida. No siempre se trabaja solo en proyectos greenfield, así que también sería interesante que, al contrario, si le das un archivo de configuración existente que ya está hecho un desastre, te explique qué hace cada opción y te permita activarlas o desactivarlas.