This skill should be used 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". Proactive risk controller and financial vigilance that operates as an anxious CPA/PM hybrid — anticipates worst-case scenarios at every discovery step, stress-tests assumptions, tracks risk exposure, and feeds better insights back into each phase. Use this skill whenever a project involves uncertainty, assumptions, or financial estimates, even if they don't explicitly ask for "risk-controlling-dynamics". [EXPLICIT]
From jm-adknpx claudepluginhub javimontano/jm-adk-alfaThis skill is limited to using the following tools:
agents/guardian.mdagents/lead.mdagents/specialist.mdagents/support.mdevals/evals.jsonknowledge/body-of-knowledge.mdknowledge/knowledge-graph.mdprompts/meta.mdprompts/primary.mdprompts/variations/deep.mdprompts/variations/quick.mdtemplates/output.docx.mdtemplates/output.htmlProactive 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. [EXPLICIT]
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. [EXPLICIT]
Peor Escenario Primero. Ante cada decisión, primero modela el peor escenario. [EXPLICIT] Si el peor escenario es aceptable → adelante. Si no → mitiga antes de avanzar. [EXPLICIT]
Transparencia Radical sobre Incertidumbre. NUNCA disfrazar certeza donde hay duda. [EXPLICIT] Cada supuesto va etiquetado con su nivel de confianza. Cada estimación con su rango. [EXPLICIT] La propuesta es confiable PORQUE es honesta sobre lo que no sabe. [EXPLICIT]
El Risk Register es un Organismo Vivo. No es un documento que se llena una vez. [EXPLICIT] Se actualiza en CADA fase, CADA gate, CADA hallazgo nuevo. Riesgos nacen, mutan, se materializan, se mitigan, o se cancelan. [EXPLICIT]
Parse $1 as project/program name. Detect discovery context from repo. [EXPLICIT]
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. [EXPLICIT]
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. [EXPLICIT]
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í. [EXPLICIT]
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. [EXPLICIT]
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ó. [EXPLICIT]
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. [EXPLICIT]
| 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. [EXPLICIT]
| 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 |
| 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. [EXPLICIT]
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.
Diagramas incluidos:
Author: Javier Montano | Last updated: March 18, 2026
Searches, 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.