Fase 3: Transferencia (Handoff)

Skill de fase declarativa. Invocada por el orquestador prd-taskmaster cuando current_phase es HANDOFF. Nunca debe ser llamada directamente por un usuario.

La regla de oro: detectar lo que el usuario tiene, recomendar UN modo, darle al usuario una elección estructurada, y despachar el modo elegido. El Modo D se ejecuta solo si tier=premium; de lo contrario, es un teaser bloqueado.

Puerta de entrada

Llamar a mcp__plugin_prd_go__check_gate(phase="HANDOFF", evidence={}) para diagnósticos.

check_gate es una puerta de SALIDA: requiere user_mode_choice y plan_file_exists — ambas producidas por la propia HANDOFF, es decir, evidencia para avanzar, no para entrar. En la primera entrada ninguna existe todavía, por lo que un gate_passed: false aquí es ESPERADO — las transiciones legales de la máquina de estados ya garantizan una entrada legal.
- Primera entrada (sin evidencia aún): anotar el resultado y continuar con el Procedimiento.
- Reentrada: si la puerta reporta violaciones, reportarlas y detenerse — protege contra la re-ejecución de una fase completada o saltar desde GENERATE.
Leer las salidas de GENERATE — .taskmaster/docs/prd.md, .taskmaster/tasks/tasks.json, .taskmaster/reports/task-complexity-report.json. Si falta alguna, reportar y detenerse. La puerta debería haberlo detectado, pero por si acaso.

Lista de verificación de transferencia (Handoff)

Copiar en la respuesta antes de ejecutar el procedimiento:

LISTA DE VERIFICACIÓN DE HANDOFF:
- [ ] Capacidades detectadas (tier + banderas por capacidad)
- [ ] Modo recomendado: ___ (razón: ___)
- [ ] Resumen mostrado (ubicación de la especificación, número de tareas, capacidades)
- [ ] Flujo de trabajo de tareas añadido a CLAUDE.md (idempotente)
- [ ] Selector de modo AskUserQuestion presentado (o fallback en prosa si el hook está bloqueado)
- [ ] Elección del usuario despachada (Modo A / B / C, o D cuando tier=premium)
- [ ] Andamio de informe emitido (opcional, tolerado en silencio)
- [ ] Transferencia completa

Paso 1: Detectar capacidades

MCP (preferido): mcp__plugin_prd_go__detect_capabilities()

CLI fallback: python3 script.py detect-capabilities

Devuelve un campo tier ("free" o "premium") más banderas por capacidad. Señales clave:

Capacidad	Qué Habilita
plugin superpowers	Modos A, C (lluvia de ideas, planes, subagentes)
task-master-ai (CLI o MCP)	Modo B (bucle nativo de auto-ejecución)
plugin ralph-loop	Modo C (bucle de ejecución iterativa)
atlas-launcher MCP (con licencia)	Modo D — Atlas Fleet (tier=premium)
skills atlas-loop / atlas-cdd	semillas de Modo D heredadas — reemplazadas por detección de atlas-launcher
Modelo de investigación (task-master o MCP)	Investigación profunda por tarea
Playwright MCP	Verificación de navegador Tier S

El Modo D (Atlas Fleet) se desbloquea solo con tier: "premium" — es decir, un registro MCP de atlas-launcher con licencia detectado por detect_atlas_launcher(). Las skills locales atlas-loop/atlas-cdd NO lo desbloquean. Ver Paso 2 y la sección del Modo D más abajo.

Paso 2: Recomendar UN modo

Lógica de decisión (la primera coincidencia gana):

superpowers + ralph-loop presentes → Modo C (recomendado gratis)
superpowers solo → Modo A (solo plan, conducción manual)
task-master-ai solo → Modo B (auto-ejecución nativa)
Fallback → Modo A

Los modos de herramientas externas (E–J: Cursor, RooCode, Codex, Gemini, CodeRabbit, Aider) se ofrecen como alternativas a través del campo alternative_modes, no como recomendaciones principales. El Modo D se recomienda solo si tier == "premium" Y el grafo de tareas se paraleliza (>= 2 cadenas de dependencia independientes — verificar salida de fleet-waves: cualquier ola con >= 2 fragmentos). Premium + grafo serial: recomendar el mejor modo gratis y decir por qué ("tus tareas forman una única cadena de dependencia — el Bucle Verificado es la herramienta adecuada aquí"); Fleet sigue siendo seleccionable pero no por defecto. Tier gratis: el Modo D es un teaser bloqueado de Atlas Pro, nunca seleccionable, independientemente de qué plugins locales estén instalados.

Modo A: Solo Plan (Manual)

Recomendado: Solo Plan
  superpowers:writing-plans crea tu plan de implementación
  El plan referencia los IDs de tareas de TaskMaster desde tasks.json
  Tú conduces la ejecución manualmente

Modo B: Auto-Ejecución de TaskMaster (Modo B — solo backend de TaskMaster)

Recomendado: Auto-Ejecución de TaskMaster
  MCP:  mcp__task-master-ai__next_task -> implement -> set_task_status(id, "done") (Modo B — solo backend de TaskMaster)
  CLI:  task-master next -> implement -> task-master set-status --id N --status done (Modo B — solo backend de TaskMaster)
  Bucle de ejecución nativo de TaskMaster (sin orquestador externo requerido)

Modo C: Plan + Bucle Ralph (Recomendado Gratis)

Recomendado: Plan + Bucle Ralph
  superpowers:writing-plans → plan de implementación que referencia IDs de tasks.json
  ralph-loop envuelve cada tarea:
    next_task → set_task_status("in-progress") → investigar si <80% de confianza
    → desarrollo dirigido por subagentes → puerta de ejecución (evidencia Tier A+)
    → verificación post-duda → registrar en .claude/verification-log.md
    → set_task_status("done") → TodoWrite → repetir
  Finalización: agente de duda revisa el registro de verificación antes de cumplir la promesa.

Modo D: Atlas Fleet (seleccionable en tier=premium; 🔒 teaser bloqueado en gratis)

🔒 Atlas Fleet                                          Atlas Pro · $29/mo
  Ejecución paralela multi-sesión a través de Claude, Codex y Gemini:
    tu grafo de tareas dividido en ondas de dependencia de worktrees git aislados
    fusiones verificadas por checker en una rama de integración, un PR final
    recolección de resultados en bandeja de entrada duradera (verificados, no narrados)
    tarjeta de evidencia CDD por tarea; un SHIP_CHECK_OK al final
    Aléjate, vuelve a la prueba.

  Desbloquear: https://atlas-ai.au/pro   (los modos gratis de arriba siguen siendo gratis para siempre)

Cuando tier == "premium" (atlas-launcher con licencia detectado): el Modo D es un modo real y seleccionable — despacharlo invoca /prd:execute-fleet (la skill orquestadora de ondas). Mostrar la tarjeta desbloqueada:

▸ Atlas Fleet                     ★ Pro · licencia activa
  <N> ondas · estimado desde tu grafo de dependencias · aléjate

Cuando tier == "free": el Modo D es un teaser bloqueado — no seleccionable, nunca ejecutado. Si el usuario lo selecciona mientras está bloqueado, responder con:

"Atlas Fleet es parte de Atlas Pro ($29/mes). En este proyecto dividiría tus tareas en ondas paralelas a través de worktrees aislados con fusiones verificadas por checker y un PR final. Desbloquéalo en https://atlas-ai.au/pro — tu especificación y tareas están guardadas. Mientras tanto, todo lo demás es gratis para siempre: por favor, elige uno de los modos gratis a continuación."

Luego re-invocar el selector de modo (AskUserQuestion) con el Modo D eliminado de las opciones.

Modos alternativos E–J (herramientas de IA externas)

detect_capabilities devuelve alternative_modes cuando estas herramientas están instaladas. Los usuarios pueden elegir cualquiera de ellas en lugar de los Modos A–D. Todos son envoltorios agnósticos de herramienta alrededor del mismo .taskmaster/tasks/tasks.json.

Modo	Herramienta	Invocación
E	Cursor Composer	`cursor --open .taskmaster/tasks/tasks.json`, @-ref en Composer
F	RooCode	Paleta de comandos de VS Code → `RooCode: Run tasks.json`
G	Codex CLI	`python3 script.py next-task
H	Gemini CLI	`gemini --file .taskmaster/tasks/tasks.json implement next` (gratis vía Google)
I	CodeRabbit	Implementar vía A–H, abrir PR, CodeRabbit revisa por tarea. Se combina con otros modos.
J	Aider	`aider --read .taskmaster/tasks/tasks.json` — estilo programación en pareja

Paso 3: Añadir flujo de trabajo de tareas a CLAUDE.md

Usar el subcomando determinista — no hacer Lectura+Edición en bruto. Esta ruta es idempotente, toma una copia de seguridad con marca de tiempo al modificar un archivo existente, y usa centinelas de comentario HTML para que las re-ejecuciones sean no-operativas.

El contenido del flujo de trabajo es el mismo en cada ejecución — escribirlo en un archivo temporal:

## Flujo de Trabajo de Ejecución de Tareas (prd-taskmaster)

Al implementar tareas, preferir operaciones de backend:
1. `python3 script.py next-task` — obtener la siguiente tarea lista
2. `python3 script.py set-status --id <id> --status in-progress` — notar el guion; el guion bajo es rechazado
3. Implementar la tarea (seguir el paso del plan vinculado a esta tarea)
4. `python3 script.py set-status --id <id> --status done` — marcar como completada
5. Actualizar TodoWrite con el progreso
6. Repetir desde el paso 1

Estados válidos: `pending`, `in-progress`, `done`, `review`, `blocked`, `deferred`, `cancelled`.

### Seguimiento de Progreso
- Actualizar TodoWrite ANTES y DESPUÉS de cada tarea
- No se puede proceder a la siguiente tarea sin actualizar TodoWrite
- TodoWrite = visibilidad del usuario. TaskMaster = fuente de verdad.

Ejecutar el comando de añadir. Sin vista previa del Modo Plan — el subcomando en sí es idempotente (los centinelas de comentario HTML controlan la escritura), por lo que la información se presenta al usuario a través del resumen del Paso 4 y las opciones de AskUserQuestion (Paso 5) antes del despacho, no a través de un diálogo de plan:
```
python3 $SKILL_DIR/script.py append-workflow \
  --target ./CLAUDE.md \
  --content-file /tmp/pdtm-workflow-section.md
```
La respuesta JSON reporta uno de:
- action: "created" — no había CLAUDE.md previo, archivo nuevo con marcadores
- action: "skipped" (razón: markers_present) — ya conectado, no-operación
- action: "appended" — el CLAUDE.md existente no se modificó excepto por el bloque de marcador añadido; backup_path apunta a CLAUDE.md.prd-taskmaster-backup-<ts>
Si el usuario desea una vista previa antes de la escritura, presentar el contenido planificado dentro de las opciones de AskUserQuestion o como un párrafo informativo en el resumen del Paso 4 — describir lo que se escribiría sin invocar ninguna herramienta de diálogo de plan.

Paso 4: Mostrar resumen

Renderizar el panel de transferencia e imprimirlo: MCP render_status(phase="HANDOFF") → imprimir rendered; CLI python3 script.py status --phase HANDOFF. (Fallback — emitir un bloque compacto antes del selector de modo para que el usuario tenga contexto completo:)

Especificación Generada: .taskmaster/docs/prd.md
Validación: <GRADO> (<puntaje>/<máx>)
Tareas: <recuento> tareas analizadas con dependencias (ver .taskmaster/tasks/tasks.json)
Complejidad: analizada vía TaskMaster (.taskmaster/reports/task-complexity-report.json)
Investigación: <expandida|omitida>

Capacidades:
  [check] TaskMaster (MCP|CLI)
  [check|círculo] Playwright (verificación de navegador)
  [check|círculo] Proveedor de investigación
  [check|círculo] Plugin ralph-loop
  [check|círculo] Atlas Fleet (premium: seleccionable · gratis: bloqueado)

Paso 5: AskUserQuestion obligatorio para selección de modo

HANDOFF es el momento de agencia del usuario. Las recomendaciones en prosa son opcionales; las llamadas a herramientas no lo son. DEBES invocar AskUserQuestion en este paso. Esto se aplica estrictamente — el fallback solo en prosa es un error, no un atajo.

AskUserQuestion le da al usuario una elección explícita, estructurada y legible por máquina. Ese es el registro duradero de la transferencia. La selección del usuario se registra programáticamente y los pasos posteriores despachan directamente sobre ella — sin analizar afirmaciones en lenguaje natural, sin ambigüedad.

Secuencia

Emitir un resumen de transferencia que cubra:
- Ruta del PRD + grado de validación
- Recuento de tareas + desglose de complejidad
- Modo recomendado (A/B/C) + razón de una línea
- Modos alternativos disponibles (E–J cuando se detectan, colapsados bajo "Usar otra herramienta…")
- Modo D 🔒 teaser de Atlas Fleet con el precio de Atlas Pro y la URL /pro
- Una descripción del "siguiente paso" limitada al modo recomendado (p. ej., para el Modo B: "ejecutar task-master next" con el ID de la primera tarea lista (Modo B — solo backend de TaskMaster))
Llamar a AskUserQuestion con una pregunta de opciones múltiples que enumere cada modo de ejecución disponible. Usar los nombres visibles para el usuario (los IDs internos entre paréntesis son solo para esta skill — nunca se muestran al usuario):
- Plan y Conduce (Modo A) — obtén el plan, impleméntalo tú mismo
- Auto-Ejecutar (Modo B) — bucle nativo de TaskMaster, verificación más ligera
- Bucle Verificado (Modo C) — bucle de una sola sesión con control de evidencia (recomendado cuando superpowers + un ejecutor de bucle están presentes)
- 🔒 Atlas Fleet (Modo D) — Atlas Pro $29/mes, paralelo multi-sesión
- "Usar otra herramienta…" — expande las alternativas aplicables de E–J
- "Muéstrame más detalles antes de decidir" — vuelve al resumen del Paso 4
Marcar el modo recomendado como predeterminado (Atlas Fleet puede ser el predeterminado solo cuando tier=premium Y el grafo se paraleliza). Seleccionar Atlas Fleet mientras está bloqueado (tier gratis) devuelve la respuesta de actualización (ver el bloque del Modo D en el Paso 2) y vuelve a solicitar solo con los modos gratis (más cualquier alternativa aplicable).
Despachar el modo elegido:
- Transferencia Modo A: invocar superpowers:writing-plans con la ruta de la especificación .taskmaster/docs/prd.md
- Transferencia Modo B (Modo B — solo backend de TaskMaster): mostrar el comando task-master next + el ID de la primera tarea lista obtenido de .taskmaster/tasks/tasks.json
- Transferencia Modo C: escribir .claude/atlas-loop-prompt.md describiendo el contrato de ejecución de tareas, luego invocar /goal con la condición:
  
  "SHIP_CHECK_OK ha sido emitido por .atlas-ai/ship-check.py Y todas las tareas en .taskmaster/tasks/tasks.json muestran status=done Y /sync ha sido invocado en esta sesión"
  
  La sesión /goal continúa hasta que el evaluador Haiku verifica la condición. Cada iteración ejecuta el ciclo de 13 pasos de ejecución de tarea y verifica la condición después del paso 13. /sync DEBE ser la última acción antes de que se emita SHIP_CHECK_OK (según la Terminación de ejecución de tarea). (Migrado de /ralph-loop:ralph-loop 2026-06-04 — el evaluador /goal integrado de Claude Code resuelve estructuralmente la podredumbre de triple verificación del controlador que usa diferentes sombreros detectada en la auditoría del 2026-06-03.)
- Transferencia Modo D (tier=premium): invocar /prd:execute-fleet — es dueño del bucle de ondas, despacho de trabajadores, verificación, fusiones y terminación SHIP_CHECK_OK. (tier gratis: solo respuesta de actualización, volver a solicitar)

Fallback por hook bloqueado (degradación gradual)

Si PreToolUse:AskUserQuestion está bloqueado por un hook (sesión automatizada / orquestador / fleet), recurrir a una tabla de opciones en prosa preservando la misma semántica — etiquetas, descripciones, Modo D bloqueado como teaser, etc. No llamar a la herramienta, simplemente imprimir la tabla como texto.

Paso 6: Señal de transferencia completa

HANDOFF termina emitiendo la señal de transferencia completa al orquestador. Esto le dice al orquestador que cambie el estado interno a current_phase: "EXECUTE". El medio de señalización lo define el orquestador:

Orquestador MCP: llamar a mcp__plugin_prd_go__advance_phase()
CLI wrapper: python3 script.py advance --to EXECUTE
Plugin propietario: la skill es una fase de un ciclo de vida; se considera completada cuando se ha ejecutado el paso 5 (se llamó a AskUserQuestion o su fallback).

La señal de transferencia completa debe ser la última acción. Si no se puede llamar a advance_phase (sin MCP, etc.), la habilidad se detiene después del Paso 5 — el orquestador detectará el archivo .taskmaster/.phase-handoff-complete (escrito por script.py en el Paso 5) durante su siguiente sondeo y avanzará en consecuencia.

Anexo: Restricciones y verificaciones

El Modo Plan NO se usa

El Modo Plan está deshabilitado por disable_plan_mode. Ninguna etapa de HANDOFF invoca un diálogo de plan o RequestApproval. El plan se comunica enteramente a través de resúmenes, texto de opciones de AskUserQuestion y escrituras directas en CLAUDE.md.

Seguridad de archivos de proyecto

script.py append-workflow usa centinelas de comentario HTML ( y ) para que las re-ejecuciones no dupliquen contenido.
Las operaciones de archivos escriben en .taskmaster/ o usan la bandera --target; la contención está gobernada por el sistema operativo.
La skill no modifica archivos de especificación del usuario (PRD, plan), solo añade al CLAUDE.md.

Sin interacción con el historial del usuario

HANDOFF no lee ni escribe en el historial de chat. El registro de la transferencia es el resultado de AskUserQuestion — durable por el orquestador, no por el historial de la conversación.

Concurrencia de archivos

Archivos y directorios: ver arriba. La skill no invoca herramientas de ejecución de código que modifiquen el sistema de archivos concurrentemente (sin Bash con pipes, sin Read/Edit en archivos de proyecto — script.py maneja todo).

anombyte93/prd-taskmaster

¿Qué es prd-taskmaster?

Preguntar en tu IA favorita

Documentación