Discovery-to-execution handover — operational transition package, commercial activation, governance transfer, and Phase 1 kickoff plan. Use when the user asks to "create handover", "transition to operations", "prepare delivery handoff", "activate commercial proposal", "hand off discovery", "prepare operations package", "close discovery engagement", or mentions handover, transition, delivery kickoff, proposal preparation, or discovery close-out.
From maonpx claudepluginhub javimontano/mao-discovery-frameworkThis skill is limited to using the following tools:
examples/README.mdexamples/sample-output.htmlexamples/sample-output.mdprompts/metaprompts.mdprompts/use-case-prompts.mdreferences/body-of-knowledge.mdreferences/handover-templates.mdreferences/knowledge-graph.mmdreferences/state-of-the-art.mdEnables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Genera el paquete de transición operativa que traduce los entregables de descubrimiento (Fases 0-5) en artefactos de ejecución listos para Operaciones y/o Comercial.
Un discovery sin handover es un informe guardado en un cajón. La transición de descubrimiento a ejecución es donde el valor se materializa o se pierde. Cada insight, cada riesgo, cada decisión del discovery debe traducirse en una acción operativa con owner, fecha, y criterio de éxito. El handover no es un resumen — es un plan de activación.
El handover REQUIERE que Gate 3 esté aprobado. Antes de generar, validar que existen:
| Fuente | Entregable Requerido | Archivo Esperado |
|---|---|---|
| Phase 0 | Mapa de stakeholders + RACI | 01_Stakeholder_Map.html |
| Phase 1 | Análisis AS-IS (10 secciones) | 03_Analisis_AS-IS.html |
| Phase 2 | Mapeo de flujos + DDD | 04_Mapeo_Flujos.html |
| Phase 3 | Escenarios + scoring | 05_Escenarios_ToT.html |
| Phase 4 | Roadmap + costeo | 06_Solution_Roadmap.html |
| Phase 5a | Especificación funcional | 07_Especificacion_Funcional.html |
| Phase 5b | Pitch ejecutivo + financiero | 08_Pitch_Ejecutivo.html |
Si algún entregable falta, DETENER y listar qué falta antes de proceder.
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
{FORMATO}: markdown (default) | html | dual{VARIANTE}: ejecutiva (~40% — S1 resumen + S2 comercial + S6 tracker) | técnica (full 8 sections, default)El skill debe preguntar al usuario cuál es el receptor primario:
| Receptor | Enfoque del Paquete |
|---|---|
| Operaciones | Checklist de readiness, kickoff Phase 1, governance, riesgos operativos |
| Comercial | Propuesta comercial derivada del pitch, pricing, narrativa de venta |
| Ambos | Paquete completo (default) |
Sintetizar en máximo 1 página:
Derivar del 08_Pitch_Ejecutivo.html:
┌─────────────────────────────────────────────────────┐
│ ESTRUCTURA DE PRICING │
├─────────────────┬──────────┬────────┬───────────────┤
│ Fase │ Duración │ Equipo │ Inversión │
├─────────────────┼──────────┼────────┼───────────────┤
│ Foundation │ X meses │ N FTE │ $XXX,XXX │
│ Build │ X meses │ N FTE │ $XXX,XXX │
│ Integrate │ X meses │ N FTE │ $XXX,XXX │
│ Optimize │ X meses │ N FTE │ $XXX,XXX │
│ Scale │ X meses │ N FTE │ $XXX,XXX │
├─────────────────┼──────────┼────────┼───────────────┤
│ TOTAL │ XX meses │ │ $X,XXX,XXX │
│ Contingencia │ │ │ XX% │
└─────────────────┴──────────┴────────┴───────────────┘
| Semana | Actividad | Responsable | Entregable |
|---|---|---|---|
| 1 | Revisión propuesta con sponsor | Comercial | Propuesta v1 |
| 2 | Negociación términos | Comercial + Legal | Term sheet |
| 3 | Aprobación interna | Steering | SOW firmado |
| 4 | Kick-off operativo | Operaciones | Plan Phase 1 |
Mapear los 9+ prerrequisitos del roadmap (Phase 4) a tareas operativas:
| Rol | Cantidad | Status | Owner de Contratación | Fecha Límite |
|---|---|---|---|---|
| {Rol de Phase 4} | N | Pendiente/Listo | {Nombre} | {Fecha} |
| Componente | Especificación | Status | Owner | Fecha Límite |
|---|---|---|---|---|
| {De AS-IS + Roadmap} | {Specs} | Pendiente/Listo | {Nombre} | {Fecha} |
Derivar de Phase 1 (Foundation) del 06_Solution_Roadmap.html:
| Día | Actividad | Responsable | Output |
|---|---|---|---|
| 1-2 | Onboarding equipo técnico | Delivery Manager | Equipo operativo |
| 3-4 | Setup ambientes dev/staging | Tech Lead | Ambientes listos |
| 5 | Workshop de arquitectura objetivo | Architect | Decisiones técnicas |
| 6-7 | Configuración CI/CD pipeline | DevOps | Pipeline base |
| 8-10 | Primer spike técnico (mayor riesgo) | Dev Team | PoC validado/invalidado |
| Métrica | Target | Fuente | Frecuencia |
|---|---|---|---|
| Velocidad del equipo | Estabilizar en Sprint 3 | JIRA/Linear | Semanal |
| Defectos críticos | 0 en producción | Bug tracker | Diario |
| Cobertura de tests | >80% unit, >70% integration | CI pipeline | Por PR |
| Budget burn rate | ≤110% del plan | Finance | Quincenal |
| Riesgo materializado | 0 de top-3 | Risk register | Semanal |
| Rol Discovery | Transiciona a | Nuevo Responsable |
|---|---|---|
| Discovery Conductor | PMO Lead / Scrum Master | {Asignar} |
| Technical Architect | Solution Architect (ejecución) | {Mismo o nuevo} |
| Domain Analyst | Product Owner / BA | {Asignar} |
| Quality Guardian | QA Lead | {Asignar} |
| Delivery Manager | Project Manager / Engineering Manager | {Mismo o nuevo} |
| Data Strategist | Data Architect (ejecución) | {Mismo o nuevo} |
| Change Catalyst | Change Manager | {Asignar} |
| Ceremonia | Frecuencia | Participantes | Propósito |
|---|---|---|---|
| Standup | Diario | Dev team | Impedimentos + progreso |
| Sprint Planning | Quincenal | PO + Dev team | Scope del sprint |
| Sprint Review | Quincenal | Stakeholders + Dev | Demo + feedback |
| Retrospectiva | Quincenal | Dev team | Mejora continua |
| Steering Committee | Mensual | Sponsors + PMO | Go/no-go, budget, riesgos |
| Architecture Review | Quincenal | Architects | Decisiones técnicas |
Nivel 1: Dev Team → Tech Lead (resolución < 4h)
Nivel 2: Tech Lead → PM / PO (resolución < 24h)
Nivel 3: PM → Steering Committee (resolución < 1 semana)
Nivel 4: Steering → Executive Sponsor (decisiones de scope/budget/timeline)
Operacionalizar los pivot points del Phase 4:
| # | Supuesto | Validación Propuesta | Deadline | Owner | Status |
|---|---|---|---|---|---|
| 1 | {Del roadmap} | {PoC / spike / vendor eval} | Semana X | {Nombre} | Pendiente |
| 2 | ... | ... | ... | ... | ... |
Regla: Si un supuesto se invalida, activar el conditional switching logic del Phase 3 (escenario alternativo).
| # | Riesgo | Probabilidad | Impacto | Mitigación | Early Warning | Owner |
|---|---|---|---|---|---|---|
| 1 | {Del risk register} | Alta/Media/Baja | Alto/Medio/Bajo | {Acción} | {Indicador} | {Nombre} |
Regla: Revisar en cada Steering Committee. Si early warning se activa, ejecutar mitigación inmediata.
| Condición | Threshold | Acción | Decision Maker |
|---|---|---|---|
| Budget overrun | >130% del plan | Pause + re-scope | Executive Sponsor |
| Timeline overrun | >150% de Foundation | Re-evaluate approach | Steering Committee |
| Quality failure | >3 defectos críticos en producción | Stop + quality sprint | QA Lead + PM |
| Team attrition | >40% turnover | Pause + re-staff | HR + PM |
Transformar el mapa de stakeholders de Phase 0 en roles de ejecución:
| Stakeholder | Rol Discovery (Phase 0) | Rol Ejecución | Engagement Shift | Comunicación |
|---|---|---|---|---|
| {Nombre} | Sponsor | Executive Sponsor | Mensual steering | Dashboard + report |
| {Nombre} | Champion | Product Owner | Diario/semanal | Sprint reviews |
| {Nombre} | Informado | Consumidor | Por release | Release notes |
| {Nombre} | Resistente | Early adopter target | Post-MVP | Training + soporte |
09_Handover_Operaciones_{project}.md (o .html si {FORMATO}=html|dual)
Producir un documento con las 8 secciones anteriores, usando el sistema de diseño de la marca (READ references/handover-templates.md para la estructura HTML cuando {FORMATO}=html|dual).
| Dimensión | Opción A | Opción B | Regla de Decisión |
|---|---|---|---|
| Alcance del handover | Solo Operaciones | Comercial + Operaciones | Ambos si el deal no está cerrado; solo Ops si ya está firmado |
| Nivel de detalle 90 días | Sprint-level | Week-level | Sprint-level para equipos ágiles; week-level para waterfall |
| Governance | Ligera (standup + steering) | Completa (todas las ceremonias) | Completa si equipo > 5; ligera si ≤ 5 |
| Financial tracking | Mensual | Quincenal | Quincenal si budget > $500K; mensual si menor |
| Stakeholder transition | Mapeo 1:1 | Taller de transición | Taller si > 10 stakeholders; mapeo si ≤ 10 |
| Escenario | Respuesta |
|---|---|
| Gate 3 no aprobado | NO generar handover. Listar gaps. |
| Solo se ejecutó Quick Reference (Phases 1→3→5b) | Handover simplificado: solo S1 + S2 + S6. Sin 90-day plan. |
| Minimal Pipeline (sin Phase 0 ni 5a) | Omitir S7 (no hay stakeholder map). S4 simplificado sin use cases. |
| Cliente quiere solo propuesta comercial | Generar solo S1 + S2. Marcar S3-S7 como "pendiente post-cierre". |
| Equipo de ejecución es diferente al de discovery | Incluir sesión de knowledge transfer (2-4 horas) en Sprint 0. |
| Multi-vendor execution | Agregar sección de vendor coordination en S5 Governance. |
| Caso | Estrategia de Manejo |
|---|---|
| Gate 3 no aprobado pero el cliente necesita propuesta comercial urgente | NO generar handover completo. Generar solo S1 + S2 con disclaimer explicito de que el discovery no esta cerrado. Listar gaps pendientes como condiciones para activacion. |
| Equipo de ejecucion completamente diferente al equipo de discovery | Incluir sesion obligatoria de knowledge transfer (2-4 horas) en Sprint 0. Documentar decisiones de arquitectura con ADRs. Grabar walkthrough de entregables clave. |
| Multi-vendor execution con 3+ proveedores en el programa | Agregar seccion de vendor coordination en S5 Governance. Definir integration contracts entre vendors. Establecer single point of contact por vendor. Escalation path cross-vendor. |
| Solo se ejecuto Quick Reference (Phases 1-3-5b) sin phases intermedias | Handover simplificado: solo S1 + S2 + S6. Sin plan de 90 dias (no hay roadmap detallado). Marcar S3-S5, S7 como pendientes post-cierre comercial. |
| Decision | Alternativa Descartada | Justificacion |
|---|---|---|
| Sprint 0 de 2 semanas como buffer obligatorio antes de ejecucion | Arrancar Sprint 1 directamente post-handover | Sprint 0 valida si el plan sobrevive el contacto con la realidad. Sin setup de ambientes, onboarding y spike tecnico, Sprint 1 fracasa por impedimentos evitables. |
| Governance completa (todas las ceremonias) para equipos >5 personas | Governance ligera (solo standup + steering) | Equipos >5 necesitan estructura para coordinacion. Sin retrospectivas ni sprint reviews, el feedback loop se rompe y los problemas se acumulan silenciosamente. |
| Phase-gate funding sobre presupuesto completo aprobado upfront | Aprobacion de presupuesto total del programa desde el inicio | Phase-gate reduce riesgo financiero del cliente. Kill criteria en cada gate permiten salida controlada. Presupuesto upfront genera compromiso sin validacion de resultados. |
graph TD
subgraph Core
DH[discovery-handover]
end
subgraph Inputs
G3[Gate 3 Approval] --> DH
RDM[Solution Roadmap - Phase 4] --> DH
PITCH[Executive Pitch - Phase 5b] --> DH
STK[Stakeholder Map - Phase 0] --> DH
end
subgraph Outputs
DH --> HO[Handover Package 09]
DH --> COM[Commercial Activation]
DH --> P90[90-Day Kickoff Plan]
DH --> GOV[Execution Governance Model]
end
subgraph Related Skills
DH -.-> DO[discovery-orchestrator]
DH -.-> EP[executive-pitch]
DH -.-> PPM[project-program-management]
DH -.-> RCD[risk-controlling-dynamics]
end
Formato MD (default):
# Handover Operaciones: {project_name}
## S1: Resumen Ejecutivo de Transicion
- Estado del descubrimiento, escenario aprobado, inversion
## S2: Paquete de Activacion Comercial
- Narrativa, pricing structure, condiciones, cronograma cierre
## S3: Checklist de Readiness Operacional
- Equipo, infraestructura, accesos, documentacion
## S4: Plan de Kickoff — Primeros 90 Dias
- Sprint 0, Sprints 1-3, Sprints 4-6, metricas
## S5-S8: [remaining sections]
Formato DOCX (secondary):
Formato HTML (bajo demanda):
09_Handover_Operaciones_{project}_{WIP}.htmlFormato XLSX (bajo demanda):
{fase}_{entregable}_{cliente}_{WIP}.xlsxFormato PPTX (bajo demanda):
{fase}_{entregable}_{cliente}_{WIP}.pptx| Dimension | Peso | Criterio | Umbral Minimo |
|---|---|---|---|
| Trigger Accuracy | 10% | El skill se activa correctamente ante menciones de handover, transicion, kickoff, cierre de discovery | 7/10 |
| Completeness | 25% | Las 8 secciones cubren transicion ejecutiva, comercial, operacional, governance, y tracking | 7/10 |
| Clarity | 20% | Owners asignados a todas las tareas. Fechas absolutas. RACI de ejecucion diferenciado del de discovery. | 7/10 |
| Robustness | 20% | Kill criteria con thresholds numericos. Early warning indicators para riesgos heredados. Rollback path documentado. | 7/10 |
| Efficiency | 10% | Output proporcional al receptor (Ops, Comercial, Ambos). Sin seccion redundante con deliverables previos. | 7/10 |
| Value Density | 15% | Plan de 90 dias con actividades dia-a-dia en Sprint 0. Metricas de seguimiento con targets concretos. | 7/10 |
Umbral minimo global: 7/10. Deliverables por debajo requieren re-work antes de entrega.
| Format | Default | Description |
|---|---|---|
markdown | ✅ | Rich Markdown + Mermaid diagrams. Token-efficient. |
html | On demand | Branded HTML (Design System). Visual impact. |
dual | On demand | Both formats. |
Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.
Primary: 09_Handover_Operaciones_{project}.md (o .html si {FORMATO}=html|dual) — Executive transition summary, commercial activation package, operational readiness checklist, 90-day kickoff plan, governance transition, assumption tracker, stakeholder transition matrix.
Diagramas incluidos:
Autor: Javier Montaño | Última actualización: 12 de marzo de 2026