Arasz/ai-badger

skill de orquestación de tareas

Ejecuta un elemento del backlog como una unidad de trabajo separada con seguimiento de tokens. Pensamiento de alto apalancamiento: la planificación y la puerta de calidad final se delegan a un modelo de alto razonamiento; los modelos de implementación hacen el trabajo práctico; la sesión de orquestación integra y rastrea todo para que una sesión muerta pueda reanudarse.

Todos los detalles del proyecto provienen de .ai-badger/config.json — nunca codifiques un comando de compilación, un nombre de persona o un repositorio. Los datos de seguimiento viven en .ai-badger/task-tracking/ (ignorado por git). Los scripts viven en scripts/ de este skill.

Contrato de configuración (leer primero)

Desde .ai-badger/config.json:

• commands.build / commands.test / commands.lint — los comandos de verificación para la Fase 3.
• personaRouting — asigna tipos de trabajo a las personas scaffolded; impulsa el envío de la Fase 2.
• sourceControl — plataforma + URL del repositorio/proyecto; controla la extensión de control de fuentes (flujo de PR, bucle de revisión, integración de issues/tableros). Si sourceControl.platform == "github" y hay una repoUrl, el fragmento extensions/github/ de este skill está activo — síguelo para los pasos de PR/bucle de revisión a continuación. De lo contrario, haz commit localmente e integra según tu plataforma.

Política de modelo y delegación

Gasta capacidad de alto razonamiento en planes, descomposición y revisión, no en escribir implementaciones. La sesión de orquestación obtiene ese razonamiento mediante delegación explícita, no asumiendo su propio modelo.

• Delega a un agente de alto razonamiento (planificación/descomposición en la Fase 1; la puerta final de corrección + arquitectura en la Fase 3). Prefija esas llamadas con una descripción para mantener el modelo visible de un vistazo.
• Delega a agentes de implementación emparejados con el trabajo, usando las personas de personaRouting en config.json. TDD es obligatorio para código.
• Delega trabajo mecánico trivial (actualizaciones de documentación/comentarios, refactorizaciones rutinarias, relleno de pruebas) a un modelo barato.
• La sesión de orquestación hace directamente: obtener la tarea, leer documentos, registrar el uso de tokens, la verificación ligera de finalización por subagente, ejecutar la compilación/prueba configurada y pequeñas correcciones quirúrgicas encontradas durante la puerta de calidad.

Los prompts de los subagentes deben ser autocontenidos: alcance, criterios de aceptación, archivos/documentos para leer, las reglas de TDD + estilo de código del proyecto (dirígelos a CLAUDE.md) y qué informar. Ejecuta subagentes independientes en paralelo.

Artefacto de visualización conocido — no lo diagnostiques erróneamente como un error de envío: el campo model por tarea del panel de agente en vivo (y cualquier línea de estado personalizada que lo lea) puede mostrar transitoriamente un valor obsoleto — por ejemplo, mostrando el modelo de la sesión principal para un subagente que en realidad fue enviado con una anulación de model diferente. Causa raíz: el campo del panel proviene de un feed de estado en vivo asíncrono, una ruta de código separada del resolvedModel que Claude Code escribe en los metadatos del resultado de la herramienta de la transcripción de la sesión al finalizar la llamada. La transcripción es la fuente de verdad; el panel es una instantánea que puede retrasarse. Si alguna vez hay dudas sobre el modelo real de un envío, busca en la transcripción .jsonl de la sesión el Agent tool_use cuya description coincida y verifica su tool_result emparejado para toolUseResult.resolvedModel en lugar de confiar en el panel. No pierdas tiempo investigando esto como un problema de código de envío a menos que la transcripción misma muestre un resolvedModel incorrecto.

Envío consciente de caché: el prefijo de solicitud de cada agente incluye el contexto siempre cargado de tu proyecto (instrucciones equivalentes a CLAUDE.md/AGENTS.md, .ai-badger/state.json y cualquier otro archivo que tu proyecto cargue en cada turno) — mantenlos estables en bytes dentro de una tarea (nunca los reescribas a mitad de la tarea; el protocolo de finalización escribe el estado entre tareas) para que sirvan como lecturas de caché a aproximadamente una décima parte del costo en lugar de una escritura nueva. Las cachés de los subagentes son arranques en frío independientes con un TTL de ~5 minutos, por lo tanto: prefiere un subagente de múltiples turnos sobre muchos envíos únicos para un grupo de pasos relacionados (amortigua el arranque en frío) y usa /rewind en lugar de /compact para retroceder dentro de una tarea (rewind reutiliza el prefijo en caché; compact paga por una escritura de resumen nuevo). Compacta solo en los límites de la tarea (Fase 0). token-usage.json registra un cacheEfficiency de la sesión principal (cache_read ÷ (cache_read + cache_creation)); una proporción baja significa que el prefijo está cambiando. La división de caché por subagente no está disponible — la notificación de finalización expone solo total_tokens.

Si no puedes generar subagentes (estás ejecutándote como subagente tú mismo, o la herramienta Agent no está disponible), haz el trabajo directamente en la sesión con el modelo que esté disponible; el flujo de trabajo de seguimiento y el protocolo de finalización aún se aplican, pero anota en tu resumen que la planificación/revisión se ejecutó con menor rigor ya que no fue posible la delegación de alto razonamiento.

Fase 0 — Higiene del contexto

1. python3 scripts/task_tracker.py status. Si una tarea anterior está sin terminar, finalízala o estaciona.
2. Confirma que .ai-badger/state.json refleje la última tarea finalizada; repáralo si no.
3. Si esta sesión tiene un historial pesado, dile al usuario que haga /compact (o que comience de nuevo) y que vuelva a invocar /task <id> en un contexto limpio, luego detente — a menos que sea autónomo.

Fase 1 — Inicio

1. Resuelve la tarea (una URL de issue, o texto libre usado como alcance/título; verifica el tablero del proyecto a través de la extensión de control de fuentes si está activa). Lee los documentos referenciados.
2. Registra: python3 scripts/task_tracker.py start <taskId> --title "<title>" --branch task/<taskId>-<slug>.
3. Pídele al usuario que renombre la sesión para que coincida con la tarea (salta si es autónomo).
4. Crea/cambia a la rama de la tarea.
5. Planifica: delega la descomposición a un agente de alto razonamiento (la persona architect), alimentándolo con el cuerpo de la tarea y extractos de documentos. Usa su plan para impulsar la Fase 2.

Fase 2 — Ejecutar

1. Envía subagentes de implementación según personaRouting. Instruye a cada subagente de código para que escriba primero la prueba fallida (TDD).
2. Registra los total_tokens de cada subagente al finalizar: python3 scripts/task_tracker.py subagent <taskId> <total_tokens> --description "<lo que hizo>".
3. Revisa cada resultado en las uniones (¿coincide con el plan? ¿criterios de aceptación?). Envía seguimientos en lugar de reescribir, a menos que la corrección sea de pocas líneas.
4. Haz commit y push por paquete de trabajo (commits pequeños). Si la extensión de control de fuentes está activa, abre un PR borrador temprano según extensions/github/.

Fase 3 — Puerta de calidad

Ejecuta los commands.build y commands.test configurados tú mismo y captura la salida. Luego delega una revisión a un agente de alto razonamiento (la persona code-reviewer) con el diff, los criterios de aceptación, los documentos de arquitectura relevantes y la salida de compilación/prueba. Pídele que juzgue la corrección de la implementación (lógica, casos borde, honestidad de las pruebas) y la arquitectura (pureza de capas, coherencia con los documentos). Corrige los hallazgos (los triviales tú mismo, los sustanciales a través de un subagente), vuelve a ejecutar compilación/prueba, luego continúa.

Fase 4 — Protocolo de finalización

1. Si la extensión de control de fuentes está activa, sigue extensions/github/ para PR-listos, el bucle de rondas de revisión y squash-merge. De lo contrario, integra según tu plataforma.
2. Actualiza los archivos de estado: antepone la entrada resumida de la tarea finalizada a completedTasks de .ai-badger/state.json, actualiza next/lastUpdated; escribe notas/decisiones detalladas en el archivo de notas del proyecto.
3. Verificación de compactación en CLAUDE.md si el proyecto tiene uno.
4. Cierra el seguimiento: python3 scripts/task_tracker.py finish <taskId>.
5. Pídele al usuario que califique el skill de 0 a 5: python3 scripts/task_tracker.py grade <taskId> <0-5> (salta/déjalo sin establecer si es autónomo).
6. Informa el costo de tokens de la tarea y recomienda /compact o una sesión nueva antes de la siguiente tarea — este es el final predeterminado. Auto-continuación autorizada (ruta alternativa, solo cuando se cumple una condición observable: el modo autonómico/de compañero del skill auto-wm está activo, o la invocación original del usuario indicó explícitamente continuar con la siguiente tarea): después de que la Fase 5 se complete, compacta según la guía de la Fase 0, lee la siguiente tarea del campo next de .ai-badger/state.json (o el siguiente elemento no reclamado de tu fuente de backlog configurada) e invoca este skill nuevamente para esa tarea. Si no se cumple ninguna condición y no hay usuario disponible, comienza una nueva sesión y dile al usuario que vuelva a invocar el skill para que la siguiente tarea comience en un contexto limpio.

Fase 5 — Auditoría de brechas de documentación

Después de la integración, delega un agente de auditoría de documentación (aislado del árbol de trabajo) para verificar CLAUDE.md y los documentos del proyecto contra el código fusionado, corrige pequeñas desviaciones e informa brechas que necesiten una decisión.

Recuperación

task_tracker.py registra el ID de sesión y el comando de reanudación de cada tarea; un cron de reanudación vigila las sesiones estancadas. Si te despiertas en una sesión reanudada a mitad de una tarea, ejecuta primero python3 scripts/task_tracker.py reattach <taskId> y luego continúa.

Extensiones: el comportamiento de PR/issue/bucle de revisión de control de fuentes se define en extensions/<nombre>/ y es incrustado por welcome-ai-badger solo cuando config.json proporciona los datos requeridos. El skill base anterior permanece neutral en cuanto a plataforma y pila tecnológica.