Imported from betta-tech/harness-sdd (
AGENTS.md). Install upstream withnpx skills add betta-tech/harness-sdd. 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)
- Ejecuta
./init.shy verifica que termina sin errores. Si falla, para y resuelve el entorno antes de tocar código. - Lee
progress/current.mdpara entender en qué estado quedó la última sesión. - Lee
feature_list.json. Toda feature nueva ("sdd": true) pasa por Spec Driven Development — verdocs/specs.mdy §4 de este archivo. - Lee
docs/specs.mdantes de tocar cualquier spec o featuresdd: true.
2. Mapa del repositorio
| Archivo / carpeta | Qué contiene | Cuándo leerlo |
|---|---|---|
feature_list.json |
Lista de tareas con estado (pending / spec_ready / in_progress / done / blocked) |
Siempre, al empezar |
progress/current.md |
Estado de la sesión actual | Siempre, al empezar |
progress/history.md |
Bitácora append-only de sesiones anteriores | Si necesitas contexto histórico |
specs/<feature>/ |
requirements.md + design.md + tasks.md (Kiro-style) |
Antes de implementar cualquier feature con "sdd": true |
docs/architecture.md |
Qué significa "hacer un buen trabajo" en este proyecto | Antes de implementar |
docs/conventions.md |
Reglas de estilo, nombres, estructura | Antes de escribir código |
docs/specs.md |
Proceso SDD: EARS notation, los 3 archivos, puerta de aprobación humana | Antes de redactar o leer un spec |
docs/verification.md |
Cómo verificar que tu trabajo funciona (incluye trazabilidad requirements) | Antes de declarar una tarea como done |
CHECKPOINTS.md |
Criterios objetivos de "estado final correcto" | Para auto-evaluarte |
.claude/agents/ |
Definiciones de subagentes (leader, spec_author, implementer, reviewer) |
Si orquestas trabajo |
src/ |
Código de la aplicación | Para implementar |
tests/ |
Tests automáticos | Para verificar |
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
donesin pruebas verdes. Ejecuta./init.shy asegúrate de que el bloque de tests pasa al 100%. - No saltes la fase de spec. Toda feature con
"sdd": truedebe pasar porspec_authory obtener aprobación humana antes de tocar código. - No saltes la puerta de aprobación humana. El leader detiene el flujo
en
spec_readyy espera. - Documenta lo que haces en
progress/current.mdmientras 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
- El leader detecta la primera feature
pendingcon"sdd": true. - El leader lanza
spec_author, que creaspecs/<name>/{requirements,design,tasks}.mdy marca el status comospec_ready. - Pausa. El humano lee el spec en
specs/<name>/y aprueba (o pide cambios). - Una vez aprobado, el leader cambia el status a
in_progressy lanzaimplementer. - El implementer ejecuta
tasks.mduna a una, marcándolas[x]. - El reviewer verifica trazabilidad
R<n>↔ test y tasks completas; aprueba o rechaza. - Si aprueba, el implementer marca
doney mueve el resumen aprogress/history.md.
5. Cierre de sesión (lifecycle)
Antes de terminar:
- Ejecuta
./init.sh— todo verde. - Si la tarea está acabada: marca
status: "done"enfeature_list.json. - Mueve el resumen de
progress/current.mdal final deprogress/history.md. - Vacía
progress/current.mddejando solo la plantilla. - 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.mdy para la sesión.