Discovery pipeline governance — phase gate management, resource orchestration, dependency control, and proposal QA validation across the entire discovery pipeline. Replaces former project-program-management (not generic PM, specific to discovery pipeline). Use when the user asks to "track the discovery", "govern the pipeline", "validate the proposal", "run governance check", "check phase dependencies", "coordinate resources", or mentions pipeline governance, phase gates, proposal readiness, milestone tracking, or cross-phase dependency management. Works as the structural glue that holds the entire discovery pipeline together — from Phase 0 through Handover.
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/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.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Structural governance layer that manages the discovery pipeline as a formal program — tracking phases, gates, resources, dependencies, risks, and proposal readiness. Operates as the connective tissue between all 48 skills, ensuring nothing falls through cracks, phases do not skip prerequisites, and the final proposal is validated before client delivery.
Discovery without governance is improvisation disguised as methodology. This skill imposes program discipline on the pipeline: every phase has prerequisites, every gate has criteria, every deliverable has an owner and a date. It is not bureaucracy — it is the difference between "we did a discovery" and "we executed a reliable discovery program."
Governance is not bureaucracy. Governance exists to enable speed with confidence, not to slow things down. Every control must justify its existence with a risk it mitigates.
Total traceability. Every decision, scope change, materialized risk, and resolved dependency is recorded. The program can be audited at any time.
Proposal QA = Final Quality Gate. Proposal v1 does not go out until it passes a multidimensional validation that verifies technical coherence, viability, completeness, and alignment with discovery findings.
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){MODO_OPERACIONAL}: integral (default, full governance across all 7 sections) | seguimiento (phase state tracking, gate readiness, scope changes, dependency monitoring, status dashboard) | validacion-propuesta (proposal QA across coherence, completeness, viability, alignment — final quality gate)| Phase | Prerequisites | Gate | Gate Criteria | Owner |
|---|---|---|---|---|
| Phase 0: Stakeholder Mapping | Project kickoff | — | Map complete, power grid populated | Domain Analyst |
| Phase 1: AS-IS | Phase 0 complete | — | 10-section analysis delivered | Technical Architect |
| Phase 2: Flow Mapping | Phase 1 complete | — | Domain taxonomy + 8-12 flows | Domain Analyst |
| Phase 3: Scenarios | Phase 2 complete | G1 | Scenario approved by committee | Full-Stack Generalist |
| Phase 3b: Feasibility | G1 passed | 3b checkpoint | Feasibility verdict + viability scorecard | Quality Guardian |
| Phase 4: Roadmap + Cost | Phase 3b passed | — | Roadmap + cost drivers delivered | Delivery Manager |
| Phase 4b: Commercial Model | Phase 4 complete | G2 | Commercial structure approved | Data Strategist |
| Phase 5a: Functional Spec | G2 passed | — | Spec complete + use cases validated | Technical Architect |
| Phase 5b: Executive Pitch | G2 passed | G3 | Pitch approved, investment case clear | Change Catalyst |
| Phase 6: Handover | G3 passed | — | Handover package complete | Delivery Manager |
Required diagram: Gantt chart (Mermaid) with complete program timeline, gates as milestones
For each quality gate, evaluate:
Gate Evaluation Protocol:
GATE EVALUATION: {gate_name}
════════════════════════════
Phase Completing: {phase}
Date: {date}
ENTRY CRITERIA:
[ ] {criterion_1} — {status: ✅/⚠️/🔴}
[ ] {criterion_2} — {status}
...
DELIVERABLES CHECK:
[ ] {deliverable_1} — {completeness: complete/partial/missing}
[ ] {deliverable_2} — {completeness}
EVIDENCE CHAIN:
- {deliverable} → {finding} → {implication for next phase}
DEPENDENCIES RESOLVED:
[ ] {dependency_1} — {status}
RISKS CARRIED FORWARD:
- {risk_1}: {mitigation status}
VERDICT: PASS / CONDITIONAL PASS / FAIL
Conditions (if conditional):
1. {condition}
2. {condition}
Fail reasons (if fail):
1. {reason} → {remediation}
| Expert | Current Phase | % Allocated | Bottleneck Risk | Next Phase Needed |
|---|---|---|---|---|
| Technical Architect | Phase 1 | 100% | Yellow — Phase 3 needs same expert | Phase 3 (50%) |
| Domain Analyst | Phase 0 | 80% | Green — Available for Phase 2 | Phase 2 (100%) |
Required diagram: Flowchart (Mermaid) showing resource flow between phases
| Source Phase | Output | Consumer Phase | Contract | Status |
|---|---|---|---|---|
| Phase 1: AS-IS | Stack inventory | Phase 3b: Feasibility | technology_inventory.json | Delivered |
| Phase 2: Flow Mapping | Domain taxonomy | Phase 4: Cost | scope_decomposition base | Pending |
| Phase 3: Scenarios | Approved scenario | Phase 3b: Feasibility | scenario_claims.json | In Progress |
Required diagram: Sequence diagram (Mermaid) showing data flow between phases
CRITICAL SECTION — the final validator before the proposal reaches the client.
Proposal v1 is built from the outputs of Phases 4-5b. Before sending to the client, it passes through a multidimensional validation:
QA Failure Traceability to Source Phase: If a QA dimension fails, remediation is traced directly to the responsible phase(s):
5a. Technical Coherence
5b. Completeness
5c. Proposal Viability
5d. Alignment with Findings
PROPOSAL QA SCORECARD
═════════════════════
Proyecto: {nombre}
Propuesta v1 — Validación Pre-Envío
| Dimensión | Score | Hallazgos | Acción |
|---|---|---|---|
| Coherencia Técnica | [X]/5 | {findings} | {action if <4} |
| Completitud | [X]/5 | {findings} | {action if <4} |
| Viabilidad | [X]/5 | {findings} | {action if <4} |
| Alineación | [X]/5 | {findings} | {action if <4} |
COMPOSITE: [X.X]/5.0
VEREDICTO: APROBADA / APROBADA CON CONDICIONES / RECHAZADA
Threshold mínimo: 3.5/5.0 composite, ninguna dimensión <3
Condiciones (si aplica):
1. {condición}
LISTA PARA ENVÍO A CLIENTE: SÍ / NO
| Phase | Status | Planned End | Actual/Forecast | Variance | RAG |
|---|---|---|---|---|---|
| Phase 0 | Complete | Day 2 | Day 2 | 0 | Green |
| Phase 1 | In Progress | Day 5 | Day 6 (forecast) | +1 day | Yellow |
| Phase 3b | Not Started | Day 10 | — | — | Not Started |
Required diagram: Timeline/Gantt (Mermaid) with current program state
The project manager is the governance backbone that accompanies ALL prompts. It is implicitly activated in every prompt execution.
| Prompt | PM Role | Section Activated |
|---|---|---|
00-plan-discovery | Co-author: Program Charter | S1 (Charter) |
01-stakeholder-map | Receiver: RACI for tracking | S3 (Resources) |
02-brief-tecnico | Monitor: phase status update | S6 (Dashboard) |
03-asis-analysis | Monitor: dependency tracking | S4 (Dependencies) |
04-mapeo-flujos | Monitor: data contract validation | S4 (Dependencies) |
05-escenarios | Gate evaluator: G1 | S2 (Gate Management) |
06-solution-roadmap | Gate evaluator: G2, scope tracking | S2 + S4 |
07-spec-funcional | Monitor: completeness tracking | S6 (Dashboard) |
08-pitch-ejecutivo | QA validator: proposal coherence | S5 (Proposal QA) |
09-handover | Gate evaluator: G3, final QA | S2 + S5 + S7 |
revisar | Primary executor: full QA audit | S5 (Proposal QA) |
evolucionar | Re-validator: post-improvement QA | S5 + S6 |
rescatar | Triage: gate status assessment | S2 + S6 |
| Domain | Skills | Count |
|---|---|---|
| Discovery Pipeline | metodologia-discovery-orchestrator, metodologia-stakeholder-mapping, metodologia-workshop-design, metodologia-asis-analysis, metodologia-sector-intelligence, metodologia-flow-mapping, metodologia-scenario-analysis, metodologia-technical-feasibility, metodologia-software-viability, metodologia-solution-roadmap, metodologia-cost-estimation, metodologia-commercial-model, metodologia-functional-spec, metodologia-executive-pitch, metodologia-discovery-handover | 15 |
| Architecture Design | metodologia-software-architecture, metodologia-architecture-tobe, metodologia-enterprise-architecture, metodologia-solutions-architecture, metodologia-infrastructure-architecture, metodologia-devsecops-architecture, metodologia-design-system | 7 |
| Data Strategy | metodologia-data-science-architecture, metodologia-bi-architecture, metodologia-data-engineering, metodologia-database-architecture, metodologia-data-governance, metodologia-analytics-engineering, metodologia-data-mesh-strategy | 7 |
| Cloud & Mobile | metodologia-cloud-native-architecture, metodologia-cloud-migration, metodologia-mobile-platform-assessment, metodologia-finops | 4 |
| Engineering Excellence | metodologia-api-architecture, metodologia-event-architecture, metodologia-security-architecture, metodologia-performance-engineering, metodologia-observability | 5 |
| Consulting & Quality | metodologia-quality-engineering, metodologia-testing-strategy, metodologia-user-representative | 3 |
| Governance & Risk | metodologia-pipeline-governance, metodologia-risk-controlling-dynamics | 2 |
| Change Management | metodologia-change-readiness-assessment, metodologia-adoption-strategy | 2 |
| Delivery & UX | metodologia-ux-writing, metodologia-roadmap-poc | 2 |
| Delivery & Brand | html-brand, metodologia-ux-writing, metodologia-roadmap-poc | 3 |
| TOTAL | 48 |
All 48 skills have examples/ with:
sample-output.md — Reference markdown output (Acme Corp Banking Modernization)sample-output.html — Branded HTML output (Design System CSS)README.md — Asset indexLocation: plugins/metodologia-discovery-framework/skills/{skill-name}/examples/
| Decision | Enables | Constrains | When to Use |
|---|---|---|---|
| Full governance (all sections) | Maximum confidence, auditable | Overhead on small programs | Discovery >3 phases, high-stakes |
| Lite governance (S1+S2+S5) | Fast tracking | Loses detailed traceability | Discovery with 3 or fewer phases, fast-track |
| QA-only (S5) | Focused proposal validation | No tracking history | When proposal exists, need validation |
| Gate-only (S2) | Phase transition control | No resource or dependency tracking | Simple sequential pipeline |
| Scenario | Response |
|---|---|
| Discovery runs out of order (phase skip) | Flag as governance violation. Document rationale. Assess impact on downstream phases |
| Scope change mid-discovery | Impact assessment across all remaining phases. Re-estimate if >10% scope change |
| Expert unavailable for gate review | Designate alternate. If no alternate, escalate with documented risk |
| Proposal QA fails multiple dimensions | Do NOT send to client. Identify remediation per dimension. Re-run QA after fixes |
| Client requests deliverables before QA | Flag risk. Offer "draft" watermark. Never mark as final pre-QA |
| Pipeline variant = Quick Reference | Adapt to 3-phase subset. QA still mandatory for proposal |
graph TD
subgraph Core
PG[Pipeline Governance]
end
subgraph Inputs
I1[Discovery Pipeline State] --> PG
I2[Phase Deliverables] --> PG
I3[Expert Committee Roster] --> PG
I4[Scope & Timeline] --> PG
end
subgraph Outputs
PG --> O1[Program Charter]
PG --> O2[Gate Evaluations]
PG --> O3[Resource Tracking]
PG --> O4[Dependency Control]
PG --> O5[Proposal QA Scorecard]
PG --> O6[Status Dashboard]
PG --> O7[Lessons Learned]
end
subgraph Related Skills
RS1[risk-controlling-dynamics] -.-> PG
RS2[discovery-orchestrator] -.-> PG
RS3[discovery-handover] -.-> PG
RS4[cost-estimation] -.-> PG
RS5[executive-pitch] -.-> PG
end
Formato MD (default):
# Pipeline Governance: {project_name}
## S1: Program Charter & Governance Framework
### Phase Dependency Map | Decision Rights | Communication Plan
## S2: Phase Gate Management
### Gate Evaluation Protocol (G1, 3b, G2, G3)
## S3: Resource & Capacity Orchestration
### Expert Allocation | Bottleneck Detection | Skill Activation
## S4: Cross-Phase Dependency Control
### Input/Output Matrix | Data Contracts | Scope Change Log
## S5: Proposal QA Validation
### Coherencia | Completitud | Viabilidad | Alineacion | Composite Score
## S6: Status Reporting & Dashboard
### RAG Status | Milestone Tracking | Risk Burn-Down | Decision Log
## S7: Continuous Governance & Lessons Learned
### Retrospective | Governance Effectiveness | Process Improvement
Formato DOCX: Reporte de gobernanza de programa en formato documento formal: charter ejecutivo, evaluaciones de gate con firmas de aprobacion, scorecard de propuesta, y dashboard de estado con graficos de varianza y tendencia de riesgos.
Formato XLSX (bajo demanda):
{fase}_Pipeline_Governance_{cliente}_{WIP}.xlsxFormato PPTX (bajo demanda):
{fase}_Pipeline_Governance_{cliente}_{WIP}.pptx| Dimension | Peso | Criterio (7/10 minimo) |
|---|---|---|
| Trigger Accuracy | 10% | Se activa ante keywords de governance, pipeline, gate, proposal QA; no se confunde con PM generico |
| Completeness | 25% | Las 7 secciones cubren charter, gates, recursos, dependencias, QA de propuesta, dashboard, y lecciones |
| Clarity | 20% | Gate criteria, QA scorecard, y RAG status son inequivocos; verdicts son PASS/CONDITIONAL/FAIL |
| Robustness | 20% | Edge cases (phase skip, scope change, expert unavailable, QA fail) tienen protocolo definido |
| Efficiency | 10% | Modos operacionales (integral, seguimiento, validacion-propuesta) permiten activacion parcial |
| Value Density | 15% | Cada gate produce veredicto accionable; QA scorecard traza fallas a fase origen con remediacion |
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. |
| HTML | {fase}_Pipeline_Governance_{proyecto}_{WIP}.html | Mismo contenido en HTML branded (Design System MetodologIA v5). Self-contained, WCAG AA, responsive. Tipo: Dark-First Executive. Incluye Gantt interactivo de programa, gate scorecard con RAG status, y proposal QA dashboard. |
Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.
Primary: P-01_Program_Governance_{project}.md (or .html if {FORMATO}=html|dual) — Program charter, gate evaluations, resource tracking, dependency control, proposal QA scorecard, status dashboard, lessons learned.
Included diagrams:
Formerly separate sub-agents (governance-tracker, proposal-qa-validator) are now operational modes:
| Mode | Focus | Best For |
|---|---|---|
integral (default) | Full pipeline governance: charter, gates, resources, dependencies, proposal QA, dashboard, lessons learned | End-to-end discovery program governance |
seguimiento | Phase state tracking, gate readiness evaluation, scope change monitoring, cross-phase dependency control, RAG status dashboard | Ongoing governance during active discovery phases |
validacion-propuesta | Multidimensional proposal QA: technical coherence, completeness audit, viability verification, alignment with discovery findings, composite scoring and verdict | Pre-client delivery quality gate on proposal v1 |
Invoke with {MODO_OPERACIONAL}=seguimiento or {MODO_OPERACIONAL}=validacion-propuesta.