15 de julio de 2026

DRY para tu IA: deja de copiar y pegar reglas en cada proyecto

Como desarrolladores tenemos una regla casi sagrada: no repetirnos. La aplicamos a todo… menos a la IA, donde copiamos y pegamos a mano las mismas reglas, guías y prompts de un proyecto a otro.

🧩 El problema: copiar y pegar reglas no escala

Cada repo acaba con su propia versión de las reglas: nadie sabe cuál es la buena, mejoras una convención y las otras diez se quedan viejas, y sin ellas delante la IA inventa. Nos estamos repitiendo. La solución, como con el código: una única fuente de verdad y una forma de distribuirla.

🧭 Las soluciones de un vistazo

Dos piezas que se complementan:

Una CLI que, con un comando, inyecta y mantiene las configs de IA en cada repo — el "cómo trabajamos en este proyecto".
Paquetes que llevan sus propias skills dentro: publicas la librería junto a las instrucciones de cómo usarla — el "cómo se usa esta herramienta".

🚀 Solución 1: una CLI que prepara el contexto de IA del proyecto

En lugar de copiar y pegar, ejecutas un comando desde la raíz del proyecto y queda configurado. La CLI vive en su propio repo (tu fuente de verdad) y cada proyecto se sirve lo que necesita. A lo largo del artículo usaré ai-ctx como ejemplo; su código está en GitHub por si quieres verlo.

🧱 Estructura de comandos: una acción, un comando

Cada comando distribuye un tipo de configuración y hace una sola cosa:

Comando	Para qué sirve	Qué instala
`add-rules`	Reglas que el agente debe cumplir (convenciones de código, arquitectura).	Reglas en el repo destino.
`add-guides`	Guías más largas y explicativas (cómo montamos X, patrones recomendados).	Documentos de guía.
`add-skills`	Skills: capacidades empaquetadas que el agente puede invocar.	Skills en el proyecto.
`add-context`	Genera un índice vivo de todo lo anterior.	Un archivo de contexto.

✅ Bloques a seleccionar: instala solo lo que aplica

Un frontend no necesita las reglas de backend, y viceversa. Por eso instalar es interactivo: un selector donde marcas por categorías (frontend, backend, shared) y solo entra lo que marcas. Configuración tipo "menú", sin traer reglas de más "por si acaso".

📚 El índice vivo: el punto de entrada para el agente

¿Cómo sabe el agente qué hay instalado y dónde? Con un índice vivo (en ai-ctx, un app-context.md) que:

Se genera del estado real: lista las reglas, guías y skills instaladas, con su descripción y ubicación.
Se actualiza solo: se regenera cada vez que instalas algo.
Preserva lo que escribes tú: las notas del equipo conviven con el índice y la regeneración no las pisa.

Un único sitio al que cualquier agente (o persona nueva) mira para entender, de un vistazo, cómo está configurado el proyecto.

🧰 Stack tecnológico

Con herramientas estándar de Node sobra: Node.js + TypeScript de base, commander.js para los comandos, @inquirer/prompts para los selectores y tsup para empaquetar como ESM ejecutable con npx.

🔧 Cómo construirla, a grandes rasgos

Un comando por acción, aislado en su módulo. Añadir una capacidad es añadir un comando.
Catálogos de assets versionados en el repo de la CLI: tu fuente de verdad, que viaja dentro del paquete.
Reescritura al instalar: las reglas traen placeholders (p. ej. rutas de un monorepo) que la CLI expande al vuelo.
Un índice generado desde el estado real, no una lista manual.

📦 Solución 2: paquetes reutilizables que llevan sus skills dentro

La CLI resuelve el "cómo trabajamos aquí". Pero hay otra repetición igual de costosa: explicarle a la IA cómo se usa cada herramienta interna, algo que cambia con cada versión. La idea: el paquete publica, junto a su código, las skills que enseñan a usarlo.

Una librería de componentes que, además de exportarlos, incluye una skill con cómo se compone la UI, qué props usar y qué antipatrones evitar. Lo mismo para un @tu-org/backend-core: cómo se construye un servicio y qué convenciones seguir.

💡 Por qué esto es tan potente

Versionado real. La skill viaja con la versión del paquete: si tienes la 2.3, el agente ve la doc de la 2.3, no un README que se quedó en la 1.0. Se acabó el desfase entre la API real y lo que la IA cree que existe.
El agente sabe construir, no solo qué existe. Una lista de funciones no enseña a montar una app; una skill sí: patrones, ejemplos y "esto sí / esto no".
Menos alucinaciones y onboarding inmediato. El conocimiento va empaquetado y se distribuye con npm install. Quien lo instale —persona o agente— lo hereda al instante.

🔗 Cómo encaja con la CLI

La CLI instala y registra esas skills; el paquete es la fuente que las mantiene al día. Una distribuye, la otra es el origen versionado.

🏢 Un repositorio central de configs de IA para toda la empresa

Si merece la pena una fuente de verdad para el código, ¿por qué no para todas las configs de IA de la organización? Imagina un repo central con las configs de la empresa entera, no solo ingeniería:

Marketing: tono de voz, plantillas de presentaciones, guías de copy que suenen a la marca.
Ventas: plantillas de propuestas, respuestas tipo, criterios de calificación.
Soporte: guías de estilo, escalados, límites de lo que la IA puede prometer.

El beneficio: toda la empresa rema en la misma dirección, y cuando algo cambia se actualiza en un solo sitio. Es DRY a escala de organización: una fuente de verdad distribuida, en vez de mil copias divergiendo en silencio.

🔁 En el día a día

Con las dos piezas montadas, el flujo es casi aburrido de tan simple:

Proyecto nuevo → CLI con npx, seleccionas los bloques, y en segundos el repo tiene reglas, guías y skills. El índice queda generado.
Instalas un paquete interno → sus skills vienen incluidas y al día. No configuras nada.
Mejoras una regla → la cambias en la fuente y los proyectos se ponen al día re-ejecutando el comando o actualizando la dependencia.

🏁 Conclusión

DRY nunca fue solo para el código. Aplicarlo a tus configs de IA convierte el conocimiento del equipo —cómo escribes código, cómo se usan tus herramientas, cómo suena tu marca— en algo versionado, distribuible y consistente. Deja de repetirte. También con la IA.

🆚 CLI vs MCP: ¿por qué no usar MCP para todo?

El MCP es excelente para conectar la IA con datos o APIs en tiempo real, pero usarlo para reglas estáticas de código es sobreingeniería. La CLI gana porque inyecta la configuración directamente en el repo: las reglas se versionan en Git junto al código. Clonas el proyecto dentro de dos años y la IA respeta la arquitectura exacta de esa versión, sin que nadie tenga que levantar servidores MCP locales.

En resumen: CLI para reglas versionadas y estáticas; MCP para contexto dinámico.