Use when the user asks to "track issues", "manage project issues", "resolve blockers", "create issue log", "remove impediments", or mentions issue tracking, issue resolution, blocker management, impediment removal, issue escalation. Triggers on: creates issue tracking workflow, assigns issue resolution owners, enforces resolution SLAs, captures root cause analysis, produces issue trend analysis.
From maonpx claudepluginhub javimontano/mao-discovery-frameworkThis skill is limited to using the following tools:
evals/evals.jsonexamples/README.mdexamples/sample-output.mdprompts/metaprompts.mdprompts/use-case-prompts.mdreferences/body-of-knowledge.mdreferences/knowledge-graph.mmdreferences/state-of-the-art.mdIntegrates Apple's FoundationModels for on-device LLM in iOS 26+ apps: text generation, @Generable structured output, tool calling, snapshot streaming.
Provides React and Next.js patterns for component composition, compound components, state management, data fetching, performance optimization, forms, routing, and accessible UIs.
Reviews Flutter/Dart code with library-agnostic checklist for widget best practices, state management patterns, Dart idioms, performance, accessibility, security, and clean architecture.
TL;DR: Implements issue tracking and resolution workflow for project issues (risks that have materialized, blockers, impediments, and problems). Establishes classification, priority assignment, resolution workflow, escalation paths, and closure criteria. Issues are risks that happened — they demand immediate action, not analysis.
Un issue no es un riesgo — es una realidad que requiere acción inmediata. La velocidad de resolución determina el impacto: un issue resuelto en 24 horas es un inconveniente; el mismo issue sin resolver en 2 semanas es un factor de fracaso. El sistema de issue management prioriza resolución sobre documentación.
/pm:issue-management $PROJECT_NAME --setup
/pm:issue-management $PROJECT_NAME --log-issue --severity=critical --category=resource
/pm:issue-management $PROJECT_NAME --report --period=sprint
Parameters:
| Parameter | Required | Description |
|---|---|---|
$PROJECT_NAME | Yes | Target project identifier |
--setup | No | Initialize issue tracking system |
--log-issue | No | Log a new issue |
--severity | No | critical / high / medium / low |
--category | No | technical / resource / scope / external / process |
--report | No | Generate issue status report |
{TIPO_PROYECTO}: Agile tracks impediments in daily standups; Waterfall uses formal issue logs; SAFe uses program-level impediment boards; All types need escalation paths.
governance-framework — confirm escalation paths and authority levels exist [PLAN]*risk-register* — identify risks that may have materialized as issues [PLAN]Good Issue Management:
| Attribute | Value |
|---|---|
| Issue template | Standardized: what, when, who, impact, category, severity [PLAN] |
| SLA compliance | 92% of issues resolved within SLA targets [METRIC] |
| Escalation path | 3-tier escalation with time triggers (24h, 48h, 1 week) [SCHEDULE] |
| Root cause analysis | Completed for all Critical and High issues [PLAN] |
| Trend analysis | Monthly report showing issue patterns by category [METRIC] |
Bad Issue Management: "We have a list of issues somewhere." — No classification, no SLAs, no assigned owners, no escalation paths. Issues languish indefinitely; critical blockers treated same as minor inconveniences.
| Resource | When to read | Location |
|---|---|---|
| Body of Knowledge | Before starting to understand standards and frameworks | references/body-of-knowledge.md |
| State of the Art | When benchmarking against industry trends | references/state-of-the-art.md |
| Knowledge Graph | To understand skill dependencies and data flow | references/knowledge-graph.mmd |
| Use Case Prompts | For specific scenarios and prompt templates | prompts/use-case-prompts.md |
| Metaprompts | To enhance output quality and reduce bias | prompts/metaprompts.md |
| Sample Output | Reference for deliverable format and structure | examples/sample-output.md |
The Issue Classifier agent triages incoming project issues by assigning a structured taxonomy across three dimensions: type (technical, resource, scope, external, organizational), severity (critical/high/medium/low), and urgency (immediate/within-sprint/within-release). This classification drives downstream routing to the appropriate resolution agents, ensures SLA compliance, and provides portfolio-level visibility into issue distribution patterns that may signal systemic risks.
## Issue Classification Report
| Field | Value |
|-------|-------|
| Issue ID | {ID} |
| Summary | {one-line description} |
| Type | {technical | resource | scope | external | organizational} |
| Severity | {critical | high | medium | low} |
| Urgency | {immediate | within-sprint | within-release} |
| Affected Components | {list} |
| Classification Rationale | {evidence-backed reasoning} |
| Routing | {next agent or action} |
| Confidence | {high | medium | low} |
### Evidence
- {evidence items with tags: [CODIGO] [CONFIG] [DOC] [INFERENCIA] [SUPUESTO]}
### Ambiguity Flags
- {any dimensions requiring human validation}
The Issue Escalation Engine agent enforces time-based escalation policies to ensure no issue stalls without visibility. It monitors issue age against severity-driven SLA thresholds — critical issues escalate after 24 hours without resolution, high after 48 hours — and routes escalations through a defined organizational path from team lead to project manager to steering committee. The agent maintains a real-time escalation dashboard, generates proactive alerts before SLA breaches, and provides decision-makers with the context they need to unblock resolution without re-investigation.
## Escalation Alert
### Issue Context
| Field | Value |
|-------|-------|
| Issue ID | {ID} |
| Summary | {one-line description} |
| Severity / Urgency | {severity} / {urgency} |
| Age | {hours/days since classification} |
| SLA Threshold | {threshold for this severity} |
| SLA Status | {breached | at-risk (X% elapsed) | within-SLA} |
### Escalation Details
| Field | Value |
|-------|-------|
| Escalation Level | {L1 | L2 | L3 | L4} |
| Escalated To | {role/name} |
| Escalated From | {previous owner} |
| Escalation Reason | {SLA breach | manual | blocker} |
### Current Status
- **Resolution Plan**: {exists/in-progress/blocked/none}
- **Blocker**: {what is preventing resolution}
- **Prior Actions Taken**: {summary of attempts}
### Decision Required
> {Specific ask: approve resource, remove dependency, make scope decision, etc.}
### Action Deadline
- **Respond by**: {date/time — typically 4h for L3+, 8h for L2}
## Escalation Dashboard (Portfolio View)
| Issue ID | Severity | Age | SLA Status | Current Level | Blocker |
|----------|----------|-----|------------|---------------|---------|
| {ID} | {sev} | {age} | {status} | {L1-L4} | {blocker} |
### Escalation Metrics
| Metric | Value |
|--------|-------|
| Active Escalations | {count} |
| Avg Time-to-Escalation | {hours} |
| L1 Resolution Rate | {%} |
| L2 Resolution Rate | {%} |
| Repeat Escalations (same root cause) | {count} |
| Top Blocker Category | {category} |
The Issue Root Cause Analyzer agent applies systematic analytical techniques — primarily the 5 Whys method and Ishikawa (fishbone) diagrams — to move beyond surface-level symptoms and identify the true underlying causes of project issues. By distinguishing proximate triggers from systemic root causes, this agent enables durable fixes that prevent recurrence rather than temporary patches that leave the organization vulnerable to repeated failures across projects and teams.
[SUPUESTO] tags.## Root Cause Analysis Report
### Issue Summary
| Field | Value |
|-------|-------|
| Issue ID | {ID} |
| Classification | {type/severity/urgency from classifier} |
| Analysis Date | {date} |
### Symptom Map
| # | Symptom | Observed By | When | Conditions |
|---|---------|-------------|------|------------|
| 1 | {symptom} | {who} | {when} | {context} |
### 5 Whys Chain
1. **Why** did {symptom} occur? → {cause 1} `[evidence tag]`
2. **Why** did {cause 1} occur? → {cause 2} `[evidence tag]`
3. **Why** did {cause 2} occur? → {cause 3} `[evidence tag]`
4. **Why** did {cause 3} occur? → {cause 4} `[evidence tag]`
5. **Why** did {cause 4} occur? → **ROOT CAUSE**: {root cause} `[evidence tag]`
### Ishikawa Decomposition
| Category | Contributing Factors |
|----------|---------------------|
| People | {factors} |
| Process | {factors} |
| Technology | {factors} |
| Environment | {factors} |
| Materials | {factors} |
| Measurement | {factors} |
### Root Cause Determination
- **Root Cause**: {statement}
- **Type**: {isolated | systemic}
- **Confidence**: {high | medium | low}
- **Counterfactual Test**: {if X had been different, would issue have occurred?}
### Recommendations
| # | Action | Scope | Priority |
|---|--------|-------|----------|
| 1 | {immediate remediation} | {this issue} | {immediate} |
| 2 | {preventive measure} | {portfolio-wide} | {within-release} |
The Resolution Plan Builder agent transforms analyzed issues into actionable, time-bound resolution plans that cover the full lifecycle from immediate containment through permanent fix and verification. Each plan assigns clear ownership, defines dependencies and blockers, establishes measurable success criteria, and includes verification steps to confirm the issue is genuinely resolved — not merely suppressed. The agent ensures every plan is realistic given current resource constraints and aligned with sprint and release cadences.
## Issue Resolution Plan
### Overview
| Field | Value |
|-------|-------|
| Issue ID | {ID} |
| Severity / Urgency | {severity} / {urgency} |
| Root Cause | {from RCA report} |
| Plan Owner | {name/role} |
| Target Resolution Date | {date} |
### Phase 1: Immediate Containment
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| {containment action} | {owner} | {hours/date} | {pending} |
### Phase 2: Root Cause Fix
| Action | Owner | Effort | Dependencies | Deadline |
|--------|-------|--------|--------------|----------|
| {fix action} | {owner} | {hours} | {deps} | {date} |
### Phase 3: Verification & Closure
| Criterion | Method | Owner | Target Date |
|-----------|--------|-------|-------------|
| {what must be true} | {how to verify} | {who} | {when} |
### Dependencies & Risks
| Dependency | Owner | Risk if Delayed | Contingency |
|------------|-------|-----------------|-------------|
| {dep} | {who} | {impact} | {plan B} |
### Timeline
Phase 1 (Containment): {start} → {end} Phase 2 (Fix): {start} → {end} Phase 3 (Verify): {start} → {end} Monitoring Period: {start} → {end}
### Closure Checklist
- [ ] Containment confirmed effective
- [ ] Root cause fix deployed
- [ ] Verification criteria met
- [ ] Monitoring period passed without regression
- [ ] Stakeholder sign-off obtained
- [ ] Lessons learned captured