¿Alguna vez la IA te ha dado respuestas raras o ha cometido errores absurdos? Puede que esté ahogándose en contexto. Como cuando preguntas a tu hijo qué ha pasado y te suelta todo lo que le ha pasado en el último mes: acabas más perdido tú que él. (Y quizás sea esto lo que prentede :P)
TL;DR
No entierres a tu agente en datos/contexto inútiles. Déjale encontrar y usar estrictamente lo que necesita, para que no se distraiga. El patrón para descubrimiento progresivo en archivos mdc es simple:
- Un archivo índice ligero (
alwaysApply: true) con comandos, estructura y enlaces a donde descubrir la información necesaria- Archivos especializados (
alwaysApply: false) con reglas detalladas, cargados mediante globs- Empieza ‘todo en uno’ y divide cuando empiecen a soltarse las costuras
El descubrimiento progresivo (progressive disclosure) es un principio de diseño donde muestras a los agentes de IA solo la información que necesitan en cada momento, revelando detalles conforme se vuelven relevantes. En el sistema de reglas de Cursor, esto significa estructurar tus archivos .cursor/rules/ de modo que las reglas ligeras y esenciales se carguen siempre, mientras que la documentación detallada se carga bajo demanda —por ejemplo, solo cuando trabajas con ciertos tipos de archivo.
El Problema: Sobrecarga de Contexto
Cuando tienes un repo de código grande (múltiples proyectos, transformaciones SQL, esquemas complejos…), cargar toda la documentación en cada conversación con la IA desperdicia tokens. Y aunque suene contraintuitivo, demasiado contexto da peores resultados: ralentiza el modelo, entierra los detalles importantes en ruido, y fuerza al modelo a adivinar qué es relevante. Conclusión: Una pregunta corta y enfocada con solo la info relevante suele obtener mejor respuesta que una larga y vaga con todo adjunto “por si acaso”.
Ejemplo: Un agente trabajando en un cambio simple de SQL no necesita la sintaxis detallada de anotaciones de esquema —a menos que haya un cambio de esquema. En un banco, un agente descubriendo el mejor producto de inversión para un tipo de cliente probablemente no necesita tener en cuenta información sobre seguros de hogar.
La Solución: Carga Inteligente de Reglas
La clave detrás del descubrimiento progresivo en reglas son los archivos índice que actúan como ayudas de navegación, para organizar y trocear los volcados de documentación. Tu índice siempre-cargado debería responder tres preguntas:
- “¿Qué puedo hacer?” (comandos)
- “¿Cuáles son las reglas críticas?” (estilo, convenciones)
- “¿Dónde encuentro los detalles?” (punteros a archivos especializados)
Todo lo demás va en archivos especializados con los globs apropiados.
Mi enfoque: empieza con un archivo de reglas único y pide a Cursor -esto en realidad funciona con cualquier herramienta de IA- que lo divida cuando empieces a sospechar que los agentes están recibiendo información que no necesitan. Lo notarás en el % de usage limit subiendo como la espuma… o incluso puedes preguntarle a la IA. No descartes preguntar.
Un Ejemplo Real
Digamos que tienes un proyecto de transformación de datos con código Scala, SQL y definiciones de esquema. Tu estructura .cursor/rules/ podría verse así:
Siempre Cargado (Archivo Índice)
.cursor/rules/myproject.mdc
—
description: Project system index – Points to specialized rules globs: myproject/**/*
alwaysApply: true
—
# My Project System
⚠️ **This file is an index. Core rules have been split for efficiency.**
## Quick Reference
**Detailed documentation** (loaded on-demand):
– **Schemas & Annotations**: `.cursor/rules/myproject.schemas.mdc`
– **Testing**: `.cursor/rules/myproject.testing.mdc`
– **Transformations**: `.cursor/rules/myproject.transformations.mdc`
—
## Essential Quick Commands
“`
…
“`
## File Structure
“`
myproject/
├── schema/ # Schema definitions
├── src/main/
│ ├── transforms/ # Data transformations
│ └── validations/ # Validation rules
└── src/test/
└── specs/ # Test specifications
“`
## Code Style Rules
**ASCII-only in code files:**
– NEVER use non-ASCII characters (→, •, é, ñ, etc.) in code files
– Non-ASCII allowed ONLY in `.md` documentation
– Use ASCII alternatives: `->` instead of `→`, `-` instead of `•` —
For detailed information, Cursor will automatically load the relevant specialized rule file based on the files you’re working with.
Tamaño: pequeño. Justo lo suficiente para empezar.
Cargado Bajo Demanda (Archivos Especializados)
Cuando editas archivos de esquema, el archivo mdc específico mencionado arriba (.cursor/rules/myproject.schemas.mdc) entra en acción:
---
description: Schema definitions and annotations (on-demand)
globs:
- myproject/**/schema/*.avdl
- myproject/**/*.avdl
alwaysApply: false
---
# Schema Definitions
## Core Concept Each `record` defines a table...
[detailed schema documentation here - could be 100+/200+ lines]
Y también necesitarás los archivos correspondientes para:
- .cursor/rules/myproject.testing.mdc — sintaxis de tests, reglas de validación (~160 líneas)
- .cursor/rules/myproject.transformations.mdc — patrones, estrategias de particionado (~90 líneas)
Todos con alwaysApply: false y los globs adecuados.
Cómo Funciona en la Práctica
Usando el último ejemplo donde he aplicado descubrimiento progresivo:
Antes (monolítico):
- Tenía un archivo de reglas de 400+ líneas, siempre cargado, independientemente de la tarea
- Uso una configuración multi-agente, donde cada agente veía detalles de anotaciones de esquema cuando escribía SQL / el agente veía reglas de particionado de transformaciones cuando escribía tests
Después de aplicar descubrimiento progresivo, tenía 4 archivos:
├── myproject.mdc (59 lines, always loaded)
├── myproject.schemas.mdc (104 lines, schema files only)
├── myproject.testing.mdc (156 lines, testing only)
└── myproject.transformations.mdc (93 lines, SQL only)
Las cuentas:
- En lugar de cargar siempre todo (400 líneas)
- ¿Agente editando SQL? Carga ~152 líneas (índice + transformaciones)
- ¿Editando esquema? Carga ~163 líneas (índice + esquemas)
- ¿Editando tests? Carga ~215 líneas (índice + testing)
Reglas Personales, Mismo Patrón
Este enfoque no se limita a reglas compartidas de proyecto. Uso la misma estructura en mi directorio .cursor/local/rules/ para flujos de trabajo personales. Por ejemplo, digamos que tengo un archivo de documentación de PR que uno de mis multi-agentes (el documentador) usa para crear descripciones de PR concisas pero completas que escribe en una carpeta local/docs:
---
description: PR summary and documentation formatting
globs:
- myproject/**/*.md
- myproject/.cursor/local/docs/**/*
alwaysApply: false
---
La idea es que este archivo solo se carga cuando se necesita. El agente obtiene exactamente lo que necesita para escribir buenas descripciones de PR, justo cuando lo necesita y sin cargar con el peso de sintaxis de esquemas o patrones de test que nunca va a usar.
Por Qué Esto Importa
- Respuestas más rápidas — Menos contexto = procesamiento de tokens más rápido
- No te quedas sin tokens 😅 Recuerda, todos estos tokens se usan en cada petición en la ventana de chat. ¡Estás multiplicando los ahorros por el número de preguntas!
- Guía más relevante — El agente ve las reglas para la tarea que tiene entre manos, no todo
- Mantenimiento más fácil — Actualiza las reglas de esquema sin tocar las reglas de test
- Mejor organización — Separación clara
- Escalable — Añade nuevos archivos de reglas sin inflar el índice siempre-cargado
RECAP/Corolario
El descubrimiento progresivo va realmente de respeto… por la atención de la IA (sí, eso existe), por tu presupuesto de tokens, y por tu propia cordura cuando mantienes reglas. Empieza simple. Divide cuando duela. Confía en los globs.
Y si te preguntas si esto es hilar muy fino para tu caso… probablemente no lo es. El momento en que te pilles pensando “¡¡¡¿Pero qué me está diciendo esto?!!!” —esa es tu señal.


Leave a Reply