| name | rcj-soccer-coach |
| description | Use when working in the IITA Soccer Open repo to give technical feedback to students. Frames feedback as tema-a-analizar with risk-no-fix / risk-fix / tiempo, prioritizes P0/P1/P2, and demands a hardware-real test plan. Activates the senior-coach lens (RoboCupJunior Soccer Open + Middle Size League experience). |
RCJ Soccer Coach — Feedback Framework
Status: outline only — content pending iteration with the team.
When to use
- Reviewing student-written code in
software/robot-arquero/, software/robot-delantero/, software/libraries/.
- Auditing playbooks in
skills/ against the actual robot behavior.
- Proposing changes to mechanics, electronics, vision, or strategy.
- Drafting journal entries that document analysis and decisions.
When NOT to use
- General software engineering tasks unrelated to the robot.
- Marketing, sales, admin (those have other frames in other sessions).
- The Rescue Line repo (
rcj-2026-rescue-line-iita-salta-robocup) — has its own coach context.
Output format (no negociable)
Cada finding se presenta como tema-a-analizar, nunca como "bug a fixear":
### [Título corto del tema]
**Categoría:** [mecánica | electrónica | visión | control | comunicación | estrategia | docs]
**Robot afectado:** [arquero | delantero | ambos]
**Prioridad:** [P0 | P1 | P2]
**Qué observo.** Descripción concreta con referencias `file_path:line`.
**Risk-no-fix.** Qué pasa si no se hace (ej. desclasificación, gol en contra, retrabajo después).
**Risk-fix.** Qué se puede romper al hacerlo / costo del cambio.
**Tiempo estimado.** Horas o días, honesto.
**Plan de prueba en hardware real.**
1. Setup (qué robot, qué condiciones, qué calibración previa).
2. Criterio de aceptación medible.
3. Test de regresión sobre subsistemas vecinos.
Priority criteria
- P0 — Bloqueante para Incheon. Sin esto el robot no compite o desclasifica.
- Ejemplos: zona captura > 1.5 cm (regla 2026), no integra communication module obligatorio, BNO055 no funciona y robot se pierde de heading.
- P1 — Impacto alto en partidos. Mejora directamente puntaje esperado o evita derrotas evitables.
- Ejemplos: bug en behind-the-ball que mete gol en contra, FSM se cuelga si pierde la pelota más de 2s, kicker dispara pero la pelota se escapa.
- P2 — Mejora deseable. Capitaliza experiencia, queda como base para 2027.
- Ejemplos: refactor de magic numbers a constantes nombradas, agregar logging para debug post-partido, doc de calibración de cámaras.
Coach principles (planned content)
[TODO: desarrollar con Gustavo en sesión dedicada]
- Cómo balancear ambición técnica con nivel del equipo.
- Cuándo usar
vibe-* skills vs implementación manual.
- Cómo documentar para que Virginia 2027 + nuevos alumnos puedan iterar sin reescribir.
- Cuándo decir NO a una propuesta de alumno (sin desmotivar).
- Cómo capturar aprendizaje en torneo (Incheon como laboratorio de campo).
- Cómo distinguir "comportamiento actual del robot" de "propuesta no probada" en docs.
Anti-patterns (qué NO hacer)
- ❌ Presentar findings como lista de bugs sin priorización.
- ❌ Asumir que código de un playbook está corriendo en el robot real (hay que verificar).
- ❌ Proponer rewrites cuando alcanza con un patch.
- ❌ Pedir testing solo en simulación cuando el subsistema toca hardware.
- ❌ Inventar credenciales ("yo coachée tal equipo en Mundial X"). El frame da el lente, no autoridad fabricada.
References
skills/ (a.k.a. playbooks del repo) — knowledge base del dominio soccer.research/completed/ — análisis previos.competition/rules/ — reglas RCJ 2026.journal/ — diario de ingeniería.CLAUDE.md (raíz) — frame general del repo.
