Los agentes leen tu repositorio. Eso cubre la mayor parte de lo que necesitan; pero no las decisiones que residen en la mente de las personas, en un wiki o en una conversación de hace dos años.
Contexto del proyecto Combina las instrucciones del repositorio con la guía que guardas en Coroid.
Las instrucciones del repositorio también forman parte del contexto.
Coroid lee archivos de memoria como los de nivel raíz AGENTS.md, CLAUDE.md y
GEMINI.md, además de las reglas de Cursor en .cursor/rules. Las fuentes habilitadas se incluyen
en el contexto del proyecto del agente antes de iniciar el trabajo. El entorno local del repositorio @ pueden incorporar otros archivos de instrucciones. Las importaciones repetidas, los ciclos y los cuerpos de instrucciones idénticos se incluyen una sola vez. No necesitas copiar esas instrucciones en una entrada del contexto de la aplicación.
En Configuración → Conocimiento → Contexto, Fuentes del repositorio controla qué archivos reciben los agentes, mientras que Contextos de aplicación almacena notas manuales y el contexto generado en Coroid. Las fuentes se habilitan a menos que se deshabiliten explícitamente; desactiva las instrucciones superpuestas o conflictivas que no desees combinar.
Las instrucciones del repositorio viajan con el código en Git. Los contextos de aplicación son útiles para guías y referencias que guardas fuera del repositorio. Ambos requieren mantenimiento cuando cambia una convención. Consulta Configuración de contexto del proyecto para rutas compatibles, detección de archivos y controles.
Qué determina Coroid por sí solo
Solo a partir del repositorio, los agentes pueden ver:
- los lenguajes, frameworks y bibliotecas en uso
- cómo se construye, prueba y ejecuta el proyecto
- los patrones existentes: cómo se gestionan los errores, cómo se estructuran los módulos y cómo se nombran las cosas
- Dependencias entre elementos
No necesita documentar nada de esto. Reescribirlo supone un esfuerzo innecesario y el riesgo de que quede desactualizado respecto al código, que es la fuente más fiable en cualquier caso.
Lo que los agentes no pueden deducir
El código muestra qué hizo usted, nunca por qué:
- Una biblioteca elegida en lugar de una alternativa obvia por una razón que sigue siendo aplicable
- Un patrón que parece duplicación pero es una separación deliberada
- Un módulo que nadie debe modificar sin consultar a un equipo específico
- Convenciones acordadas pero aún no implementadas en ningún sitio
- Restricciones externas al código base: cumplimiento normativo, contratos, una migración en curso
Esto es lo que debe incluirse en el contexto del proyecto. La prueba es sencilla: ¿Podría alguien que solo leyera el repositorio resolverlo? Si la respuesta es sí, déjelo fuera. Si no, escríbalo.
El repositorio muestra qué
Los agentes lo leen en cada tarea. No hay necesidad de repetirlo.
- Lenguajes, frameworks y bibliotecas
- Cómo se compila, prueba y ejecuta
- Patrones y nomenclatura existentes
- Qué depende de qué
Usted añade por qué
El contexto del proyecto incluye lo que reside en la mente de las personas.
- Por qué se eligió una biblioteca en lugar de una alternativa obvia
- Duplicación que constituye una separación deliberada
- Módulos que nadie debe tocar sin autorización del equipo específico
- Convenciones acordadas pero aún no aplicadas
- Restricciones externas: cumplimiento normativo, contratos, una migración en curso
La prueba: ¿Podría alguien que solo leyera el repositorio resolver esto? Si la respuesta es sí, omítalo. Si no, anótelo.
Añadir contexto
Adjunte documentos, políticas y referencias en la sección de Contexto del proyecto. Las notas de arquitectura, los registros de decisiones, las guías de estilo y los contratos de API son todos válidos.
Un buen contexto es breve y específico. Una guía de incorporación de 40 páginas escrita para personas contiene mayormente narrativa; los tres párrafos que indican restricciones reales son los que importan. Extraiga esos.
Contexto por tarea
El contexto adjunto al proyecto se aplica a todo. Para algo relevante para una sola tarea —una incidencia, un documento de diseño, un informe de cliente— adjúntelo a la tarea en lugar de al proyecto.
Conserva el contexto del proyecto solo para lo que sea permanentemente cierto. Una nota específica de una tarea en el contexto del proyecto se convierte en ruido en cada tarea futura.
Mantenerlo fiel a la realidad
El contexto desactualizado es peor que no tener contexto, ya que los agentes lo tratan como autoritativo. Cuando cambie una convención, actualiza el contexto en la misma modificación que altera el código.
Si te encuentras corrigiendo lo mismo repetidamente en los comentarios de re trabajo, eso indica que falta algo en el contexto o que algo en él está incorrecto.