Los agentes leen tu código y los archivos de instrucciones de tu repositorio. Contexto reúne esos archivos de memoria con las notas del proyecto, el contexto generado y las referencias.
Para conocer la razón por la que esto se incluye aquí, lee Contexto del proyecto en Conceptos. Esta página trata sobre cómo gestionarlo.
Archivos de memoria del repositorio
Abrir Configuración → Conocimiento → Contexto y busca bajo Fuentes del repositorio. Coroid lee estos archivos del repositorio conectado:
AGENTS.mden la raíz del repositorio: instrucciones generales para agentesCLAUDE.mden la raíz del repositorio: instrucciones para ClaudeGEMINI.mden la raíz del repositorio: instrucciones para Gemini.cursor/rules: reglas del proyecto de Cursor, ya sea el directorio de.mdcarchivos de reglas (incluidas las subcarpetas) o un único archivo heredado
Estos suelen llamarse archivos de memoria. Su contenido habilitado se incluye en el contexto del proyecto del agente antes de comenzar el trabajo. Los nombres no los limitan a un modelo específico: las fuentes habilitadas se combinan para los agentes de Coroid.
Los archivos existentes aparecen con un Editar acción, un recuento estimado de tokens y un switch que controla si los agentes los reciben. Las fuentes se habilitan a menos que las deshabilites explícitamente. Si varios archivos se repiten o contradicen entre sí, mantén habilitadas las fuentes que quieras que sigan los agentes y deshabilita las demás.
Al guardar una edición en un proyecto con un repositorio GitHub o GitLab conectado, se abre un pull request con el cambio, en una rama nueva a partir de la base de pull request del proyecto. Coroid no realiza commits en tu rama predeterminada, y los agentes leen la nueva versión una vez que se fusione el pull request. En un proyecto cuyo repositorio aloja Coroid, se realiza un commit. El editor lo indica antes de guardar.
Coroid lee las reglas de Cursor de la misma manera que Cursor las aplica:
| Regla | Lo que reciben los agentes |
|---|---|
alwaysApply: true | Toda la regla |
globs conjunto | Toda la regla, con los archivos a los que se aplica |
Solo un description | La ruta y descripción de la regla, para que el agente la lea cuando sea relevante |
| Ninguno de estos | Nada: Cursor la aplica solo cuando alguien la menciona |
Un archivo .md en .cursor/rules se ignora, ya que Cursor lo ignora. Las reglas en
el directorio se editan en el repositorio, por lo que esa fila no tiene Editar acción.
Crear significa que se confirmó la ausencia del archivo en la copia de trabajo del repositorio de Coroid. Si la lectura falla, la página ofrece Reintentar; un error de acceso no implica que el archivo falte. Comprueba que el archivo esté commiteado en la rama del repositorio conectado. Para la ejecución de tareas, el agente lee la copia de trabajo de la tarea, por lo que los cambios en los archivos de instrucciones de esa rama se aplican a la tarea.
Los archivos de memoria habilitados pueden importar Markdown del repositorio con @path, por ejemplo
@AGENTS.md en CLAUDE.md o @docs/conventions.md. Las rutas se resuelven en relación con
el archivo que contiene la referencia. Coroid sigue las importaciones anidadas, detiene los ciclos
y incluye cada archivo y cada cuerpo de instrucción idéntico solo una vez. Las importaciones dentro de ejemplos de código y direcciones de correo electrónico se dejan tal cual. Las referencias fuera del repositorio no se cargan, y las importaciones no pueden omitir una fuente del repositorio explícitamente deshabilitada.
Solo las fuentes listadas se detectan automáticamente. Un AGENTS.md anidado puede
incluirse mediante una @ importación; su ámbito de directorio no se infiere.
Contextos de aplicación
Bajo Contextos de aplicación, conserva las instrucciones y referencias almacenadas en Coroid. Las notas manuales y el contexto del proyecto generado se pueden habilitar o deshabilitar independientemente de los archivos del repositorio. Usa estas entradas para información que no pertenece a Git.
Añadir contexto
Selecciona Añadir contexto y añade una entrada. Cada una tiene un título y un cuerpo, y se puede editar o eliminar más tarde.
Las buenas entradas son cortas, específicas y duraderas. Las decisiones de arquitectura, convenciones de estilo, contratos de API, límites de propiedad y prohibiciones explícitas pertenecen aquí. La narrativa de incorporación y todo lo que ya sea obvio a partir del repositorio no.
Mantén las entradas separadas y con nombre
Una entrada por tema, titulada según lo que cubra. "Convenciones de manejo de errores" y "Módulos congelados" son recuperables; una única entrada llamada "Notas" que contenga ambas no lo es.
Esto es importante porque el contexto se carga selectivamente según el trabajo en curso — consulta Habilidades progresivas. Las entradas bien separadas permiten que la adecuada se cargue para la tarea correcta.
Referencias
Además de las entradas escritas, puedes adjuntar referencias: enlaces y documentos que apuntan a material almacenado en otro lugar. Úsalos cuando la copia autorizada se encuentre en una wiki o herramienta de diseño y no quieras que exista una segunda copia desactualizada.
Contexto por tarea
El contexto del proyecto se aplica a todo lo incluido en él. Para el material relacionado con una tarea específica —un ticket, un informe de cliente, un documento de diseño— adjúntalo a esa tarea en lugar de al proyecto. Una nota específica de una tarea que se incluye en el contexto del proyecto genera ruido en todas las tareas futuras.
Mantenerlo actualizado
Un contexto obsoleto es peor que la ausencia de contexto, ya que los agentes lo tratan como fuente autorizada. Cuando cambie una convención, actualiza la entrada en la misma modificación que altera el código.
Revisar lo que hay
Lee tu contexto ocasionalmente como si fueras nuevo. Las entradas se acumulan, y las redactadas durante una migración finalizada hace un año ahora resultan activamente engañosas.