Comprehensive functional specification with use cases, business rules, and complexity/risk matrix, service specification, deliverable specification, and engagement spec. Use when the user asks to "write functional specs", "document use cases", "define business rules", "create requirements", "specification document", or mentions "Phase 5a", "functional specification", "MVP scope", "acceptance criteria", "casos de uso", "reglas de negocio".
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.
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.
Generates detailed functional specifications: MVP modules, 8+ use cases with complete flows, 6+ business rules with validation logic, complexity/risk matrix, explicit scope boundaries, data model overview, integration specs, and per-module acceptance criteria.
Nota de universalidad: Este skill genera especificaciones funcionales para CUALQUIER tipo de servicio MetodologIA. Para SDA produce especificaciones de software (módulos, casos de uso, modelos de datos). Para otros tipos de servicio, adapta la estructura a los entregables propios de cada línea.
Una especificación ambigua es una promesa de retrabajo. La spec funcional es el contrato entre negocio y tecnología: cada use case define QUÉ hace el sistema, cada business rule define CÓMO decide, y cada criterio de aceptación define CUÁNDO está listo. Si no está en la spec, no se construye. Si está ambiguo en la spec, se construye mal.
$1 — MVP module count target (default: 3-5)$2 — Use case depth: actor-goal (1 page, fast) or cockburn (5+ pages, detailed; default)Parse from $ARGUMENTS. Use actor-goal for MVP speed; cockburn for critical/complex flows.
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
{FORMATO}: markdown (default) | html | dual{VARIANTE}: ejecutiva (~40% — S1 modules + S4 risk matrix + S5 scope) | técnica (full 8 sections, default){TIPO_SERVICIO}: SDA (default) | QA | Management | RPA | Data-AI | Cloud | SAS | UX-Design
Requirements:
Cannot replace:
All unvalidated business rules marked "UNVALIDATED -- requires stakeholder approval before implementation" with risk flag.
IF module has >5 use cases:
-> Create sub-module decomposition with clear ownership
IF use case has >3 primary actors:
-> Model as system use case or split into actor-specific use cases
IF use case has >10 alternative flows:
-> Break into sub-use-cases
-> Keep each use case <200 lines
IF business rule severity is CRITICAL:
-> Must have automated test in acceptance criteria
-> Cannot be waived without steering committee approval
IF integration dependency is external (3rd-party API):
-> Add SLA contract to specification
-> Identify failure modes and fallback behavior
IF no business stakeholder available:
-> Document ALL rules as "UNVALIDATED" with risk flag
-> Do not proceed to development until validation complete
| Decision | Enables | Constrains | When to Use |
|---|---|---|---|
| Cockburn use cases (5+ pages) | Deep detail, unambiguous | Time-intensive, heavy | Critical/complex flows |
| Actor-goal use cases (1 page) | Fast, scannable | May miss edge cases | MVP, simple flows |
| Natural language rules | Readable, accessible | Ambiguous | Non-technical audience |
| Pseudo-code rules | Precise, testable | Harder to read | Complex validation logic |
| 3x3 complexity grid | Forces binary decisions | Coarse | MVP prioritization |
Card grid. Per card: module name, description (1-2 sentences), key features (3+), related use case IDs, business rule IDs, complexity rating (1-5 with explanation), risk rating (1-5 with factors), upstream/downstream dependencies.
| Service Type | "Modules" Become | Examples |
|---|---|---|
| SDA | Software modules | Authentication, Payments, Notifications |
| QA | Test suites / QA workstreams | Functional Testing, Performance Testing, Security Testing |
| Management | Delivery workstreams | Sprint Management, Governance, Stakeholder Communication |
| RPA | Automation modules | Invoice Processing Bot, Data Entry Bot, Report Generation Bot |
| Data-AI | Data products / pipelines | Customer 360 Pipeline, Revenue Dashboard, Churn Prediction Model |
| Cloud | Migration workstreams / platform components | Landing Zone, CI/CD Pipeline, Monitoring Stack |
| SAS | Staffing packages | Frontend Team Package, QA Team Package, DevOps Team Package |
| UX-Design | Design deliverables | Design System, User Research Program, Prototype Suite |
Per use case structured table: ID, name (verb-noun), primary actor, preconditions, main flow (numbered steps), alternative flows (2+ per use case), exception flows (1+ per use case), postconditions, linked business rules, data entities, priority (High/Medium/Low), frequency (Daily/Session/Ad-hoc).
| ID | Rule Name | Description | Validation Logic | Severity | Module | Validation Status | Severity: CRITICAL (blocks release), HIGH (major impact), MEDIUM (nice-to-have), LOW (documentation).
3x3 heatmap. X-axis: complexity (Low/Mid/High). Y-axis: risk (Low/Mid/High). Each feature positioned with rationale. Bottom-left = quick wins first. Top-right = detailed planning + spike required.
In Scope (MVP): checklist with rationale per feature. Out of Scope (Future): explicit list with reason per exclusion. Boundary Conditions: max records/query, concurrent users, API SLA, data retention, uptime target.
Per module: Functional completeness (use cases tested, rules validated, alternative/exception flows working, data consistency). Non-functional (response time, load tested, no SPOF, audit trail). Security & compliance (auth, authz, encryption, PII handling). Quality (code review zero critical, coverage >80% unit / >70% integration). Sign-offs (business owner, QA lead, tech lead).
| Service Type | Key Acceptance Criteria |
|---|---|
| SDA | Code review passed, unit test coverage >80%, integration tests green, security scan clear |
| QA | Test case pass rate >95%, defect detection rate >85%, automation coverage >60%, zero P1 escapes |
| Management | Milestone on time, stakeholder NPS >7, team velocity stable ±10%, zero unresolved blockers |
| RPA | Bot success rate >98%, exception rate <2%, processing time within SLA, audit trail complete |
| Data-AI | Data quality score >95%, model accuracy above threshold, pipeline SLA met, dashboard adoption >70% |
| Cloud | Zero downtime migration, performance parity, security compliance verified, cost within budget |
| SAS | Position filled within SLA, ramp-up completed, stakeholder satisfaction >8/10, retention >90% at 90 days |
| UX-Design | Usability score >80 (SUS), accessibility WCAG AA compliant, design system adoption >70%, stakeholder approval |
Per entity: fields (name, type, constraints), relationships (belongs-to, has-many), lifecycle (create/update/delete conditions). Entity-to-business-rule mapping.
Per external system: endpoint, method, payload, response, SLA. Failure modes and fallback documented. Circuit breaker and retry policies.
07_Especificacion_Funcional_{TIPO_SERVICIO}_{project}.md (default) | .html (when {FORMATO}=html) | both (when {FORMATO}=dual)
| 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.
| Caso | Estrategia de Manejo |
|---|---|
| Business rules discovered during spec writing contradict rules from a prior discovery phase | Flag the contradiction with [CONFLICT] tag; document both versions; escalate to business owner with 48-hour resolution SLA; block dependent use cases until resolved |
| Service type is hybrid (e.g., SDA + Data-AI in the same engagement) | Produce separate module inventories per service type; use a shared data model section; flag cross-type dependencies explicitly in integration specs |
| Stakeholder requests >12 MVP modules ("everything is critical") | Apply the 3x3 complexity/risk matrix to force prioritization; present the top-right quadrant (high complexity + high risk) as "Phase 2" candidates; escalate if stakeholder refuses to prioritize |
| No business stakeholder available for the entire spec cycle | Mark ALL business rules as UNVALIDATED; produce the spec with [SUPUESTO] tags on every rule; add a mandatory validation sprint before development can start |
| Decision | Alternativa Descartada | Justificacion |
|---|---|---|
| Default to Cockburn use case format for critical flows | Use actor-goal format universally for speed | Actor-goal format misses alternative/exception flows, which is where 70% of implementation bugs originate; Cockburn's rigor prevents downstream rework |
| Require explicit scope boundaries (IN/OUT lists) | Allow implicit scope through use case coverage | Implicit scope invites scope creep; explicit IN/OUT lists create a contractual reference point between business and technology teams |
| Unvalidated rules carry UNVALIDATED status and risk flag | Allow unvalidated rules to proceed to development with assumptions | Building on unvalidated rules creates technical debt that compounds; the risk flag forces organizational attention on validation before investment |
graph TD
subgraph Core["Functional Specification"]
A["MVP Module Inventory"] --> B["Use Cases"]
A --> C["Business Rules"]
B --> D["Acceptance Criteria"]
C --> D
A --> E["Complexity-Risk Matrix"]
end
subgraph Inputs["Inputs"]
F["Approved Scenario"] --> A
G["Service Type"] --> A
H["Stakeholder Input"] --> C
end
subgraph Outputs["Outputs"]
D --> I["Spec Document"]
E --> J["Scope Definition"]
A --> K["Data Model + Integration Specs"]
end
subgraph Related["Related Skills"]
L["scenario-analysis"] -.-> F
M["solution-roadmap"] -.-> J
N["mermaid-diagramming"] -.-> K
end
07_Especificacion_Funcional_{tipo_servicio}_{cliente}_{WIP}.md07_Especificacion_Funcional_{tipo_servicio}_{cliente}_{WIP}.docx07_Especificacion_Funcional_{tipo_servicio}_{cliente}_{WIP}.html07_Especificacion_Funcional_{tipo_servicio}_{cliente}_{WIP}.xlsx{fase}_{entregable}_{cliente}_{WIP}.pptx| Dimension | Peso | Criterio |
|---|---|---|
| Trigger Accuracy | 10% | Descripcion activa triggers correctos sin falsos positivos |
| Completeness | 25% | Todos los entregables cubren el dominio sin huecos |
| Clarity | 20% | Instrucciones ejecutables sin ambiguedad |
| Robustness | 20% | Maneja edge cases y variantes de input |
| Efficiency | 10% | Proceso no tiene pasos redundantes |
| Value Density | 15% | Cada seccion aporta valor practico directo |
Umbral minimo: 7/10 en cada dimension para considerar el skill production-ready.
Autor: Javier Montaño | Ultima actualizacion: 15 de marzo de 2026