Imported from Cesar-Joel/geoagent (AGENTS.md). Install upstream with npx skills add Cesar-Joel/geoagent. Copyright stays with the author.

AGENTS.md — Mapa de navegación para agentes de IA

Este archivo es el punto de entrada para cualquier agente que trabaje en este repositorio. NO es una biblia de reglas: es un mapa. Lee solo lo que necesites cuando lo necesites (divulgación progresiva).

1. Antes de empezar (obligatorio)

1. Ejecuta ./init.sh y verifica que termina sin errores. Si falla, para y resuelve el entorno antes de tocar código.
2. Lee progress/current.md para entender en qué estado quedó la última sesión.
3. Lee feature_list.json. Toda feature nueva ("sdd": true) pasa por Spec Driven Development — ver docs/specs.md y §4 de este archivo.
4. Lee docs/specs.md antes de tocar cualquier spec o feature sdd: true.

2. Mapa del repositorio

3. Reglas duras (no negociables)

• Una sola feature a la vez. No mezcles cambios de varias tareas en la misma sesión.
• No declares una tarea done sin pruebas verdes. Ejecuta ./init.sh y asegúrate de que el bloque de tests pasa al 100%.
• No saltes la fase de spec. Toda feature con "sdd": true debe pasar por spec_author y obtener aprobación humana antes de tocar código.
• No saltes la puerta de aprobación humana. El leader detiene el flujo en spec_ready y espera.
• Documenta lo que haces en progress/current.md mientras trabajas, no al final.
• Deja el repositorio limpio antes de cerrar la sesión (ver §5).
• Si no sabes algo, busca en docs/ antes de inventarlo.

4. Flujo de trabajo (SDD)

pending → [spec_author] → spec_ready → ⏸ HUMANO → in_progress → [implementer → reviewer] → done

1. El leader detecta la primera feature pending con "sdd": true.
2. El leader lanza spec_author, que crea specs/<name>/{requirements,design,tasks}.md y marca el status como spec_ready.
3. Pausa. El humano lee el spec en specs/<name>/ y aprueba (o pide cambios).
4. Una vez aprobado, el leader cambia el status a in_progress y lanza implementer.
5. El implementer ejecuta tasks.md una a una, marcándolas [x].
6. El reviewer verifica trazabilidad R<n> ↔ test y tasks completas; aprueba o rechaza.
7. Si aprueba, el implementer marca done y mueve el resumen a progress/history.md.

5. Cierre de sesión (lifecycle)

Antes de terminar:

1. Ejecuta ./init.sh — todo verde.
2. Si la tarea está acabada: marca status: "done" en feature_list.json.
3. Mueve el resumen de progress/current.md al final de progress/history.md.
4. Vacía progress/current.md dejando solo la plantilla.
5. No dejes archivos temporales, ni print() de debug, ni TODOs sin contexto.

6. Si te bloqueas

• Relee la sección relevante de docs/.
• Si la herramienta no hace lo que esperas, no inventes un workaround: documenta el bloqueo en progress/current.md y para la sesión.