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
- Ask for or infer the source of intake items:
- tracker export
- markdown notes
- meeting notes
- chat/email thread
- spreadsheet table
- Confirm triage objective:
- sprint planning intake
- urgent bug sweep
- client feedback cleanup
- backlog hygiene pass
- If
.agents/project-context.mdexists, 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:
- Preserve source wording in raw issue descriptions.
- Do not invent facts.
- Mark unknowns explicitly as
TBD. - If an item is ambiguous, set
confidence: lowand 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 (
TBDif missing) - due/review date (
TBDif 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 (
TBDif unknown)
Response drafting rules:
- Keep tone collaborative and non-defensive.
- State what is known, what is pending, and what happens next.
- If more info is needed, ask one concrete question.
- 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:
- triage objective used
- tools and sources used
- rubric used (default or custom)
- count by recommendation (
ready,needs-info,defer,escalate) - top 3 items by urgency with one-line rationale each
- explicit list of items blocked by missing context
- response queue with comment drafts
- closure summary (
close now,keep open,escalatecounts) - 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.