Cómo hacer que Continue escriba una regla a partir de la conversación que acabas de tener (Guía de 2026)

Los archivos de instrucciones se escriben con anticipación, por alguien que imagina lo que un agente necesitará. Eso es algo razonable y captura lo estable: comandos de construcción, estilo, pasos de revisión. Sistemáticamente pasa por alto todo lo demás, porque las cosas que realmente hacen tropezar a un agente no se pueden saber hasta que tropieza.

Continue es claro sobre para qué sirve una regla: las reglas "proporcionan instrucciones de mensaje del sistema al modelo para el modo Agente, Chat y solicitudes de Edición", y "para formar el mensaje del sistema, las reglas se unen con nuevas líneas, en el orden en que aparecen en la barra de herramientas". Una regla es una configuración a nivel de prompt, que se vuelve a enviar en cada solicitud. Ese enfoque es preciso y explica por qué escribir reglas desde la imaginación produce reglas endebles. Estás adivinando el contenido de un mensaje del sistema.

La corrección es diferente. Llega con todo lo que una buena regla necesita ya adjunto: un comportamiento específico que estuvo mal, el comportamiento correcto y, si lo dices en voz alta (lo que la gente suele hacer cuando está molesta), la razón. "No uses el endpoint por lotes para la conciliación porque se agota el tiempo de espera con más de diez mil filas". Esa última cláusula es lo que hace que la regla sobreviva al contacto con una decisión futura. Una prohibición simple se anula la primera vez que resulta inconveniente.

El problema nunca ha sido que la gente no sepa esto. Es que escribirlo es una segunda tarea, realizada en el momento en que tienes menos ganas de hacer una segunda tarea. Que es exactamente para lo que sirve una llamada a una herramienta.

Volver a escribir la restricción en cada sesión. Este es el comportamiento por defecto, y funciona, en el sentido de que el código sale bien. Lo que cuesta es que la restricción tiene una vida media igual a tu memoria de ella, y es invisible para todos los demás en el equipo. La forma general de este problema se aborda en cómo dejar de volver a explicar el contexto a la IA.

Un único archivo de reglas grande siempre activo. Todo lo aprendido va a una sola regla con alwaysApply: true. Nunca deja de estar presente, y ese es el problema: después de unos meses, el modelo recibe varios miles de palabras de correcciones acumuladas en cada solicitud, la mayoría irrelevantes para la tarea, y las que importan compiten con las que no. Mantener menos información frente al modelo suele ser la mejor opción, como argumentamos en la memoria del agente y mantener menos.

Escribirlo en el README o en un documento de diseño. Instinto correcto, contenedor equivocado. Continue lee las reglas de .continue/rules; un README no está en el mensaje del sistema a menos que algo lo ponga allí. El conocimiento se preserva para los humanos y está ausente para el agente.

Confiar en la conversación. La corrección está ahí mismo en el chat, así que seguramente el modelo la tiene. La tiene, para esta sesión. Las reglas de Continue existen porque ese es el límite: las instrucciones se vuelven a suministrar por solicitud, y un chat no es un almacén. Explicamos por qué en por qué los agentes ignoran tus archivos de instrucciones.

Recurrir a una habilidad (skill). Las habilidades empaquetan un procedimiento. Una corrección no es un procedimiento, es un hecho sobre tu base de código, y la distinción importa más de lo que parece; consulta por qué las habilidades de los agentes no son memoria.

Paso 1: Activa la creación de reglas y úsala al mismo tiempo que la corrección

create_rule_block es una herramienta que llama el agente, y la documentación de Continue señala que funciona "si está habilitada", así que confirma que está disponible en tu lista de herramientas del modo Agente antes de confiar en ella. Continue también ofrece un botón "Add Rules" para crear reglas a mano, que es la alternativa cuando quieres escribir una desde cero en lugar de a partir de una conversación.

El patrón de uso que funciona es corregir y capturar en un solo movimiento. En lugar de "no, usa el analizador de streaming aquí" seguido de seguir adelante, di "no, usa el analizador de streaming aquí; el endpoint por lotes se agota con más de diez mil filas. Crea una regla para eso". El agente escribe una regla en .continue/rules derivada de la conversación que acaba de tener, lo que significa que tiene tanto la razón como la instrucción.

Dos cosas a verificar en el archivo generado, porque determinan todo en el Paso 2. La documentación de Continue dice que las reglas "deben ser archivos .md con un frontmatter YAML adecuado", y que la carpeta debe ser .continue/rules/, no .continue/rule/, un error tipográfico que su sección de resolución de problemas señala específicamente. Luego lee el frontmatter que escribió el agente. Habrá tomado una decisión sobre globs, description y alwaysApply en tu nombre, y esa decisión es una suposición.

Continue no es el único que ofrece esto; Cursor tiene un comando /create-rule que hace algo similar. Lo que Continue documenta más claramente es la parte de la recuperación, que es donde están las decisiones interesantes.

Paso 2: Elige el comportamiento de recuperación deliberadamente

Los tres campos de frontmatter de Continue interactúan para producir tres comportamientos distintos, y la documentación los detalla.

Con alwaysApply: true, la regla "siempre se incluye". Usa esto solo para restricciones que sean verdaderas independientemente de lo que estés tocando. Una corrección sobre el endpoint de conciliación no es una de ellas.

Con alwaysApply: false, la regla se "incluye si existen globs Y coinciden con el contexto del archivo, o si el agente decide incorporar la regla al contexto basándose en su descripción". Este es el modo que la mayoría de las correcciones capturadas necesitan, y tiene dos activadores independientes. Si sabes qué archivos rige la restricción, define globs; la documentación de Continue describe que los globs coinciden "cuando se proporcionan archivos como contexto". Si la restricción es sobre un concepto en lugar de una ruta, apóyate en description y escríbela como una consulta de recuperación en lugar de un resumen. Continue es explícito en que "los agentes pueden leer esta descripción cuando alwaysApply es falso para determinar si la regla debe incorporarse al contexto". Una descripción que diga "restricciones de conciliación" no se activará cuando estés trabajando en una tarea de liquidación nocturna. Una que diga "restricciones en endpoints masivos, conciliación, liquidación y cualquier cosa que pagine sobre un gran número de filas" sí lo hará.

Omitir alwaysApply por completo te da el comportamiento por defecto: "se incluye si no existen globs O si existen globs y coinciden". Eso significa que una regla sin globs y sin alwaysApply está activa todo el tiempo, lo cual es un valor predeterminado razonable y un mal accidente. Si el agente generó un archivo sin frontmatter, habrás creado una regla siempre activa sin haberlo decidido.

Un detalle de orden que vale la pena conocer: "los archivos de reglas se cargan en orden lexicográfico, por lo que puedes anteponerles números para controlar el orden en que se aplican", usando nombres como 01-general.md y 02-frontend.md. Dado que las reglas se unen en un solo mensaje del sistema, el orden es precedencia en la práctica. Las correcciones capturadas generalmente pertenecen al final, después de tus convenciones generales, para que se lean como refinamientos en lugar de ser contradichas por algo más general más abajo.

Paso 3: Separa las reglas de los hechos antes de que la carpeta se llene

Después de unas semanas de captura, lee tu carpeta .continue/rules y hazte esta pregunta sobre cada archivo: ¿es esto una convención o un hecho?

Una convención dice cómo se hace el trabajo aquí: nomenclatura, estructura de manejo de errores, qué ejecutor de pruebas usar. Es estable, se aplica ampliamente y es exactamente para lo que sirve un mensaje del sistema. Consérvala. El conocimiento del dominio que es estable pero extenso es un tercer caso, y pertenece a un almacén en lugar de a un prompt, como explicamos en darle a Claude conocimiento permanente del dominio.

Un hecho dice qué sucedió. "Dejamos de usar el analizador de streaming en julio después de la regresión de memoria". "El sandbox del proveedor necesita el servidor de fixtures, por lo que las pruebas de pagos usan un comando diferente". "Intentamos dos soluciones en la prueba de integración inestable; ambas fallaron por la misma razón". Estos tienen propiedades que las convenciones no tienen: se acumulan sin límite, se reemplazan en lugar de editarse, y la mayoría de ellos son relevantes para un puñado de tareas al trimestre.

Los hechos almacenados como reglas se vuelven obsoletos de forma invisible. Nada te dice que una regla describe una decisión que se revirtió en agosto, y una decisión revertida presentada como una instrucción de mensaje del sistema es peor que no tener ninguna regla. Este es el mismo fallo que hace que los sistemas de historial de revisiones se desvíen, lo cual analizamos en agentes que mejoran a partir de la retroalimentación.

Los mecanismos documentados de Continue (reglas, con estos tres modos de recuperación) cubren bien las convenciones. No hay un equivalente documentado en ellos para un almacén que guarde un registro acumulativo y reemplazable de lo que un equipo ha establecido. Eso es una declaración de alcance sobre el sistema de reglas, no una crítica al mismo; un mensaje del sistema tiene la forma incorrecta para ese trabajo en cualquier herramienta.

MemoryLake es donde va la mitad de los hechos: un almacén fuera del repositorio que guarda las decisiones establecidas, admite la sustitución en lugar de la obsolescencia silenciosa y se puede leer a través de MCP o una API desde cualquier agente que estés ejecutando.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. La misma clave funciona desde Continue, desde el editor de un compañero de equipo y desde CI.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que ya contienen las decisiones de tu proyecto: el informe del incidente detrás de la política de reintentos actual, la revisión de diseño que nadie quiere repetir y los archivos de reglas que acabas de identificar como hechos en lugar de convenciones.

Paso 3: Conecta tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y otros agentes a través de MCP o la API. En Continue, eso significa que los hechos establecidos se recuperan cuando son relevantes en lugar de vivir permanentemente en tu mensaje del sistema.

Tu carpeta de reglas deja de crecer sin límite. Una vez que los hechos tienen otro lugar a donde ir, .continue/rules se estabiliza en el tamaño de tus convenciones reales, que para la mayoría de los repositorios es pequeño, legible y revisable en un pull request.

Las descripciones se escriben para la recuperación en lugar de para el archivo. Cuando lo único que tiene que hacer una description es ayudar al agente a decidir si incorporar la regla, la escribes de manera diferente, y las reglas que conservas comienzan a activarse cuando deben.

Las correcciones sobreviven al repositorio. Una regla vive en una copia local. Un hecho capturado fuera de ella está disponible cuando la misma restricción aparece en el servicio de al lado, que es donde ocurre la mayor parte de las explicaciones repetitivas.

Y el hábito de captura se vuelve lo suficientemente económico como para mantenerlo. Ese es el verdadero beneficio de create_rule_block: el costo de escribir algo se reduce a cuatro palabras. Que regrese correctamente es una decisión independiente, y ahora puedes tomarla deliberadamente.

Incluye siempre la razón. "No uses X" se anula. "No uses X porque Y" no.

Nunca dejes el frontmatter al azar. Lee lo que generó el agente. Un archivo sin globs y sin alwaysApply se activa para cada solicitud.

Escribe descripciones como consultas, no como etiquetas. La descripción es la señal de recuperación cuando alwaysApply es falso. Incluye las palabras que realmente escribirías.

Numera tus archivos de reglas. El orden de carga lexicográfico es la precedencia real. Convenciones al principio, refinamientos al final.

Prefiere archivos Markdown. Continue señala que las reglas se definieron originalmente en YAML, pero ahora recomienda el formato Markdown; mantener un solo formato hace que la carpeta sea revisable.

Vuelve a leer la carpeta mensualmente. No para podar convenciones, sino para detectar hechos que silenciosamente se han vuelto incorrectos.

create_rule_block resuelve un problema real que la mayoría de las herramientas dejan a la disciplina: elimina la fricción entre notar una restricción y registrarla. Di "crea una regla para esto" y la corrección se convierte en un archivo con el razonamiento adjunto, que es más de lo que logran la mayoría de las reglas escritas a mano.

La mitad que te corresponde a ti es la recuperación, y Continue te da las piezas para hacerlo correctamente: globs para restricciones de alcance de ruta, description para las de alcance de concepto, alwaysApply para las pocas cosas que son incondicionales y ordenamiento lexicográfico para la precedencia. Úsalos deliberadamente, especialmente en los archivos que generó un agente, porque una regla que nunca se activa y una regla que nunca deja de activarse fallan en direcciones opuestas y ambas se ven como una carpeta de reglas llena.

Luego haz la clasificación que mantiene todo el sistema saludable. Las convenciones pertenecen al mensaje del sistema. Los hechos pertenecen a un lugar que pueda albergar un registro creciente y corregible, y devolver solo la parte que importa. Conseguir que ese límite sea el correcto es lo que evita que el hábito de captura se convierta en un directorio que nadie lee.