Un solo archivo Markdown para configurar Claude, Codex, Cursor y Copilot

Cualquier equipo que use más de un asistente de código conoce el problema: cada herramienta tiene su propio formato de instrucciones, su propia carpeta de configuración y su propia forma de interpretar el contexto del proyecto. El resultado habitual es un conjunto disperso de archivos que nadie mantiene sincronizados. Un desarrollador llamado kernalix7 ha publicado esta semana en Hacker News, bajo el hilo Show HN, un repositorio llamado ai-project-setup que propone una solución directa: un único archivo Markdown que sirve como fuente de verdad para Claude, Codex, Cursor y GitHub Copilot a la vez.

La propuesta tiene la virtud de su simplicidad. En lugar de mantener un `CLAUDE.md`, un `.cursorrules`, un `copilot-instructions.md` y un archivo de configuración de Codex por separado, el repositorio plantea una estructura compartida que cada herramienta puede consumir, ya sea directamente o mediante un script de distribución incluido en el propio repo.

Cómo funciona la aproximación

El núcleo del proyecto es un archivo Markdown con secciones claramente delimitadas: convenciones de código, contexto del proyecto, restricciones, ejemplos de patrones preferidos y notas de arquitectura. La idea es que este archivo sea el único que el equipo tenga que actualizar cuando cambien las reglas del proyecto.

El repositorio incluye además un pequeño script que lee ese archivo maestro y distribuye los fragmentos relevantes a cada destino:

• Para Claude Code, genera o actualiza el `CLAUDE.md` en la raíz del proyecto, que la CLI de Anthropic carga automáticamente como contexto de sistema.
• Para Cursor, escribe el `.cursorrules` correspondiente.
• Para GitHub Copilot, coloca el contenido en `.github/copilot-instructions.md`.
• Para Codex, adapta la salida al formato que espera su configuración local.

No hay magia especial: es una capa de distribución sobre formatos ya existentes. Lo que aporta es la disciplina de tener una sola fuente que editar.

Por qué tiene sentido en equipos mixtos

En mayo de 2026, es habitual que dentro de un mismo equipo de desarrollo coexistan usuarios de Claude Code, desarrolladores que prefieren Cursor y otros que trabajan con Copilot directamente desde VS Code. Cuando cada herramienta tiene sus propias instrucciones, la coherencia se rompe: el asistente A insiste en usar tabs, el B en espacios, y las revisiones de código se convierten en arbitraje de estilos.

La propuesta de kernalix7 ataca ese problema sin imponer una herramienta única. Cada desarrollador sigue usando lo que prefiere; el archivo maestro garantiza que todos parten del mismo conjunto de instrucciones.

Para equipos que ya tienen un `CLAUDE.md` bien trabajado —con contexto de arquitectura, convenciones de naming y restricciones de dependencias— la migración es inmediata: ese archivo puede convertirse en la fuente y el script se encarga del resto.

Limitaciones que conviene tener presentes

El proyecto tiene en este momento un punto de partida modesto: un repositorio recién publicado, sin issues, sin estrellas acumuladas y con la discusión de Hacker News todavía en cero comentarios en el momento de su publicación. No hay versión estable documentada ni tests automatizados visibles en el repositorio.

También hay un límite conceptual: las instrucciones genéricas funcionan bien para convenciones de estilo y contexto de proyecto, pero cada herramienta tiene capacidades distintas. Claude Code, por ejemplo, soporta skills y subagentes que no tienen equivalente directo en Cursor o Copilot. Un archivo verdaderamente unificado tiende a quedarse en el mínimo común denominador, lo que puede ser suficiente para muchos equipos pero insuficiente para quienes explotan las capacidades específicas de cada plataforma.

El script de distribución tampoco es bidireccional: si alguien edita directamente el `.cursorrules`, ese cambio no se propaga al archivo maestro. La disciplina de mantener el flujo en un solo sentido depende del equipo, no de la herramienta.

Para quién es útil ahora mismo

El repositorio tiene valor inmediato para desarrolladores en solitario o equipos pequeños que ya saltan entre varias herramientas y quieren una forma ligera de mantener coherencia sin infraestructura adicional. También es un buen punto de partida para quien quiera construir algo más robusto encima: la idea central es sólida aunque la implementación actual sea inicial.

Desde ElephantPink, la aproximación nos parece sensata como punto de partida, aunque el valor real llegará cuando la comunidad aporte soporte para más herramientas y, sobre todo, algún mecanismo de sincronización bidireccional que elimine la dependencia de la disciplina manual.