Global: C:\Users\<username>\.config\opencode\AGENTS.md
local: AGENTS.md
# Reglas globales de trabajo
Ahorro de tokens (obligatorio)
- Nunca leas un archivo grande (>5 KB) entero al contexto. Procesa datos y archivos grandes con un script (
python /node vía bash): filtra, cuenta y agrega con código y trae al contexto solo el resultado.- Antes de leer, busca:
grep /glob para localizar, luegoread con offset/limit solo del tramo relevante. Tras un grep, lee las 5 líneas alrededor del match para distinguir definición de uso/llamada.- Exploraciones verbosas (auditorías, búsquedas en muchos archivos, revisiones): delégalas a un subagente
task y pide que devuelva SOLO el resumen con los hallazgos, no el volcado.- No releyas archivos que ya tienes en contexto y no han cambiado.
Exactitud (obligatorio)
- REGLA DEL DOBLE MÉTODO: para respuestas numéricas o de conteo, computa el resultado por DOS métodos independientes (p.ej. Python y awk) y repórtalo solo si coinciden. Si difieren, investiga cuál falla antes de responder.
- REGLA DEL PARSER: para datos estructurados (CSV, JSON, XML, logs), usa el parser de la librería estándar (
csv ,json ). Nunca proceses formatos con split o regex de líneas.- REGLA DE ESCRITURA: escribe archivos estructurados (JSON, código) con la herramienta write/edit, nunca con heredocs ni redirecciones de shell (los escapes rompen el contenido). Después de escribir, valida el archivo:
python -m json.tool para JSON, compilar para código.Efectividad
- REGLA DEL ENTREGABLE: antes de terminar, relee la última instrucción del usuario. Si pedía un archivo o artefacto (answer.json, un fix, un script), verifica que EXISTE y contiene exactamente lo pedido. La tarea no está terminada hasta que el entregable existe y es correcto.
- Antes de dar una tarea por terminada, verifica con el comando más barato disponible: compilar, correr los tests, o un script de comprobación. No afirmes que algo funciona sin haberlo ejecutado. NUNCA escribas una respuesta final (JSON, números, rutas) que no hayas verificado ejecutando.
- REGLA ANTI-BUCLE: si un comando falla, lee el error completo antes de reintentar. Nunca repitas el mismo comando sin cambiar nada. Máximo 2 reintentos; después, reporta el bloqueo en vez de seguir.
- Los comandos git que contactan con remotes (push, fetch, pull) deben fallar rápido si piden credenciales: no esperes input interactivo, no hay TTY. Reporta el error en vez de reintentar en bucle.
- En Windows usa rutas con precaución: el shell es Git Bash; los paths de Windows con espacios van entre comillas.
Memoria del proyecto (curación asistida)
Al terminar una tarea, si descubriste un hecho durable del proyecto (comandos de build correctos, convenciones, trampas conocidas, decisiones de arquitectura), PROPÓN añadirlo al AGENTS.md del proyecto en una o dos líneas y espera mi confirmación. No edites AGENTS.md sin confirmación, y no guardes secretos, tokens ni rutas con credenciales.
Mantenimiento de este archivo
- ENTRADA POR EVIDENCIA: ninguna regla entra por especulación. Entra solo tras observar el mismo fallo DOS veces, y debe citar el fallo que la motivó.
- FORMA: toda regla es un imperativo observable en una línea. Si no se puede comprobar si se cumplió ("sé conciso", "piensa bien"), no es una regla: se rechaza.
- PRUEBA: cuando sea posible, una regla nueva se valida antes de adoptarse — canario para reglas de formato, banco de tareas para reglas de comportamiento.
- BORRADO: una regla que no ha disparado en semanas, o cuyo fallo raíz ya está arreglado en código (p.ej. el anti-cuelgue de git vive en el binario: GIT_TERMINAL_PROMPT=0), se propone eliminar. Las reglas muertas diluyen a las vivas.