Generador AGENTS.md / CLAUDE.md — 20+ Plantillas
Genera archivos de configuración de proyectos para Claude Code / Codex / Cursor / Windsurf / Gemini / GitHub Copilot con un solo clic desde 20+ plantillas prácticas (Next.js / React / Vue / Django / FastAPI / Rails / Laravel / Go / Rust y más). Compatible con los 6 formatos: AGENTS.md / CLAUDE.md / .cursor/rules/main.mdc / .windsurfrules / GEMINI.md / copilot-instructions.md con descarga en lote zip.
▶ 📦 Elige plantilla → instante
▶ 🎛 Reglas operativas 0 / 28
Añade reglas de comportamiento prácticas para agentes de IA, como «Obtén aprobación antes de tocar producción», «Siempre cita fuentes» y «Registra el progreso», con controles de ON/OFF. Estos se añaden a la sección correspondiente del archivo de salida.
Comandos
Estilo
Anti-patrones
Archivos clave
Tests
Otras notas
📚 Catálogo
Mostrar las 24 plantillas
📄 Archivo generado
AGENTS.md
📍 Dónde colocar
- AGENTS.md / CLAUDE.md / GEMINI.md → raíz
- Cursor → .cursor/rules/main.mdc
- Windsurf → .windsurfrules (root)
- Copilot → .github/copilot-instructions.md
📖 Dónde se suele tropezar
Genera archivos de configuracion de proyecto para Claude Code, Codex, Cursor, Windsurf, Gemini y GitHub Copilot a partir de mas de veinte plantillas, cubriendo los seis formatos AGENTS.md, CLAUDE.md, .cursor/rules/main.mdc, .windsurfrules, GEMINI.md y copilot-instructions.md, descargables juntos en un zip. Todo se ejecuta en el navegador. Una plantilla, sin embargo, no sabe nada de tu repositorio: y un archivo de instrucciones equivocado produce peores resultados que no tener ninguno. El agente lo sigue sin ponerlo en duda, de modo que una afirmacion que no cuadra con la realidad te vuelve convertida en una implementacion incorrecta.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Si lo dejas como plantilla, instruye cosas que no son ciertas | Un esqueleto generado contiene afirmaciones concretas que no son ciertas en tu proyecto: dice que las pruebas se lanzan con npm test cuando en realidad usas pnpm, describe una estructura de directorios que no existe, enumera convenciones de bibliotecas que no utilizas. Un agente confia en el archivo de instrucciones por encima del codigo: reintenta una y otra vez un comando documentado que no funciona y crea archivos en lugares inexistentes. El otro desperdicio es escribir lo que el codigo ya muestra: el framework en uso y los nombres de carpeta son cosas que el agente descubre por su cuenta en segundos. Cada caracter gastado ahi diluye la informacion que si importa. |
Escribe solo aquello que no se puede aprender leyendo el codigo. En concreto: los comandos que funcionan de verdad (la linea exacta de prueba, compilacion, despliegue y lint), las trampas en las que ya has caido y por que, lo que no se debe tocar y por que, y cual de varios enfoques posibles eligio este proyecto. Escribir el porque es lo de mayor valor: una razon se generaliza a situaciones que no dejaste escritas. En cuanto al proceso, obtendras un archivo mejor empezando de uno vacio y escribiendo diez lineas que partiendo de una plantilla. Y la validacion mas segura es encargar trabajo real a un agente y observar si siguio las instrucciones: anadir una linea cada vez que tropiece es la forma realista de hacerlo crecer. |
| Emitir los seis formatos y dejar que diverjan | Cada herramienta lee un archivo distinto, de modo que un equipo que use varias acaba con el mismo contenido en varios sitios. El problema es que esas copias divergen sin falta: alguien actualiza solo CLAUDE.md mientras .cursor/rules se queda como estaba hace tres meses, y el agente se comporta distinto segun la herramienta que uses. Peor aun, no hay ningun mecanismo que te avise de la divergencia: ambos siguen siendo sintacticamente validos y CI sigue pasando. Tambien conviene conocer las diferencias de carga: algunos se leen enteros siempre, otros se consultan en parte por peticion, unos miran solo la raiz del repositorio y otros leen tambien copias en subdirectorios, y esa diferencia aflora como "por algun motivo solo esta herramienta ignora las instrucciones". |
Elige un unico archivo canonico. En la practica, la forma manejable es tratar AGENTS.md como canonico y dejar los demas formatos como archivos breves que simplemente apunten a el: reducir CLAUDE.md a una sola linea que diga que se lea AGENTS.md ya elimina la duplicidad (un enlace simbolico tambien sirve donde la herramienta lo admita). No hace falta emitir todos los formatos: coloca solo los de las herramientas que usas de verdad. Y manten el archivo canonico en la raiz del repositorio, bajo Git: si lo pones en un directorio de configuracion personal, se convierte en una regla que no existe para el resto del equipo. Que sea revisable es lo que permite a otra persona comprobar que su contenido sigue cuadrando con la realidad. |
| Cuanto mas largo, menos funciona | Un archivo de instrucciones consume contexto en cada peticion: quinientas lineas de reglas son quinientas lineas menos de margen para leer el codigo real. Y cuanto mas largo, mas facil es que se contradiga: si "prefiere la implementacion mas simple" y "abstrae siempre" conviven en el mismo archivo, cual gana es impredecible. Otro fallo frecuente es escribir aspiraciones: es muy comun que el archivo diga que las pruebas son obligatorias mientras el repositorio no contiene ninguna. Esa contradiccion desconcierta al agente, porque no puede decidir si seguir el codigo existente o la regla. Y una regla que visiblemente no se cumple rebaja la credibilidad de todas las demas. | Escribelo corto, concreto y de forma que pueda comprobarse. Como guia, empieza con algo que quepa en una pantalla y anade una linea solo cuando surja un problema: intentar ser exhaustivo desde el principio garantiza lineas que nunca se usan. Prefiere reglas cuyo cumplimiento sea verificable: "escribe codigo legible" no se puede comprobar; "no modifiques src/legacy/" si. Y borra toda regla que el repositorio no cumpla de verdad: si quieres enunciar un ideal, lleva primero el codigo a ese estado y luego escribelo. Tambien hace falta revisarlo periodicamente: si el comando de compilacion cambio y el archivo no, el agente se atasca ahi cada vez: cuando cambies un comando, arregla este archivo en el mismo commit. |
Escribe esta clase de archivo dando por hecho que alguien de fuera puede leerlo. En un repositorio publico, cualquiera puede; y aun en uno privado, se transmite al proveedor del modelo en cuanto se lo entregas a un agente: no escribas nombres de host internos, como funciona tu autenticacion ni planes que aun no has anunciado. Hay ademas una propiedad de seguridad que conviene nombrar: un archivo de instrucciones es una entrada que cambia el comportamiento del agente; alguien de fuera que le anada una linea en un pull request puede dirigir lo que tus agentes hagan despues. En un repositorio que fusiona pull requests externos, pon siempre bajo revision los diffs de estos seis archivos: llaman menos la atencion que los cambios de codigo y su efecto es mas amplio. Y una nota operativa para cerrar: este archivo no termina cuando lo escribes; es algo que actualizas cuando el agente repite el mismo error. Cuando notes que das siempre la misma correccion, esa correccion es la linea que corresponde a este archivo.
📖 Cómo usar
-
1
Elige plantillaElige la más cercana entre 20+ presets
-
2
Ajusta si necesitasAbre "Edición personalizada"
-
3
Formato y descargaIndividual o zip
❓ Preguntas frecuentes
¿AGENTS.md vs CLAUDE.md?
¿Qué es Cursor MDC?
¿Si falta algo?
¿Seguridad?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.