Proactive risk controller and financial vigilance — operates as an anxious CPA/PM hybrid that anticipates worst-case scenarios at every discovery step, stress-tests assumptions, tracks risk exposure, and feeds better insights back into each phase. Use when the user asks to "assess risks", "stress-test the plan", "validate assumptions", "run worst-case analysis", "check what could go wrong", "audit the discovery", or mentions risk register, contingency planning, assumption validation, exposure analysis, risk appetite, worst-case scenarios, financial controls, or "what keeps you up at night". The paranoid voice that makes the discovery reliable and the proposal trustworthy.
From pmnpx claudepluginhub javimontano/mao-pm-apexThis 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/knowledge-graph.mmdreferences/state-of-the-art.mdSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Enables 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.
Proactive risk management and financial controlling layer that operates with the mindset of an anxious CPA who also happens to be a PM: always anticipating what could go wrong, stress-testing every assumption, and ensuring that the discovery pipeline produces outputs that are trustworthy, defensible, and honest about their uncertainty.
Lo que no se anticipa, se sufre. Lo que no se controla, se pierde. Este skill opera con paranoia productiva: cada fase del discovery es una oportunidad para que algo salga mal, y este controller lo anticipa ANTES de que ocurra. No es pesimismo — es la diferencia entre una propuesta que dice "todo va a salir bien" y una que dice "sabemos exactamente qué puede fallar y tenemos plan B."
La Paranoia es una Virtud Profesional. Un controller que no está preocupado no está prestando atención. Cada entregable que se produce sin cuestionarse es un riesgo latente.
Peor Escenario Primero. Ante cada decisión, primero modela el peor escenario. Si el peor escenario es aceptable → adelante. Si no → mitiga antes de avanzar.
Transparencia Radical sobre Incertidumbre. NUNCA disfrazar certeza donde hay duda. Cada supuesto va etiquetado con su nivel de confianza. Cada estimación con su rango. La propuesta es confiable PORQUE es honesta sobre lo que no sabe.
El Risk Register es un Organismo Vivo. No es un documento que se llena una vez. Se actualiza en CADA fase, CADA gate, CADA hallazgo nuevo. Riesgos nacen, mutan, se materializan, se mitigan, o se cancelan.
Parse $1 as project/program name. Detect discovery context from repo.
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
{FORMATO}: markdown (default) | html | dual{VARIANTE}: ejecutiva (~40%) | técnica (full, default){FASE_ACTUAL}: Phase 0-6 (detecta automáticamente si no se especifica)Define the risk boundaries for this specific engagement:
| Dimensión | Apetito | Tolerancia | Umbral Inaceptable |
|---|---|---|---|
| Técnico | Aceptamos tech nuevo si PoC valida | Max 2 tecnologías sin production evidence | >3 tech sin evidence = stop |
| Timeline | +20% es aceptable | Max +40% del timeline base | >50% overrun = re-scope |
| Costo (magnitud) | +15% sobre magnitud estimada | Max +30% sobre magnitud | >40% = re-evaluate scope |
| Calidad | Entregables ≥4/5 en QA | Min 3.5/5 con plan de mejora | <3/5 = no enviar |
| Reputacional | Propuesta tiene gaps documentados | Propuesta con 1-2 gaps menores | Propuesta con claims no validados = stop |
Cada engagement calibra estos umbrales según contexto. Engagement de startup ≠ enterprise bancario.
Para CADA fase del pipeline, el controller hace preguntas incómodas:
Phase 0: Stakeholder Mapping
Phase 1: AS-IS
Phase 2: Flow Mapping
Phase 3: Scenarios
Phase 3b: Feasibility/Viability
Phase 4: Roadmap + Cost
Phase 4b: Commercial Model
Phase 5a/5b: Spec + Pitch
Phase 6: Handover
Por cada hallazgo: riesgo identificado → probabilidad × impacto → mitigación → owner → deadline.
Diagrama requerido: Mindmap (Mermaid) de riesgos por fase
Este skill es LA autoridad central de validación de supuestos del pipeline. Todos los skills de fase (asis-analysis, flow-mapping, scenario-analysis, etc.) generan supuestos — este S3 los consolida, los stress-testea, y determina cuáles DEBEN validarse antes de la propuesta. Ningún supuesto crítico debería existir sin estar registrado aquí.
Inventario de TODOS los supuestos hechos durante el discovery:
| # | Supuesto | Fase Origen | Evidencia | Confianza | Impacto si Falso | Validación |
|---|---|---|---|---|---|---|
| A-01 | "El equipo puede aprender K8s en 4 semanas" | Phase 3 | [INFERENCIA] | 40% | Timeline +3 meses | PoC Sprint 0 |
| A-02 | "El API de tercero soporta 10K rps" | Phase 2 | [DOC] vendor | 70% | Bottleneck crítico | Load test |
| A-03 | "El presupuesto cubre 18 meses" | Phase 4b | [STAKEHOLDER] verbal | 50% | Scope reduction | Confirmar con CFO |
Para cada supuesto:
Supuestos con confianza <60% y impacto alto = MUST VALIDATE before proposal.
Formato estándar del registro:
| ID | Riesgo | Categoría | Prob | Impacto | Exposure | Fase | Mitigación | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | Team sin experiencia en stack target | Organizacional | Alta | Alto | 🔴 Crítico | Phase 3 | Training + hire specialist | PM | Mitigating |
| R-02 | Vendor AI discontinua producto | Vendor | Baja | Crítico | 🟠 Alto | Phase 3b | Exit strategy + alternativa OSS | Tech Lead | Monitoring |
| R-03 | Scope creep por stakeholder no mapeado | Gobernanza | Media | Medio | 🟡 Medio | Phase 0 | Re-run stakeholder mapping | Domain Analyst | Open |
Categorías de riesgo:
Risk evolution tracking: cada riesgo tiene un historial de cómo ha mutado a lo largo del pipeline.
Diagrama requerido: Quadrant chart (Mermaid) de probabilidad vs impacto
Para cada fase crítica, ejecuta un pre-mortem:
"Es 6 meses después. El proyecto fracasó espectacularmente. ¿Qué salió mal?"
Formato de Pre-Mortem:
PRE-MORTEM: {phase/scenario}
════════════════════════════
Premisa: El proyecto fracasó. Reconstruyamos qué pasó.
CAUSA 1: {description}
Señales tempranas: {what would we see now if this were going to happen}
Probabilidad: {X}%
Cómo prevenirlo HOY: {action}
CAUSA 2: {description}
Señales tempranas: {signals}
Probabilidad: {X}%
Cómo prevenirlo HOY: {action}
...
TOP 3 CAUSAS MÁS PROBABLES DE FRACASO:
1. {causa} — Mitigación: {acción}
2. {causa} — Mitigación: {acción}
3. {causa} — Mitigación: {acción}
KILL CRITERIA (cuándo abandonar el enfoque actual):
- Si {condition_1} → pivot to {alternative}
- Si {condition_2} → escalate to {stakeholder}
Ejecutar pre-mortems en:
El CPA interior del controller:
| Control | Expected | Actual | Variance | Alert |
|---|---|---|---|---|
| Contingency vs risk exposure | 20% | 15% | -5% | ⚠️ Contingencia insuficiente |
| Innovation margin | 5% | 5% | 0% | ✅ Presente |
| Magnitude drift (Phase 3 → Phase 4) | ±15% | +35% | +20% | 🔴 Drift excesivo |
| Hidden cost drivers identified | 8+ categories | 5 | -3 | ⚠️ Revisar taxonomía |
Diagrama requerido: Flowchart (Mermaid) de controles financieros y puntos de decisión
Sintetiza todos los hallazgos en recomendaciones accionables:
3 supuestos críticos no validados
RISK CONTROLLER FINAL ASSESSMENT
═════════════════════════════════
Proyecto: {nombre}
RISK PROFILE: LOW / MODERATE / HIGH / CRITICAL
Open Risks: {N} (🔴 {n}, 🟠 {n}, 🟡 {n}, 🟢 {n})
Unvalidated Assumptions: {N} de {total}
Pre-Mortem Top Cause: {causa}
Financial Controls: {N} de {total} passing
PROPOSAL READINESS (from risk perspective):
READY / READY WITH DISCLOSURES / NOT READY
Disclosures for client:
1. {disclosure}
2. {disclosure}
Internal mitigations required:
1. {mitigation}
RED FLAGS: {count}
{flag_1}
{flag_2}
El controller de riesgos se activa en CADA fase del pipeline. Es el skill que más transversalmente opera — escanea riesgos en cada prompt ejecutado.
| Prompt | Scanning Activado | Sección del Controller |
|---|---|---|
00-plan-discovery | Risk register inicial, assumption log | S4 (Register) + S3 (Assumptions) |
01-stakeholder-map | Riesgos organizacionales, change resistance | S2 (Phase Scanning) |
02-brief-tecnico | Semáforo de riesgos técnicos | S2 + S1 (Appetite) |
03-asis-analysis | Deep scan: seguridad, deuda, observabilidad | S2 + S4 |
04-mapeo-flujos | Puntos de falla, dependencias circulares | S2 + S4 |
05-escenarios | Stress-testing de escenarios, pre-mortem | S3 + S5 (Pre-Mortem) |
06-solution-roadmap | Financial controls, magnitude drift | S6 (Financial Controls) |
07-spec-funcional | Complejidad-riesgo matrix validation | S2 + S4 |
08-pitch-ejecutivo | Proposal hardening, red lines | S7 (Hardening) |
09-handover | Risk tracker final, kill criteria | S4 + S7 |
revisar | Cross-check de riesgos en entregables | S2 + S4 |
evolucionar | Actualización de riesgos post-mejora | S4 |
rescatar | Herencia de riesgos + nuevos de rescate | S4 + S5 |
| Dominio | Skills | Riesgos Típicos |
|---|---|---|
| Discovery Pipeline (16) | discovery-orchestrator, stakeholder-mapping, workshop-facilitator, asis-analysis, dynamic-sme, flow-mapping, scenario-analysis, technical-feasibility, software-viability, solution-roadmap, cost-estimation, commercial-model, functional-spec, executive-pitch, discovery-handover, mermaid-diagramming | Scope creep, assumption drift, gate failure, evidence gaps |
| Architecture Design (8) | software-architecture, architecture-tobe, enterprise-architecture, solutions-architecture, infrastructure-architecture, devsecops-architecture, design-system, functional-toolbelt | Technical debt, vendor lock-in, scalability limits, security gaps |
| Data Strategy (7) | data-science-architecture, bi-architecture, data-engineering, database-architecture, data-governance, data-quality, analytics-engineering | Data quality, privacy/compliance, model drift, pipeline reliability |
| Cloud & Mobile (4) | cloud-native-architecture, cloud-migration, mobile-architecture, mobile-assessment | Migration risk, cost overrun, platform dependency, performance |
| Engineering Excellence (5) | api-architecture, event-architecture, security-architecture, performance-engineering, observability | Integration failures, security vulnerabilities, SLA breaches |
| Consulting & Quality (3) | quality-engineering, testing-strategy, user-representative | Coverage gaps, user adoption, testing blind spots |
| Governance & Risk (2) | project-program-management, risk-controlling-dynamics | Governance overhead, risk register staleness |
| Delivery & Brand (3) | html-brand, ux-writing, roadmap-poc | Brand inconsistency, accessibility gaps |
Cada skill tiene examples/sample-output.md como benchmark. El controller valida que los outputs producidos por cada prompt igualen o superen la profundidad del example correspondiente.
| Decision | Enables | Constrains | When to Use |
|---|---|---|---|
| Full controlling (all sections) | Maximum confidence, trustworthy proposal | Time-intensive | High-stakes, enterprise clients |
| Risk-focused (S2+S4+S5) | Key risks identified and modeled | No financial controls | Technical-heavy discoveries |
| QA-assist (S3+S5+S7) | Proposal hardening | No per-phase tracking | When proposal exists, needs hardening |
| Continuous mode (S2+S4 per phase) | Living risk register | Overhead per phase | Long-running discoveries (>2 weeks) |
| Scenario | Response |
|---|---|
| Client says "skip risk analysis" | Document the meta-risk of skipping. Flag in proposal as limitation |
| All risks are low | Suspicious. Re-examine assumptions. Low-risk assessments are often optimism bias |
| Risk register has >30 items | Prioritize top 10 by exposure. Group minor risks into categories |
| New showstopper found late in pipeline | Immediate escalation. Pre-mortem on impact. May require Phase 3b re-run |
| Magnitude drift >40% between phases | Trigger re-estimation. Flag governance violation if not addressed |
| Assumptions all have <50% confidence | Discovery findings are insufficient. Recommend additional investigation before proposal |
graph TD
subgraph Core
RCD[Risk & Controlling Dynamics]
end
subgraph Inputs
I1[Discovery Pipeline State] --> RCD
I2[Phase Deliverables & Findings] --> RCD
I3[Assumptions from All Skills] --> RCD
I4[Financial Magnitudes] --> RCD
end
subgraph Outputs
RCD --> O1[Risk Appetite Framework]
RCD --> O2[Per-Phase Risk Scanning]
RCD --> O3[Assumption Stress-Tests]
RCD --> O4[Risk Register]
RCD --> O5[Pre-Mortem Models]
RCD --> O6[Financial Controls]
RCD --> O7[Proposal Hardening]
end
subgraph Related Skills
RS1[pipeline-governance] -.-> RCD
RS2[project-program-management] -.-> RCD
RS3[cost-estimation] -.-> RCD
RS4[technical-feasibility] -.-> RCD
RS5[software-viability] -.-> RCD
end
Formato MD (default):
# Risk & Controlling: {project_name}
## S1: Risk Appetite & Tolerance Framework
### Dimensiones | Apetito | Tolerancia | Umbral Inaceptable
## S2: Per-Phase Risk Scanning
### Phase 0-6 | Preguntas Incomodas | Hallazgos (Mindmap)
## S3: Assumption Stress-Testing
### Inventario de Supuestos | Confianza | Impacto si Falso | Validacion
## S4: Risk Register
### ID | Riesgo | Categoria | Prob x Impacto | Mitigacion | Owner (Quadrant Chart)
## S5: Worst-Case Scenario Modeling
### Pre-Mortem | Top 3 Causas | Kill Criteria
## S6: Financial Controls & Magnitude Vigilance
### Contingency | Innovation Margin | Magnitude Drift | Hidden Costs (Flowchart)
## S7: Risk-Informed Recommendations
### Disclosures | Hardening | Red Lines | Final Assessment
Formato DOCX: Reporte formal de riesgos y controlling: risk register con historial de evolucion, pre-mortems documentados, controles financieros con varianzas, y assessment final con veredicto de readiness para propuesta. Formato auditable con trazabilidad de evidencia.
Formato XLSX (bajo demanda):
{fase}_risk_controlling_{cliente}_{WIP}.xlsxFormato PPTX (bajo demanda):
{fase}_risk_controlling_{cliente}_{WIP}.pptx| Dimension | Peso | Criterio (7/10 minimo) |
|---|---|---|
| Trigger Accuracy | 10% | Se activa ante keywords de risk, stress-test, worst-case, assumption validation; no ante riesgo tecnico puro |
| Completeness | 25% | Las 7 secciones cubren apetito, scanning por fase, supuestos, register, pre-mortem, financiero, y hardening |
| Clarity | 20% | Risk register usa formato estandar con categorias; pre-mortem tiene causas y kill criteria explicitos |
| Robustness | 20% | Edge cases (skip risk, all-low, >30 risks, late showstopper, drift >40%) tienen respuesta definida |
| Efficiency | 10% | Modos (full, risk-focused, QA-assist, continuous) permiten activacion proporcional al contexto |
| Value Density | 15% | Cada seccion produce acciones concretas: mitigaciones con owner, validaciones requeridas, red lines |
Umbral minimo: 7/10 en cada dimension. Composite ponderado >= 7.0 para considerar el output aceptable.
| Format | Default | Description |
|---|---|---|
markdown | Yes | 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: P-02_Risk_Controlling_{project}.md (o .html si {FORMATO}=html|dual) — Risk appetite, per-phase scanning, assumption stress-tests, risk register, pre-mortems, financial controls, proposal hardening.
| HTML | {fase}_Risk_Controlling_{proyecto}_{WIP}.html | Mismo contenido en HTML branded (Design System MetodologIA v5). Self-contained, WCAG AA, responsive. Tipo: Dark-First Executive. Incluye risk register interactivo con quadrant chart probabilidad/impacto, assumption tracker con niveles de confianza, y final assessment con proposal readiness. |
Diagramas incluidos:
Autor: Javier Montaño | Última actualización: 12 de marzo de 2026