# Cómo configurar CLAUDE.md en 2026: plantilla y 6 reglas > Una plantilla de CLAUDE.md lista para usar, 6 reglas para mantener vivo el archivo y un análisis de un archivo de trabajo de una empresa activa. Incluye citas oficiales de Anthropic. Source: https://ailoot.ai/blog/es/claude-md-template/ Canonical: https://ailoot.ai/blog/es/claude-md-template/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-126 Revision: sha256-00609baf2bf1149ea948c3b59bc03ba05a501502a4af26d99f05b07e80e3f9c9
Idea clave CLAUDE.md es un archivo de texto en la raíz de un proyecto que Claude Code lee al inicio de cada sesión. Sin él, el agente empieza desde cero cada vez: pasas 5-10 minutos diciendo: «Hola, estoy trabajando en este proyecto, este es mi público y este es mi estilo». Un archivo inicial compacto suele apuntar a 100–200 líneas; es una pauta de revisión, no un límite técnico. La plantilla contiene 6 secciones (descripción, herramientas, estructura, rutas a archivos, reglas e idioma) y se actualiza cada vez que Claude comete un error. Este artículo incluye una plantilla lista para usar, 6 reglas, un análisis de un archivo de trabajo de una empresa activa y una lista de verificación de 12 puntos.
Materiales sobre vibe coding: herramientas, casos prácticos y errores. [Guías de Ailoot](https://ailoot.ai/docs/).
[Guías de Ailoot](https://ailoot.ai/docs/)
## ¿Por qué necesitas CLAUDE.md y por qué Claude olvida el proyecto sin él?
Idea clave En Claude Code, cada chat nuevo empieza con el contexto vacío. CLAUDE.md es el único archivo que Claude carga automáticamente en cada sesión nueva. Sin él, el agente trabaja como un becario en su primer día: no sabe nada de tu empresa, tu estilo ni tus reglas. Con él, trabaja como un empleado en su segundo año.
Abres Claude Code el martes y explicas: «Estoy trabajando en este proyecto, estas son las herramientas, no hagas esto». Funciona. El jueves, ese mismo chat ya terminó, así que repites todo. El sábado, otra vez; el lunes, una vez más. Así es trabajar con un agente sin CLAUDE.md: cada ventana nueva es un becario que empieza de cero y al que tienes que repetir las mismas cosas una y otra vez. Antes pasaba 5-10 minutos escribiendo esta introducción en cada sesión. Los prompts se alargaban porque tenía que incluir todo el contexto manualmente. Y el resultado seguía siendo genérico: el agente no conocía a mi público, mi modelo económico ni mis principios.
Nota No es un problema de la memoria del modelo. Es la arquitectura. Claude Code empieza deliberadamente con un contexto limpio en cada sesión; de lo contrario, se mezclarían distintos proyectos del mismo ordenador. CLAUDE.md es el mecanismo que te permite decirle al agente qué debe cargar.
Con un CLAUDE.md vivo, desaparece la introducción. Todas las reglas que antes repetías en cada chat están en un solo archivo y aparecen automáticamente al inicio de cada sesión. El prompt se vuelve breve: «haz X», en lugar de «estoy trabajando en el proyecto Y, las herramientas son Z, no hagas A ni B y, por cierto, recuerda también C». Entonces desaparecen los errores repetidos. Cada error del agente es una razón para añadir una línea a CLAUDE.md. Después de un mes, tienes una «constitución del proyecto» viva y Claude deja de caer en las mismas trampas conocidas. Y hay una tercera capa: el agente deja de escribir en el vacío. A través de `CLAUDE.md`, dirijo a Claude a carpetas con contexto: dónde buscar información sobre el público, los precios y la marca. Sin estas indicaciones, el agente escribe «soluciones de alta calidad» sin conocer mi modelo económico, por lo que resultan abstractas, formularias y «como las de todo el mundo». ## ¿Qué es CLAUDE.md y en qué orden lo lee Claude?
Idea clave CLAUDE.md es un archivo de texto en formato Markdown. Claude Code lo busca en cuatro lugares a la vez: el nivel del sistema, el nivel del usuario, la raíz del proyecto y las notas locales. Los cuatro se cargan en el contexto al inicio de cada sesión. El nombre del archivo distingue entre mayúsculas y minúsculas: usa siempre `CLAUDE.md` en mayúsculas.
Anthropic describe CLAUDE.md así en su documentación oficial:
Los archivos CLAUDE.md son archivos Markdown que proporcionan a Claude instrucciones persistentes para tu proyecto, tu flujo de trabajo personal o toda tu organización. Se escriben en texto sin formato y Claude los lee al inicio de cada sesión.
— Anthropic, code.claude.com/docs/en/memory
Los cuatro lugares donde Claude Code busca CLAUDE.md, en orden creciente de prioridad: | Nivel | Ubicación | Propósito | |----|----|----| | **Organización** | `/Library/Application Support/ClaudeCode/CLAUDE.md` en Mac, `/etc/claude-code/CLAUDE.md` en Linux | Reglas que el administrador de la empresa distribuye a todo el equipo mediante MDM. Si trabajas por tu cuenta, no lo necesitas. | | **Usuario** | `~/.claude/CLAUDE.md` | Reglas personales aplicables a todos tus proyectos. «Responde siempre en el idioma preferido del usuario», «no uses rayas largas». | | **Proyecto** | `./CLAUDE.md` en la raíz del proyecto o `./.claude/CLAUDE.md` | Reglas para un proyecto específico: herramientas, estructura de carpetas y lógica de negocio. Este archivo se incluye en git. | | **Local** | `./CLAUDE.local.md` | Notas personales para este proyecto que no deben incluirse en git. Por ejemplo, experimentos temporales o preferencias personales que el equipo no necesita. | Los cuatro archivos se cargan en el contexto al mismo tiempo. Si las reglas entran en conflicto, Anthropic dice directamente en su documentación que no se sabe cuál prevalecerá; Claude puede elegir cualquiera de ellas al azar. Por eso es más sencillo mantener todo lo esencial en el CLAUDE.md del proyecto y evitar duplicados.
Consejo El nombre del archivo distingue estrictamente entre mayúsculas y minúsculas. Usa `CLAUDE.md` en mayúsculas y Claude lo leerá. No leerá `claude.md` ni `Claude.md`. Lo mismo se aplica a `CLAUDE.local.md`. Es un error típico entre quienes configuran Claude Code por primera vez: crean un archivo, escriben las instrucciones, se preguntan por qué no funciona y luego descubren que el nombre estaba en minúsculas.
Hay un detalle técnico del que casi nadie escribe, pero que explica muchos comportamientos extraños.
El contenido de CLAUDE.md se envía como un mensaje del usuario después del prompt del sistema, no como parte del prompt del sistema. Claude lo lee e intenta seguirlo, pero no hay garantía de que lo cumpla estrictamente.
— Anthropic, code.claude.com/docs/en/memory
En otras palabras, CLAUDE.md no es un «prompt del sistema» en sentido estricto. Es el primer mensaje del usuario que ve Claude. Por eso sus reglas son sugerencias firmes, no leyes. Si una regla necesita aplicarse de forma obligatoria, utiliza un hook probado para el evento que cubra, y permisos o aislamiento del entorno para el límite de acceso más amplio. Que un hook se ejecute automáticamente no hace completas sus comprobaciones. Más adelante explicaré el límite entre `hooks` y `CLAUDE.md`. ## ¿Cómo escribir un CLAUDE.md mínimo en 5 minutos (plantilla lista para usar)?
Idea clave Copia la plantilla, sustituye los campos entre corchetes y guárdala en la raíz del proyecto como `CLAUDE.md`. Basta para que Claude deje de empezar desde cero en cada sesión. Puedes ampliarla sobre la marcha siguiendo la regla: «después de cada error del agente, añade una línea».
A continuación tienes una plantilla que he probado en docenas de mis proyectos. Mantiene el archivo en torno a 80-120 líneas, dentro de la recomendación de Anthropic de intentar mantenerse por debajo de 200 líneas. Con esta plantilla, el agente ofrece los resultados más sensatos. ```markdown # [PROJECT NAME] - project navigation This document is the project map. Read it at the start of every session to understand where things are and how to work with them. ## What this project is **[NAME]** - [one sentence: what it is and who it’s for]. [1-2 sentences: what problem it solves and how]. Details are in `business/INDEX.md`. ## Reading order at the start of every session 1. `about-me/INDEX.md` - who I am and how I think 2. `business/INDEX.md` - what we do (product, audience, economics) 3. `CLAUDE.md` (this file) - repo rules, tools, navigation 4. Task area: the relevant file from `business/`, `plans/`, `mastery/` or the feature folder in the code Principle: layer 1 (about me) comes before layer 2 (business) for a reason. First, **who** is thinking, then **about what**. ## Repository structure [NAME]/ ├── CLAUDE.md ← this file, navigation ├── about-me/ ← digital projection of you (how you think, what you value) │ └── INDEX.md ├── business/ ← the business’s second brain │ ├── INDEX.md │ ├── audience/ ← customer profile │ ├── products/ ← products, prices │ ├── goals/ ← goals, metrics │ └── economics/ ← unit economics, revenue ├── plans/ ← technical plans (one plan = one feature) ├── retrospectives/ ← reflections after each session └── (project code) ### Where to find things | What you need | Where to look | |---|---| | Why we’re building the project, and for whom | `business/INDEX.md` | | Target customer, pains, desires | `business/audience/` | | Product, plans, prices | `business/products/` | | Goals and metrics | `business/goals/` | | Economics | `business/economics/` | | Technical plans | `plans/` | ## Tools [INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL]. ## Repo rules 1. Never hardcode dynamic data (prices, dates, figures) - get everything from files in `business/` and the LIVE marker. 2. Don’t publish without my explicit command. 3. Before `git push`, run `npm run build` and check that it builds without errors or warnings. 4. Add files by name with `git add`. Never use `git add .` or `git add -A`. 5. Don’t read `.env` in full. To check a variable, use `grep "^VAR=" .env`. ## Big features = a plan in `plans/` Any task lasting more than an hour must be written up as a plan in the `plans/` folder: 1. Filename: `YYYY-MM-DD-feature-name.md`. 2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`. 3. At the end of the plan, add a summary: whether it was fully implemented and what remains. ## End-of-feature cycle After each feature is complete, go through these 5 steps: 1. Find errors → prove them with an example → fix them. 2. What was missed (edge cases, input validation, error handling). 3. Is this a real problem in our project? Check `business/` and `plans/`. 4. Take a fresh look: reread the diff as if you’re seeing it for the first time. 5. Security review. Especially: personal data and third-party materials. ## End-of-session reflection In `retrospectives/YYYY-MM-DD_short-name.md`, record: 1. What the task was. 2. How it was solved. 3. Whether it was solved - yes / no / partially. 4. What could have been done better. 5. What was learned about the user or project. ## Language Always respond in the user’s preferred language. Use hyphens only, not em dashes. ``` Para que Claude complete automáticamente esta plantilla para tu proyecto, dale este prompt. Leerá el contexto y rellenará los campos entre corchetes:
Prompt: Completar CLAUDE.md para mi proyecto ``` Create a CLAUDE.md file at the project root using this template: [INSERT THE ENTIRE TEMPLATE FROM ABOVE] Proceed as follows: Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author. Fill in all the square-bracketed fields in the template based on what you find in those folders. If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options. Intenta mantener el CLAUDE.md resultante por debajo de 200 líneas. Si es más largo, revisa duplicados y mueve los procedimientos detallados a archivos enlazados. Conserva las reglas esenciales de planificación, reflexión y repositorio; después pruébalas en tareas representativas. Show me the final file and ask what should be revised. Always respond in the user’s preferred language. ```
Si todavía no tienes las carpetas `about-me/` y `business/`, no pasa nada. Claude te hará preguntas aclaratorias y preparará un CLAUDE.md mínimo con la información disponible. Puedes crear las carpetas más adelante, cuando sepas qué incluir en ellas. ## ¿Qué 6 reglas convierten CLAUDE.md en un documento vivo?
Idea clave Estas 6 reglas condensan la experiencia de docenas de proyectos. Transforman CLAUDE.md de «un archivo que creamos y olvidamos» en un documento de trabajo que Claude consulta en cada sesión.
### Regla 1. Mantenlo por debajo de 200 líneas Anthropic lo dice de forma concisa en su documentación oficial:
Procura que CLAUDE.md tenga menos de 200 líneas. Los archivos más largos consumen más contexto y reducen el cumplimiento de las instrucciones.
— Anthropic, code.claude.com/docs/en/memory
Un CLAUDE.md largo se vuelve contraproducente de dos maneras. Primero, consume tokens. Un archivo de instrucciones de 800 líneas se carga en cada ventana y usa varios miles de tokens de tu presupuesto en cada sesión. Con una suscripción Pro y un límite diario, eso reduce notablemente el número de sesiones disponibles. Segundo, el modelo empieza a ignorar las reglas. La documentación recomienda intentar mantenerse por debajo de 200 líneas para reducir el contexto consumido y mejorar el cumplimiento. No establece un punto de fallo brusco en la línea 201. Revisa la pertinencia, las contradicciones, los tokens cargados y los resultados reales antes de decidir qué trasladar a otros archivos.
Advertencia Si ya has llegado a 300-500 líneas, no te preocupes: divide el contenido entre carpetas. Pon las reglas detalladas sobre, por ejemplo, el sistema de diseño en `business/assets/brand-guidelines.md`. CLAUDE.md puede hacer referencia a ese archivo en una línea: «Al trabajar en la interfaz, consulta `business/assets/brand-guidelines.md`». El principio de organización es este: CLAUDE.md es un índice, no un libro.
### Regla 2. Termina cada sesión con una reflexión Escribe en CLAUDE.md: «Al final de cada sesión, registra lo que hiciste y aprendiste en `retrospectives/YYYY-MM-DD_*.md`». Cuando añades esta línea, Claude empieza a terminar cada sesión con una reflexión por su cuenta; no tienes que pedírselo. Por qué reflexionar: - Dos semanas después, puedes abrir una retrospectiva antigua y recordar por qué elegiste ese camino. - Cuando vuelves al proyecto un mes más tarde, tienes un mapa listo de las decisiones recientes. - Si trabajas en equipo, un compañero puede leer la retrospectiva y entender el estado actual en 2 minutos, sin una llamada. ### Regla 3. Crea un commit después de cada tarea completada Mi CLAUDE.md dice: «Después de cada tarea completada, crea un commit de git con un mensaje significativo». Claude empieza a dividir el trabajo en commits atómicos por su cuenta. Esto te aporta dos cosas. Primero, si algo falla, puedes revertir una operación, no «todo lo que hice hoy». Segundo, el historial de commits se convierte en un registro de trabajo que muestra qué cambió y en qué orden. ### Regla 4. Consulta siempre la carpeta `business/` Para cualquier tarea relacionada con clientes, productos o textos, el agente debe abrir primero `business/INDEX.md` y el archivo pertinente que se indique allí. Mi CLAUDE.md dice explícitamente: «Al trabajar en la interfaz o en textos, consulta primero `business/audience/avatar.md` y `business/assets/brand-guidelines.md`». Sin esta regla, Claude escribe textos con «el estilo general de un sitio web de calidad». Con ella, los textos siguen tu estilo y están dirigidos a tus clientes, sin usar las palabras que prohíbes. ### Regla 5. Añade una regla después de cada error del agente Esta es la regla principal para mantener vivo CLAUDE.md. Ejemplos de mi propio CLAUDE.md que añadí después de errores concretos: - «Nunca incluyas archivos WIP de otra persona con `git add .`: prepara los archivos por nombre». - «Antes de hacer push a `main`, comprueba `git log origin/main..main --oneline`: si no está vacío, no hagas push». - «No inventes valores: obténlos de `.env` o del código. Sobre todo las URL, los nombres de usuario y los tokens». Cada una de estas líneas registra un incidente concreto. Una vez, un agente incluyó en un commit la rama sin terminar de un compañero. Otra vez, incluí commits de otra persona que aún no se habían enviado. Y otra vez, un agente inventó una URL inexistente. Cada error se convierte en una regla y evita que volvamos a hacernos daño de la misma manera. ### Regla 6. Incluye la seguridad en `.claude/settings.json`, no en CLAUDE.md En CLAUDE.md puedes escribir «no toques `.env`», pero eso es una petición; Claude puede incumplirla porque CLAUDE.md se carga como un mensaje del usuario, no como una ley. Para la seguridad crítica, usa `.claude/settings.json`, donde puedes bloquear ciertos comandos de forma estricta. La lista de bloqueo que añado a cada proyecto nuevo: - `rm -rf` (eliminación recursiva de cualquier archivo). - Leer `.env` completo (`Read .env`). - `export` y `curl` en el mismo comando (un patrón para filtrar secretos al exterior). - `git push --force` sin aprobación explícita.
Advertencia La diferencia es sencilla: una regla en CLAUDE.md es un consejo que el agente puede incumplir. Una regla deny coincidente bloquea la acción cubierta en el flujo de permisos aplicable. No demuestra protección frente a comandos equivalentes, otras herramientas o un modo de permisos distinto. Mantén las reglas de seguridad críticas en `settings.json` y todo lo demás en CLAUDE.md.
Encuentra otras guías en [Ailoot](https://ailoot.ai/docs/).
[Guías de Ailoot](https://ailoot.ai/docs/)
## ¿Cómo está estructurado CLAUDE.md en una empresa activa (anatomía de un archivo de 280 líneas)?
Idea clave Voy a analizar la estructura de un archivo CLAUDE.md que se usa en un servicio en línea activo. El archivo tiene unas 280 líneas y 11 secciones. Mostraré qué contiene cada sección y por qué. No publicaré el texto real: contiene detalles operativos. Pero el marco puede aplicarse a cualquier empresa.
La mayoría de los ejemplos de CLAUDE.md que hay en línea son plantillas técnicas para desarrolladores: «Usa TypeScript», «No escribas pruebas de más de 50 líneas». Para un emprendedor, este tipo de CLAUDE.md no sirve: no cubre el aspecto empresarial. A continuación está la estructura de mi CLAUDE.md de trabajo. He eliminado las reglas y rutas específicas porque reflejan mis operaciones internas. Pero la estructura y la lógica de las secciones se pueden aplicar a cualquier proyecto: añade tus propias circunstancias y tendrás un archivo de trabajo. **1. Breve descripción del proyecto (15 líneas).** Qué hacemos, quién es el público y qué productos ofrecemos. No un resumen del sitio de marketing, sino un resumen para que el agente entienda «hacia dónde vamos». **2. Sobre mí (10 líneas).** Una referencia a la carpeta `about-me/`, una proyección digital de cómo pienso. Tono, valores, principios y palabras prohibidas. Cuando Claude escribe un texto «como yo», primero lee esta carpeta para que la voz coincida. **3. Estructura del repositorio (20 líneas).** Un árbol con comentarios: dónde está el código, dónde está el contexto empresarial, dónde están los planes y las reflexiones. Sin este mapa, Claude busca archivos a ciegas cada vez. **4. Tabla «Dónde encontrar las cosas» (25 líneas).** Rutas de «pregunta → archivo». Por ejemplo, en una agencia inmobiliaria podría decir: «necesitas las condiciones de la hipoteca → `business/products/mortgage.md`» o «necesitas el tono de voz para las publicaciones → `business/assets/voice.md`». Sustituye las referencias por tus propios archivos. Esta tabla es el núcleo de CLAUDE.md. Sin ella, el agente adivina qué archivo contiene la respuesta. Con ella, va directamente a la fuente. **5. Principios clave del proyecto (40 líneas, 10-15 puntos).** Esta sección crece poco a poco y es la que más esfuerzo exige. Cada punto registra un error concreto. Para una tienda en línea, por ejemplo, las reglas podrían ser «nunca fijes precios ni plazos de entrega en el código», «no publiques un producto sin una orden explícita» y «comprueba el estilo con el glosario de marca antes de publicar la ficha de un producto». Esta sección es la «constitución del proyecto». **6. Planificación operativa (20 líneas).** Una tabla de activadores que relaciona «frase del usuario → acción». Por ejemplo: «Cuando diga “planifica la semana”, abre `ops/monthly.md` y crea el archivo de la semana». Así Claude se convierte en un asistente de operaciones que entiende el contexto de las órdenes. **7. Herramientas (5 líneas).** Tecnologías. Brevemente y sin relleno. **8. Publicación (15 líneas).** Un proceso paso a paso para publicar cambios en producción: qué comandos ejecutar, en qué orden y qué comprobar. Antes lo explicaba cada vez. Ahora Claude lo sabe. **9-12. Seguridad (35 líneas).** Cuatro subsecciones separadas: reglas para trabajar con `.env`, acceso a la base de datos de producción, comandos seguros para demostraciones (grabaciones de pantalla, transmisiones, capturas, para no exponer tokens por accidente) y reglas para rotar secretos. **13. La carpeta `plans/` (10 líneas).** El estándar para los planes: nombre del archivo, estructura de las fases y qué incluir en el bloque de resumen. **14. La carpeta `retrospectives/` (5 líneas).** El estándar para las reflexiones: plantilla, nombre del archivo y contenido. **15. Datos de la base de datos activa (15 líneas).** Una regla para marcar los «datos recientes»: cuando un archivo indica que las cifras deben estar actualizadas, el agente las obtiene de la fuente en lugar de usar cifras antiguas. Así se evita que Claude use las cifras de ayer. **16. Idioma (3 líneas).** «Responde siempre en el idioma preferido del usuario. Usa guiones, no rayas largas». Unas 280 líneas en total. Supera el objetivo de concisión, pero no invalida el archivo. En este ejemplo siguió siendo útil; conservarlo debería depender del contexto medido y de pruebas con tareas representativas. Las tablas no consumen automáticamente menos tokens que la prosa.
Consejo La estructura que he desarrollado durante un año de trabajo no es un dogma. El marco es: descripción (1-2 secciones), estructura y rutas (2-3 secciones), reglas y principios (1 sección extensa), procedimientos operativos (2-3 secciones específicas para tu empresa) y detalles menores (idioma, contactos). Complétalo con detalles específicos de tu empresa. La regla principal: cada sección debe responder a la pregunta «¿Cometería Claude un error sin esto?». Si no, elimínala.
## ¿Qué hace el comando `/init` y por qué no es suficiente?
Idea clave El comando `/init` de Claude Code crea automáticamente un CLAUDE.md básico al analizar el proyecto y enumerar herramientas y comandos de compilación. Es un buen punto de partida, pero sin contexto empresarial ni principios, el archivo es técnico y genérico. Usa `/init` como primer paso y luego complétalo a mano.
Anthropic describe el comando así en su documentación:
Ejecuta /init para generar automáticamente un CLAUDE.md inicial. Claude analizará tu código y creará un archivo con comandos de compilación, instrucciones de pruebas y convenciones del proyecto detectadas.
— Anthropic, code.claude.com/docs/en/memory
Qué hace bien `/init`: - Identifica las herramientas a partir de `package.json`, `Cargo.toml` y `pyproject.toml`. - Enumera comandos de compilación y pruebas. - Detecta convenciones en archivos existentes (`.eslintrc`, `.prettierrc`). - Detecta reglas existentes de Cursor (`.cursorrules`, `.cursor/rules/`) y de Copilot, e incorpora las partes relevantes. Detecta `AGENTS.md` en el modo `CLAUDE_CODE_NEW_INIT=1`. Qué no hará `/init`: - No sabrá quién es tu cliente. - No incluirá palabras prohibidas para los textos. - No añadirá reglas sobre errores del agente (porque todavía no habrá habido ninguno). - No creará una tabla «dónde encontrar las cosas» para la estructura de tu empresa. Así que el flujo de trabajo adecuado es: 1. ### Ejecuta /init en Claude Code Obtendrás un CLAUDE.md inicial de 30-50 líneas con herramientas y comandos. Esta es la base técnica. 2. ### Añade la plantilla de este artículo encima Usa la sección «Un CLAUDE.md mínimo en 5 minutos». Añade secciones de navegación, rutas y principios. 3. ### Rellena los campos entre corchetes Dale a Claude el prompt «lee mi proyecto y completa la plantilla». Si aún no existen las carpetas `business/` y `about-me/`, Claude te hará preguntas aclaratorias. 4. ### Haz una prueba de estrés Dile a Claude: «Lee mi CLAUDE.md y encuentra 10 ambigüedades que podrían hacer que tú, como agente, lo malinterpretaras». Obtendrás una lista de correcciones. 5. ### Después, convive con el archivo Añade una línea después de cada error del agente. En un mes, tendrás un CLAUDE.md vivo adaptado a tu empresa. Prompt para el paso cuatro:
Prompt: Prueba de estrés de CLAUDE.md ``` I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it. Your task is to stress-test it. Find 10 reasons we could potentially fail: where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it where there are gaps that would force you to make things up where rules contradict one another where I overestimate how much can be done in one day where I underestimate things (this is even worse) Don’t hold back. Criticize it harshly. I want to find these issues now, not in production. At the end, give me a list of specific changes: what to change and how, so these problems don’t happen. ```
## CLAUDE.md vs AGENTS.md vs MEMORY.md: ¿quién lee qué en 2026?
Idea clave A menudo se confunden tres archivos parecidos. CLAUDE.md contiene las reglas del proyecto que escribes tú y Claude Code lee en cada sesión. AGENTS.md es un estándar universal para otros agentes (Codex, Cursor, Copilot) y, desde septiembre de 2026, Claude Code también lo lee si el proyecto no tiene CLAUDE.md. MEMORY.md contiene notas automáticas que Claude escribe para sí mismo sobre tus hábitos. Los tres pueden coexistir sin entrar en conflicto.
| Archivo | Quién lo escribe | Quién lo lee | Cuándo se carga | |----|----|----|----| | **CLAUDE.md** | Tú, manualmente | Claude Code (de forma nativa) | Al inicio de cada sesión | | **AGENTS.md** | Tú, manualmente | Codex CLI, Cursor, GitHub Copilot CLI, Gemini CLI y, desde la versión 2.1.277, Claude Code si el proyecto no tiene CLAUDE.md | Al inicio de cada sesión | | **MEMORY.md** | El propio Claude Code | Claude Code (de forma nativa) | Al inicio de cada sesión, las primeras 200 líneas (o 25 KB, lo que sea menor) | La pregunta principal que desconcierta a los recién llegados es: **¿Claude Code lee `AGENTS.md`?** Antes de septiembre de 2026, la respuesta era «no»: la documentación de Anthropic recomendaba crear un CLAUDE.md que importara AGENTS.md. Desde la versión 2.1.277 (publicada el 18 de septiembre de 2026), Claude Code lee AGENTS.md por sí mismo, pero solo si no hay CLAUDE.md, `.claude/CLAUDE.md` ni `CLAUDE.local.md` en la carpeta de trabajo o por encima de ella.

Claude Code puede leer AGENTS.md como instrucciones del proyecto, por lo que un repositorio ya configurado para otros agentes funciona sin CLAUDE.md, una importación ni configuración.

— Anthropic, https://code.claude.com/docs/en/memory#agents-md
Si el proyecto tiene un CLAUDE.md, Claude Code lee solo ese archivo de manera predeterminada y omite AGENTS.md. Puedes cambiarlo en `/config`, en Project instructions: por ejemplo, el ajuste `claude-md-and-agents-md` hace que lea ambos archivos. Otra opción funciona en cualquier versión: añadir una importación a CLAUDE.md: ```markdown @AGENTS.md ## Claude Code Additional rules for Claude Code that other agents don’t need. ``` La sintaxis `@filename` importa otro archivo. Claude lo lee y lo carga en el contexto junto con CLAUDE.md. La importación no hace que el archivo se lea dos veces, incluso si Claude Code puede leer AGENTS.md por sí mismo. **Cuándo necesitas AGENTS.md.** Si trabajas en paralelo con Claude Code y Codex CLI, Cursor o Copilot, crea un AGENTS.md como única fuente de verdad, pon `@AGENTS.md` en CLAUDE.md y añade encima las reglas específicas de Claude. Si no hay reglas de ese tipo, no necesitas crear CLAUDE.md: desde la versión 2.1.277, Claude Code leerá AGENTS.md por sí mismo. Si solo trabajas con Claude Code, no necesitas AGENTS.md; usa un único CLAUDE.md. Para conocer todas las opciones paso a paso, consulta [la guía para usar AGENTS.md y CLAUDE.md en un mismo proyecto](https://ailoot.ai/blog/es/agents-md-claude-md-one-instruction-file/). **¿Qué es MEMORY.md?** Desde una actualización reciente, Claude Code guarda automáticamente notas sobre ti en `~/.claude/projects//memory/MEMORY.md`. Incluyen hábitos de conversación («el usuario prefiere respuestas breves»), frases recurrentes («prohibió los emojis en el código») y observaciones de comportamiento («trabaja en macOS, usa zsh»). Es un sistema de memoria separado, no CLAUDE.md. No lo escribes a mano; Claude lo crea a partir de tus conversaciones. Si MEMORY.md contiene algo que debería convertirse en una regla, pásalo a CLAUDE.md. Si contiene algo innecesario o incorrecto, puedes eliminarlo manualmente; es un archivo de texto.
Nota Para ver qué se carga al inicio de una sesión, escribe `/memory` en Claude Code. Muestra el contenido de CLAUDE.md, MEMORY.md y otros archivos cargados. Es útil cuando Claude se comporta de manera extraña: abre `/memory` y busca la regla que podría haberlo provocado.
## ¿Qué tamaño resulta útil para CLAUDE.md y cómo revisar un archivo largo?
Idea clave Los archivos de instrucciones largos consumen más contexto y pueden dificultar el cumplimiento de las reglas pertinentes, especialmente si hay duplicados o contradicciones. Anthropic recomienda intentar mantenerse por debajo de 200 líneas. Esa recomendación no es un límite técnico ni una predicción universal del número de reglas que seguirá el agente.
En cada ventana de Claude Code se cargan varias capas en el contexto: el prompt del sistema de Anthropic (se estima que contiene decenas de miles de tokens), tu CLAUDE.md, los archivos importados con `@`, MEMORY.md, el historial del chat actual y el contenido de los archivos que Claude abre. Todo esto debe caber en el contexto del modelo (200K tokens para Sonnet, 1M para Opus). Cuanto más grande sea CLAUDE.md, menos espacio queda para el trabajo actual. Un archivo de 1,000 líneas tiene unos 8,000 tokens y se repite en cada sesión. Con una suscripción Pro (según mi experiencia, unos 10-12 prompts «intensos» al día), eso reduce tu capacidad en una cuarta parte. El coste es solo una preocupación. El cumplimiento puede empeorar con instrucciones largas, irrelevantes o contradictorias; no existe un número universal de instrucciones que se sigan de forma fiable. Prueba varias tareas representativas que ejerciten las reglas críticas, registra los fallos y compara el comportamiento tras una edición acotada.
Los archivos CLAUDE.md sobrecargados hacen que Claude ignore tus instrucciones reales.
— Anthropic, code.claude.com/docs/en/best-practices
Esta es una regla práctica para el tamaño: - **80-120 líneas**: un punto de partida cómodo para un mapa conciso del proyecto, sin garantía de porcentaje de cumplimiento. - **150-200 líneas**: una señal útil para revisar la pertinencia y trasladar procedimientos detallados a archivos enlazados. - **200-300 líneas**: examina tokens, duplicados y resultados de tareas; el ejemplo empresarial de 280 líneas anterior puede seguir funcionando bien. - **400+ líneas**: una buena razón para revisar con atención, no una prueba de que el archivo sea inutilizable. Conserva las restricciones esenciales y mueve detalles solo después de comprobar enlaces y reglas. El número de líneas por sí solo no demuestra éxito ni fracaso. Tras editar, repite las mismas tareas representativas y verifica las reglas importantes, en lugar de asignar un porcentaje de cumplimiento inventado.
Advertencia Si tu CLAUDE.md ha crecido demasiado, no lo reorganices a mano. Dale a Claude este prompt: «Lee CLAUDE.md y evalúa cada línea con esta pregunta: “Si se eliminara esta línea, ¿cometería un error el agente?”. Devuelve una lista de líneas que se pueden eliminar sin pérdida, junto con una justificación». Eliminará lo que objetivamente no sirve.
Anthropic propone una prueba directa en su documentación:
Para cada línea, pregúntate: «Si la elimino, ¿Claude empezará a cometer errores?». Si no, bórrala.
— Anthropic, code.claude.com/docs/en/best-practices
Aplica esta prueba a cada línea. Si la respuesta es «lo seguiría haciendo bien», elimina la línea. CLAUDE.md no es el lugar para documentar, registrar decisiones ni exponer una filosofía. Solo debe contener las reglas que el agente necesita para no meter la pata. ## ¿Qué 7 errores vuelven inútil CLAUDE.md?
Idea clave Estos son siete errores comunes que veo con regularidad en los archivos CLAUDE.md de otras personas. Cada uno es una razón para limpiar el archivo metódicamente. La mayoría son variaciones de un mismo problema: intentar convertir CLAUDE.md en un «documento universal del proyecto» en vez de mantenerlo como una herramienta de trabajo para el agente.
### Error 1. «Sé un buen ingeniero» El error más común. La gente escribe deseos generales en CLAUDE.md: «escribe código limpio», «sigue las mejores prácticas», «piensa como un ingeniero sénior». Estas palabras no significan nada. Claude ya escribe «código limpio» en términos generales. Estas líneas ocupan contexto sin influir en ninguna decisión. Sustituye «escribe código limpio» por «usa sangría de 2 espacios», «no uses `any` en TypeScript» o «las funciones no deben superar las 30 líneas». Específico y verificable. ### Error 2. Duplicar lo que Claude ya sabe Descripciones de convenciones lingüísticas estándar («en JavaScript, las funciones son ciudadanos de primera clase», «TypeScript tiene tipado estático»). Explicaciones de cómo funcionan npm, git o docker. Claude aprendió todo esto durante el entrenamiento. Duplicarlo en CLAUDE.md no aporta nada; solo consume tu contexto. ### Error 3. Instrucciones largas paso a paso dentro de CLAUDE.md Instrucciones largas sobre «cómo desplegar el proyecto», «cómo escribir una migración de base de datos» o «cómo configurar un componente nuevo». Docenas de líneas paso a paso. Este no es el lugar para instrucciones largas paso a paso. Es para reglas de una sola línea. Pon las instrucciones largas en `skills/` (un mecanismo independiente de Claude Code que se carga cuando hace falta) o en `docs/`. En CLAUDE.md, usa un enlace de una línea: «Al crear una migración, abre `docs/migrations.md`». ### Error 4. Reglas que ya comprueba un analizador de código automático «Usa punto y coma», «no dejes importaciones sin usar», «no uses `var`». ESLint, Prettier y Biome detectan todo esto: son linters (herramientas automáticas de revisión de código). Un linter es determinista: se ejecuta, encuentra un error y lo corrige. Una regla de CLAUDE.md es probabilística; el agente podría olvidarla. No hace falta duplicarla: es más fácil configurar el linter. ### Error 5. Secretos en CLAUDE.md He visto contraseñas de cuentas de prueba, tokens de API de sandbox y enlaces a paneles de administración con autenticación. Todo estaba en un archivo incluido en git y cargado en el contexto del modelo de Anthropic. Nunca. Los secretos deben ir en `.env`, que se incluye en `.gitignore`. Como mucho, CLAUDE.md debería decir: «No leas `.env` completo; usa `grep` para consultar una variable específica». ### Error 6. Un archivo de más de 500 líneas que sirve de cajón de sastre y no se limpia desde hace seis meses CLAUDE.md ha crecido, duplica la mitad de `docs/`, se contradice en varios lugares y nadie recuerda qué contiene. El agente empieza a ignorar la mayor parte. El equipo se queja de que «Claude no sigue las instrucciones» y añade más reglas, lo cual empeora la situación. Señales de que CLAUDE.md está abandonado: más de 300 líneas, reglas repetidas en distintas secciones, enlaces obsoletos a archivos que ya no existen y notas «históricas» como «en 2024 decidimos hacerlo así, pero después cambiamos de opinión». La solución: cada dos semanas, pide a Claude que lo revise con la prueba de Anthropic: «Si se eliminara esta línea, ¿cometería un error el agente?». Elimina todo aquello para lo que la respuesta sea «no». ### Error 7. Crear CLAUDE.md y olvidarse de él Este es el error opuesto al anterior. Se preparó el archivo una vez, hace dos meses, y no se ha vuelto a tocar. Mientras tanto, las herramientas han cambiado, se han añadido carpetas y han surgido nuevos errores de agentes. CLAUDE.md no sabe nada de todo eso porque nadie lo ha actualizado. Una señal clara: repites la misma instrucción en cada sesión. «No hagas X», «no toques Y», «recuerda Z». Si la has repetido más de dos veces, la regla pertenece a CLAUDE.md, no a tu memoria.
[Guías de Ailoot](https://ailoot.ai/docs/)
## ¿Cómo hacer que CLAUDE.md aprenda por sí mismo con una regla de «actualización al final de la sesión»?
Idea clave La técnica principal que convirtió mi CLAUDE.md de documento en herramienta viva fue añadir una regla: «Al final de cada sesión, comprueba si has aprendido algo nuevo sobre el usuario o sobre cómo trabajar con él que no esté en CLAUDE.md, y añade una línea». En dos meses, el archivo empezó a acumular reglas individuales sin un proceso aparte.
Mi CLAUDE.md tiene una sección breve: ```markdown ## Self-learning At the end of every session, check: - Have I learned anything new about the user or how to work with them? - Did I break any rule that should now be recorded? If so, create or update a file in `about-me/feedback/` in this format: Rule (one-line rule) → Why (why it was added) → How to apply (when it applies). I don’t write the rules by hand - I say, “not like that, because this is how,” and you put it into a file. ``` Después de añadir esta sección a CLAUDE.md, Claude empezó a preguntar al final de cada sesión: «¿Hay algo nuevo que merezca la pena registrar?». Si lo había, proponía un borrador de regla, yo lo aclaraba y se creaba un archivo. Después de dos meses de trabajar así, tengo más de dos docenas de archivos en `about-me/feedback/`: reglas aprendidas a partir de errores concretos. Cada archivo ocupa una página y sigue el formato Regla → Por qué → Cómo. La carpeta se convirtió en una «segunda memoria» que registra mis preferencias y tabúes personales. Cada error deja de repetirse porque se convierte en una regla, y las reglas se acumulan y refuerzan unas a otras. Después de seis meses, Claude conoce mi proyecto mejor de lo que yo lo recuerdo tras una pausa de un mes. ## ¿Cómo añadir reglas legales, de marketing y operativas a CLAUDE.md?
Idea clave Las pautas técnicas en CLAUDE.md son solo la mitad de la historia. La otra mitad son las reglas empresariales: expresiones prohibidas por requisitos legales, formato de los textos de marca para canales externos y hábitos operativos sobre cómo trabaja el equipo semana a semana. Cuando CLAUDE.md cubre ambos aspectos, Claude se convierte no solo en programador, sino también en editor y asistente de operaciones.
Para la mayoría de los equipos, CLAUDE.md es un documento puramente técnico: herramientas, comandos de compilación y convenciones de programación. Es útil, pero solo representa un tercio del valor. Cuando un emprendedor mantiene CLAUDE.md, tiene sentido añadir secciones empresariales. Tres son las más importantes: ### Reglas legales (para sectores regulados) Si publicas textos en un sector regulado (finanzas, medicina, publicidad de medicamentos o productos infantiles), las palabras prohibidas tienen peso legal y deben figurar en CLAUDE.md como reglas explícitas. No en la cabeza de alguien ni en una captura de pantalla de un editor: en un archivo que el agente ve en cada sesión. Ejemplo para un proyecto fintech sin licencia bancaria: Nota editorial: lo siguiente muestra el formato de una regla interna para un proyecto específico. No constituye un permiso universal para usar los términos enumerados: que una afirmación sea aceptable depende de la legislación aplicable y de la situación de la empresa. > 🚨 CRÍTICO: está prohibido usar terminología financiera. En los materiales dirigidos a clientes, no uses «depósito», «rentabilidad garantizada» ni «producto de inversión». Usa «cuenta de ahorro», «rentabilidad prevista» y «producto de tasa variable». El motivo son los requisitos legales aplicables a la publicidad de servicios financieros de este proyecto. Este bloque en CLAUDE.md hace algo sencillo: cada vez que pides a Claude que escriba un texto para clientes, el agente lo contrasta con estas prohibiciones. Sin la regla, las palabras prohibidas aparecen en una de cada tres campañas. Con ella, te olvidas de que existen. El mismo enfoque funciona para: - Proyectos médicos (no afirmar que algo «trata» o «cura»). - Publicidad de medicamentos (no afirmar que son «los más eficaces»; incluir las advertencias obligatorias). - Cualquier sector regulado con normas publicitarias propias. ### Estilo de marketing y formato de los textos Si publicas textos con regularidad (redes sociales, boletines o sitios web), merece la pena documentar el formato en un párrafo de CLAUDE.md. Este es un ejemplo de lo que podría escribir una persona influyente o una agencia que gestiona un canal de mensajería: > Al redactar publicaciones para el canal, consulta `style/posts.md`. Usa los marcadores de formato permitidos por el canal y evita los caracteres especiales «peligrosos». Termina con una CTA que lleve una etiqueta UTM según esta convención: `utm_source=&utm_medium=&utm_campaign=`. Antes Claude escribía publicaciones con «el estilo general de un sitio web de marketing». Ahora sigue tu formato, utiliza tus UTM y evita que se note que el texto está escrito por una IA. ### Hábitos operativos Tablas de activadores. Cuando dices una frase concreta, el agente sabe qué archivos abrir y qué acciones ejecutar. Aquí tienes un ejemplo para un equipo que planifica por semanas: > «Planifica la semana» → abre `ops/monthly.md`, crea `YYYY-WNN.md` en la misma carpeta y mueve las tareas de `ops/backlog.md` a los días correspondientes. «¿Qué hay en la lista de tareas pendientes?» → lee `ops/backlog.md` y muéstrala como una lista. «Cierra la semana» → completa la sección «Resumen semanal» del archivo de la semana actual. Con tablas como estas, Claude pasa de ser un «asistente que escribe código» a un «operador» que conoce la rutina de tu empresa. Cada lunes digo «planifiquemos la semana» y Claude abre los archivos correctos, lee los objetivos mensuales y sugiere cómo dividir el trabajo.
Nota Las pautas específicas de tu empresa en CLAUDE.md tienen sentido cuando ya tienes una carpeta `business/` con información concreta sobre tu público, tus productos y tus objetivos. Si no la tienes, crea primero `business/` y después añade referencias a ella en CLAUDE.md. De lo contrario, tendrás instrucciones que apuntan a ninguna parte.
## ¿Cómo revisar tu CLAUDE.md con una lista de verificación de 12 puntos en 5 minutos?
Idea clave Revisa tu CLAUDE.md actual con esta lista. Cada punto lleva 30 segundos. Si respondes «no» cinco veces o más, el archivo necesita una limpieza.
1. **Tamaño.** ¿Es conciso, con unas 200 líneas como objetivo de revisión y no como límite de aprobado o suspenso? 2. **Nombre.** ¿Se llama exactamente `CLAUDE.md`, con mayúsculas, y no `claude.md`? 3. **Ubicación.** ¿Está en la raíz del proyecto o en `./.claude/CLAUDE.md`? 4. **Descripción del proyecto.** ¿Las primeras 5 líneas dejan claro qué es el proyecto y a quién va dirigido? 5. **Herramientas.** ¿Se enumeran explícitamente las tecnologías y sin relleno? 6. **Estructura.** ¿Hay un diagrama del repositorio con explicaciones? 7. **Rutas.** ¿Hay una tabla de «pregunta → archivo» que indique dónde encontrar respuestas? 8. **Principios.** ¿Hay una sección con reglas que empiecen por «nunca» y «siempre»? 9. **Especificidad.** ¿Se puede verificar cada regla? («Usa 2 espacios», no «escribe con elegancia».) 10. **Actualización automática.** ¿Hay una regla para «comprobar qué añadir al final de la sesión»? 11. **Reflexión.** ¿Hay una regla para «registrar el resumen de la sesión en `retrospectives/`»? 12. **Seguridad.** ¿Las prohibiciones críticas (`.env`, `rm -rf`) también están en `.claude/settings.json`? Si has respondido «no» más de cinco veces, abre Claude y dale este prompt:
Prompt: Revisar CLAUDE.md según la lista de verificación ``` Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix. Checklist: Lo bastante compacto para la tarea; revisar en torno a 200 líneas sin tratarlo como un límite estricto Descripción del proyecto in the first 5 lines Tools listed explicitly Repository structure diagram included “Question → file” table included Principles section with rules included Every rule is specific and verifiable “Update at the end of the session” rule included “Reflect at the end of the session” rule included Critical prohibitions included in .claude/settings.json No duplicates of the same rule in different sections No dangling links to files that no longer exist After the audit, give me a list of specific changes that will make the file living. ```
## ¿Qué deberías usar después de CLAUDE.md: Plan Mode, Skills o subagentes?
Idea clave CLAUDE.md es la base. Cuando funcione, tendrás disponibles los siguientes niveles: Plan Mode (hacer que Claude planifique primero y actúe después), Skills (trasladar el conocimiento que se usa con poca frecuencia de CLAUDE.md a archivos separados) y subagentes (tareas aisladas en sus propios contextos).
CLAUDE.md es la base. Cuando funcione, puedes añadir tres mecanismos de Claude Code que se refuerzan entre sí. **Plan Mode.** Un modo en el que Claude crea primero un plan de cambios, espera tu aprobación y solo entonces empieza a trabajar. Actívalo con Shift+Tab o el comando `/plan`. Aborda el principal problema del vibe coding: «Le pedí a Claude que arreglara una cosa y reescribió la mitad del proyecto». Eso no pasará en Plan Mode: verás el plan antes de que el agente toque ningún archivo. **Skills.** Archivos `.md` independientes en la carpeta `.claude/skills/` que contienen conocimientos para un tipo concreto de tarea. Por ejemplo, una skill sobre «cómo escribir una migración de base de datos» contiene un procedimiento específico, una plantilla y ejemplos. Ese conocimiento no está en CLAUDE.md porque es demasiado extenso. Pero cuando Claude se encuentra con una tarea como «escribir una migración», carga la skill pertinente y la sigue. **Subagentes.** Cuando una tarea requiere mucho contexto (por ejemplo, revisar una funcionalidad extensa), Claude puede iniciar un subagente independiente con su propio contexto limpio. El subagente hace el trabajo y devuelve el resultado sin saturar el contexto del chat principal. Los tres mecanismos usan CLAUDE.md como punto de entrada: lo leen al comenzar su trabajo para entender el contexto del proyecto. Por eso estas funciones también funcionan mal sin un CLAUDE.md vivo. Primero la base; después, las capas superiores. **Siguiente paso.** Crea un archivo `CLAUDE.md` en la raíz del proyecto, copia la plantilla del principio de este artículo y completa los campos entre corchetes con el prompt auxiliar. Después, convive con el archivo: convierte cada error del agente en una línea nueva. Después de dos o tres semanas, CLAUDE.md deja de ser «un documento que escribimos y olvidamos» y se convierte en algo que Claude consulta en cada sesión. Si quieres crear un marco completo alrededor de `CLAUDE.md` —una carpeta `business/` para un segundo cerebro, una carpeta `about-me/` para una proyección digital de ti, skills básicas y un Plan Mode configurado—, usa los pasos y ejemplos de este artículo. [Guías de Ailoot](https://ailoot.ai/docs/).
### Fuentes - [Anthropic - Claude Code Memory](https://code.claude.com/docs/en/memory) - documentación oficial sobre CLAUDE.md, MEMORY.md y la jerarquía de carga - [Anthropic - Best Practices](https://code.claude.com/docs/en/best-practices) - reglas para redactar un CLAUDE.md eficaz y la prueba «¿al eliminar esto haría que Claude cometiera errores?» - [Anthropic Support - Give Claude Context](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts) - guía de soporte para trabajar con contexto - [Guías de Ailoot](https://ailoot.ai/docs/) - documentación.
[Seguir leyendo con Ailoot](https://ailoot.ai/).
[Seguir leyendo con Ailoot](https://ailoot.ai/)
[Seguir leyendo con Ailoot](https://ailoot.ai/)
## Preguntas sobre CLAUDE.md ### ¿Un archivo CLAUDE.md deja de ser válido después de 200 líneas? No. La recomendación es un objetivo de concisión, no un límite de lectura ni un punto de fallo garantizado. Revisa duplicados, contradicciones y contexto cargado; prueba las reglas importantes en tareas representativas. El ejemplo de 280 líneas del artículo requiere la misma evaluación. ### ¿Qué debería sacar de un CLAUDE.md que sigue creciendo? Traslada procedimientos detallados, referencias largas e historial de decisiones a documentos o skills adecuados. Conserva en el archivo de entrada datos concisos del proyecto, restricciones esenciales y enlaces claros. Repite tareas reales después de editar para comprobar que siguen funcionando la navegación y las reglas críticas. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.