SuperAPI AI Directory

pm-monitor-ticket-triage

Office & productivity

View repository

Updated 10-16 00:02

About this skill

PM Monitor Ticket Triage

You run a repeatable intake-triage workflow that converts messy intake into a clear response and execution queue.

This skill can be invoked directly, or selected via the pm-monitor entry-point workflow.

Primary goal: make each item response-ready, owner-ready, and execution-ready.

Workflow

Before executing, copy this checklist and keep it updated in your working notes:

Ticket Triage Progress
- [ ] Step 1 complete: triage source and objective confirmed
- [ ] Step 2 complete: available tools and sources confirmed
- [ ] Step 3 complete: triage rubric selected
- [ ] Step 4 complete: items normalized and grouped
- [ ] Step 5 complete: missing context and blockers surfaced
- [ ] Step 6 complete: response and routing actions prepared
- [ ] Step 7 complete: closure signals and summary generated

Do not skip steps.

Step 1: Confirm triage source and objective

  1. Ask for or infer the source of intake items:
    • tracker export
    • markdown notes
    • meeting notes
    • chat/email thread
    • spreadsheet table
  2. Confirm triage objective:
    • sprint planning intake
    • urgent bug sweep
    • client feedback cleanup
    • backlog hygiene pass
  3. If .agents/project-context.md exists, read it first to align with:
    • stakeholder expectations
    • delivery phase
    • risk tolerances
    • communication style

If no source items are provided, return blocked with the minimum input needed.

Step 2: Confirm available tools and sources

Identify what triage sources are available now:

  • tracker tools (for example Jira/Linear/ClickUp)
  • communication sources (for example comments, Slack, email)
  • exported or local artifacts (markdown, CSV, docs)

If source coverage is incomplete, request the minimum structure needed:

  • item id or title
  • source text (ticket/comment/request)
  • current state/status (if known)
  • owner and due/review date (if known)

If no usable source data exists, return blocked with exact required inputs.

Step 3: Select and apply triage rubric

Use this default rubric unless the user provides another one:

  • Classification: bug, feature, task, question, dependency, change-request
  • Priority: P1 (urgent), P2 (high), P3 (normal), P4 (low)
  • Severity (for incidents/bugs): critical, major, minor, cosmetic
  • Confidence: high, medium, low
  • State recommendation: ready, needs-info, defer, escalate

Rules:

  1. Preserve source wording in raw issue descriptions.
  2. Do not invent facts.
  3. Mark unknowns explicitly as TBD.
  4. If an item is ambiguous, set confidence: low and explain why.

Step 4: Normalize items

For each item, produce a normalized record with:

  • item id (or generated local id)
  • title
  • source link/path (if available)
  • classification
  • priority
  • severity (when applicable)
  • owner (TBD if missing)
  • due/review date (TBD if missing)
  • dependencies
  • short problem statement
  • recommended next action
  • confidence

If duplicate or overlapping items are found:

  • keep one canonical item
  • list merged references
  • record merge rationale in notes

Step 5: Surface blockers and missing context

For each item, check for missing fields that block delivery:

  • no clear owner
  • no acceptance criteria
  • no reproducible steps (for bug)
  • no target date/review date
  • unclear scope boundary

Any item with missing critical fields must be marked needs-info and include one concrete follow-up question.

Step 6: Produce final triage outputs

For each ready or needs-info item, produce:

  • recommended channel (ticket comment, client update, internal note)
  • response draft (short, factual, next-step oriented)
  • task conversion decision (no-task, create-task, link-existing-task)
  • routed owner and due/review date (TBD if unknown)

Response drafting rules:

  1. Keep tone collaborative and non-defensive.
  2. State what is known, what is pending, and what happens next.
  3. If more info is needed, ask one concrete question.
  4. Do not promise timelines not supported by evidence.

Step 7: Closure and signal summary

Create closure guidance for each item:

  • Close now: enough evidence and action complete
  • Keep open: waiting on owner/input/dependency
  • Escalate: unresolved decision or high risk

Each item must end with one explicit next state.

Always produce these sections in order:

# Triage Report - <YYYY-MM-DD>

## Intake Summary
- Total items:
- By classification:
- By priority:
- Ready now:
- Needs info:
- Deferred:
- Escalated:

## Prioritized Queue
| Rank | Item | Classification | Priority | Owner | Next Action | Status Recommendation |
|------|------|----------------|----------|-------|-------------|-----------------------|
| 1 | | | | | | |

## Needs-Info Queue
| Item | Missing context | Follow-up question | Suggested owner |
|------|-----------------|--------------------|-----------------|
| | | | |

## Response Queue
| Item | Channel | Draft response | Task conversion | Assigned owner |
|------|---------|----------------|-----------------|----------------|
| | | | | |

## Deferred / Parked
| Item | Reason | Review date | Owner |
|------|--------|-------------|-------|
| | | | |

## Escalations
| Item | Why escalate | Escalation target | Decision needed by |
|------|--------------|-------------------|--------------------|
| | | | |

## Closure Signals
| Item | Recommended state | Close criteria | Next checkpoint |
|------|-------------------|----------------|-----------------|
| | | | |

Optional adapter modes

If user asks for tool-specific output, map the same triage decisions into that format without changing core logic:

  • Jira/Linear/ClickUp: status/priority fields + labels + assignee suggestions
  • Notion/Trello: board columns + card properties
  • Spreadsheet: flat CSV-style table with one row per item

Adapter rule: core triage decision quality comes first; tool formatting comes second.

Output contract

Always return:

  1. triage objective used
  2. tools and sources used
  3. rubric used (default or custom)
  4. count by recommendation (ready, needs-info, defer, escalate)
  5. top 3 items by urgency with one-line rationale each
  6. explicit list of items blocked by missing context
  7. response queue with comment drafts
  8. closure summary (close now, keep open, escalate counts)
  9. tool/data gaps that reduced confidence

Rules

  • Keep language short, specific, and operational.
  • Prefer decision-ready outputs over narrative summaries.
  • Preserve existing IDs and links when present.
  • Keep unknowns visible as TBD.
  • Never auto-close or drop items without recording where they went.
  • Treat this as a monitor/operations workflow: triage is incomplete unless response, routing, and closure intent are explicit.