builder-implement-from-plan
Implementa en orden las tareas de un work_plan aprobado como rol builder, bajo el contrato de ejecucion de orchestrator_launch_builder (identidad y paridad del contrato, preflight, tests, gates focale
SKILL.mdskills/builder-implement-from-plan/SKILL.md
GitHubbuilder-implement-from-plan
Skill para implementar codigo segun un plan de trabajo aprobado.
Overview
Cuando el Manager marca un plan como APPROVED, el Builder usa esta skill para:
- Leer y entender el plan completo
- Implementar tareas en orden (sin saltar fases)
- Aplicar reglas de codigo (pathlib, type hints, etc.)
- Registrar progreso y escalarse si es necesario
Workflow
Paso 0: Verificar Turno
python .agent/agent_controller.py
Debe indicar ROL ACTIVO: BUILDER y accion IMPLEMENT.
Paso 1: Cargar Contexto
Leer en orden:
.agent/rules/builder/- restricciones del rolwork_plan.md- plan aprobado completoexecution_log.md- progreso previoreferences/code-rules.md- reglas de codigo
Paso 2: Identificar Tarea Actual
En work_plan.md, buscar:
- Primera fase con tareas pendientes
[ ] - Primera tarea no completada en esa fase
NO saltar fases - Implementar en orden.
Paso 3: Verificar Pre-condiciones
Antes de implementar:
- Plan esta
APPROVED(noDRAFToIN_PLANNING) - No hay tareas
USUARIOpendientes en esta fase - Entiendo que debo hacer (criterio de aceptacion claro)
Paso 4: Implementar con Reglas de Codigo
Ver references/code-rules.md para detalles completos.
Reglas esenciales:
| Regla | Ejemplo | Incorrecto | Correcto |
|---|---|---|---|
| Pathlib | Rutas | os.path.join() |
Path() / "file" |
| Type hints | Funciones | def load(): |
def load() -> dict: |
| Docstrings | Publicas | Sin docstring | """Carga config.""" |
| Logging | Errores | print(e) |
logger.error(e) |
| Try/except | Excepciones | except: |
except ValueError: |
Paso 5: Probar el Codigo
# Ejecutar tests relacionados
python scripts/run_pytest_safe.py -- tests/test_[modulo].py -v
# Fallback
python scripts/run_pytest_safe.py -- tests/test_[modulo].py -v
# Verificar linting
ruff check src/[archivo].py
ruff format --check src/[archivo].py
Si falla: Corregir antes de continuar.
Paso 6: Ejecutar builder-self-audit (OBLIGATORIO)
Antes de documentar la tarea como completada, ejecuta el skill builder-self-audit.
builder-self-audit cubre:
- Protocolo "ya existia" con cita de linea
- Completitud multi-archivo
- Checklist anti-regresion para ISS/code smell
- Gate completo ruff check + ruff format --check + pytest
Solo si builder-self-audit pasa completamente, continua al Paso 7.
Paso 7: Documentar en execution_log.md
### [OK] [FECHA] - [Nombre Tarea]
- **Archivo:** `src/[archivo].py`
- **Cambios:** [Descripcion breve]
**Codigo anadido:**
```python
# Ejemplo de funcion creada
def nueva_funcion() -> None:
pass
Tests:
$ python scripts/run_pytest_safe.py
[archivo].py::test_nueva PASSED
Hallazgos: [Si aplica, referencia a findings.md]
### Paso 8: Marcar Tarea Completada
En `work_plan.md`:
- Cambiar `- [ ]` a `- [x]` para la tarea completada
### Paso 9: Verificar si Fase Completa
Si todas las tareas de la fase estan `[x]`:
1. Ejecutar los **gates focales** de la fase (loop rapido: no autorizan handoff)
2. Incluir `ruff format --check` sobre los archivos Python tocados
3. Si pasan -> Continuar con siguiente fase
4. Si fallan -> Corregir antes de continuar
### Paso 10: Cierre Canonico (solo al completar el plan entero)
El contrato de cierre canonico (comandos, orden, evidencia de bus, distincion
loop rapido vs cierre, y que hacer si `checkpoint/review-<ticket>` esta `stale`)
lo define el prompt canonico, no esta skill:
- `prompts/orchestrator_launch_builder.md`, secciones "Loop rapido vs cierre
canonico (politica WOT-2026-011g)" y "Registro y cierre" (`cid-bui-implement-v1`).
Sigue esa fuente. Si esta skill y el prompt divergen, prevalece el prompt.
## Escalacion
**Escalar al Manager si:**
| Riesgo | Condicion | Accion |
|---|---|---|
| Bajo | 3+ intentos fallidos | Escalar |
| Medio | 2+ intentos fallidos | Escalar |
| Alto | 1 intento fallido | Escalar inmediatamente |
| Cualquiera | 30+ min bloqueado | Escalar |
**Como escalar:**
1. Documentar en `execution_log.md` intentos realizados
2. Anadir la escalacion a la superficie de review vigente
3. Cambiar estado a `BLOCKED`
4. Informar al usuario
## Output Format
### Al Completar Tarea
- Tarea marcada `[x]` en `work_plan.md`
- Entrada en `execution_log.md` con cambios y tests
- `findings.md` actualizado (si aplico hallazgos)
### Al Completar Fase
- Todas las tareas de la fase en `[x]`
- Gates focales de la fase pasados
- Resumen de la fase en `execution_log.md`
### Al Completar Plan
- Todas las fases completadas
- Resumen final en `execution_log.md`
- Cierre canonico ejecutado segun el Paso 10 (contrato en el prompt canonico)
- Estado cambiado a `READY_FOR_REVIEW` por el controller (no manualmente)
## References
- `references/code-rules.md` - Reglas completas de codigo Python
- `references/log-format.md` - Formato de execution_log.md
- `.agent/rules/builder/` - Restricciones del rol
- `.agent/workflows/builder_workflow.md` - Flujo completo
## Constraints
- **NO** modificar `work_plan.md` (excepto marcar tareas `[x]`)
- **NO** saltar fases del plan
- **NO** omitir type hints o docstrings
- **NO** usar `os.path` (usar `pathlib`)
- **SIEMPRE** escalar si se superan intentos segun riesgo