triage-task-prioritization-x-5

---

name: Triage / Task Prioritization slug: triage version: 1.0.3 description: >- Prioritizes competing tasks into P0-P3 by cost of delay and decides what to do first, what waits, and when to interrupt current work. Use when tasks pile up or everything feels urgent, when a request arrives mid-task, when triaging bugs, tickets, alerts, or a backlog after time away, when deadlines conflict or slack runs out, or when the user says urgent, ASAP, EOD, drop everything, or no rush. Learns the user's real priority rules from their corrections and reorders. Not for effort estimation or roadmap planning. homepage: https://clawic.com/skills/triage changelog: "Display name shown correctly" metadata: clawdbot: emoji: 🚦 displayName: "Triage / Task Prioritization" configPaths: ["~/Clawic/data/triage/"]

---

Classify incoming work into P0-P3 by cost of delay, route it, and learn the user's real priority rules from their corrections. Learned rules and stated preferences persist in ~/Clawic/data/triage/ (created on first confirmed rule or stated preference; nothing is stored without the user's explicit yes). If you have data at an old location (~/triage/ or ~/clawic/triage/), move it to ~/Clawic/data/triage/.

When To Use

• Several tasks compete and you must pick an order
• A new request arrives mid-task and you must decide whether to interrupt — and how to switch safely
• A pile needs sorting: an inbox after time away, an ungroomed backlog, a ticket queue
• A bug, ticket, alert, or security report needs a priority, not just an acknowledgment
• The user uses priority language: "urgent", "ASAP", "drop everything", "no rush", "when you have time"
• The user reorders or overrides your queue — that is training data, not just an instruction
• Not for effort estimation or roadmap planning: triage decides when, not how long

Quick Reference

Situation	Play
"Drop everything and X"	Interrupt now, but name what gets paused: "Pausing Y (was P1) — resume after?"
Two tasks both claim P0	Escalate sequencing to the user — two "drop everything" cannot both be true
Must interrupt mid-task	Park first: resume note + WIP preserved, then switch (interrupts.md)
Sounds urgent, but no deadline and no accumulating damage	Cap at P1; one closed question: "Is anyone blocked right now?"
Mixed signals ("urgent but no rush")	Ask — the contradiction is the signal; never average to P1.5
Deadline exists but looks far	Compute slack (Core Rules #2); slack under one working day → P1 today
Deadline looks fake or negotiable	Find what consumes the output — the real deadline hides behind the stated one (deadlines.md)
Slack already negative	Negotiate scope → sequence → time, in that order (deadlines.md)
Bug or ticket arrives	Severity ≠ priority: score severity × reach × trend (bugs.md)
Pile of unsorted items (post-vacation, backlog)	Two-pass sweep: classify all, then order; newest-first for old piles (batch.md)
User corrects your priority	Record it; on the 2nd same-direction correction, propose a standing rule (patterns.md)
Confirmed rule matches a new task	Apply it and cite it: "Deploy issue → P0 (your standing rule)"
New fact arrives (deadline revealed, blocker cleared, scope change)	Re-triage the whole queue, not just the new item
Else	Run the level tests below top-down; torn between adjacent levels → Core Rules #3

Depth on demand: signals.md reading urgency language, senders, sources · patterns.md learning protocol and memory format · interrupts.md switching safely, parking, stacked P0s · batch.md sweeps, piles, grooming, overflow · deadlines.md slack cases, real vs stated, negotiation · bugs.md bug, ticket, SLA, and alert triage.

Priority Levels

Each level has a boundary test. Run the tests top-down; first yes wins. Test states, not tone.

Level	Test (yes → this level)	Response	Examples
P0	Does damage accumulate every minute this waits?	Interrupt current work now	Production down, active breach, data loss in progress
P1	Is a person or deliverable stalled today?	Next work-unit boundary, same day	Blocked teammate, client waiting, due-today deadline
P2	Dated or clearly valuable, but nobody stalls today?	Scheduled queue, with a date	Reviews, planning, deadlines beyond today
P3	Would anyone notice if this never happened? (barely)	Backlog, batch-processed	Ideas, "someday", minor optimizations

Core Rules

1. Priority = cost of delay, never effort or loudness. A hard task nobody waits on is P2; a 5-minute unblock for a stalled teammate is P1. Tie-break within a level: highest cost of delay per unit of effort first (WSJF, Reinertsen); when costs look equal, shortest job first.
2. Deadline urgency is slack, not calendar distance. Slack = working time until deadline − remaining work, counted in working_hours only. Friday deadline + 3 days of work, seen on Wednesday = negative slack = P1 today. A Monday-9am deadline seen Friday afternoon has near-zero slack. Recompute whenever scope grows; edge cases (timezones, dependency chains) in deadlines.md.
3. Misclassification is asymmetric — up is cheap, down is expensive. A false P0 costs one interruption; a missed P0 costs the whole damage window. Torn between adjacent levels with concrete urgency evidence → take the higher. No evidence, just tone → take the lower and label it: "Queued as P2 — say the word if it's blocking."
4. Ask only at the P0/P1 boundary. One closed question there beats a wrong guess. At P2/P3 the stakes don't cover the interruption cost — pick, state the assumption, move on.
5. Learn only through the ladder: observe → propose → confirm. One correction = record. Two same-direction corrections = propose ("Should deploy issues always be P0?"). Apply automatically only after an explicit yes, and cite the rule when applying it. Never silently internalize — full ladder and decay in patterns.md.
6. P0 is rare by construction. If over a week more than ~1/3 of items land P0/P1, the bar drifted — re-anchor on the level tests instead of inventing intermediate levels. When everything is urgent, nothing is.
7. Re-triage on state change, not on a timer. Triggers: deadline revealed or moved, blocker cleared, scope change, new P0. Each one re-sorts the whole queue; a queue sorted on stale facts is a wrong queue.

Queue Discipline

• P0 interrupts mid-task (interrupt_floor in config can extend this to P1). P1 waits for the current unit of work to finish — dropping a half-done change leaves broken state, which is its own incident. Exception: if current work is P2/P3, switch at the next safe point. Switching mechanics — parking note, resume protocol, stacked P0s: interrupts.md.
• Order within a level: confirmed user rules first, then ascending slack, then arrival order.
• Announce changes, not steady state: "New P0 — pausing X. Queue now: [incident, review, docs]." Silent reshuffles destroy the user's trust in the queue; verbosity is announce_style in config.
• A dated P2 gets scheduled the moment it enters the queue. A P2 that "ages into" a P0 was a triage failure, not an escalation — log it as a correction against yourself.
• When the queue exceeds capacity, triage becomes explicit rejection — propose drops by name, never silent starvation (batch.md, Overflow).

Output Gates

Before emitting a priority or a reordered queue:

• Is every P0 justified by accumulating damage or a level test — not by tone, caps, or sender seniority?
• Did I check ~/Clawic/data/triage/patterns.md for a confirmed rule before falling back to defaults?
• Am I auto-applying any rule the user never confirmed? If yes → propose instead.
• If queue order changed, did I say so and name what got bumped?
• If I am about to interrupt current work, does the paused task have a resume note (interrupts.md)?

Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in ~/Clawic/data/triage/config.yaml.

Variable	Type	Default	Effect
working_hours	text (e.g. "Mon-Fri 09:00-18:00")	Mon-Fri 09:00-18:00	The hours slack counts (Core Rules #2); changes every deadline-driven level
triage_mode	interrupt | batch	interrupt	batch defers non-P0 classification to scheduled sweeps (batch.md); paging-grade sources still push through
interrupt_floor	P0 | P1	P0	Lowest level allowed to interrupt mid-task; P1 relaxes the wait-for-boundary rule in Queue Discipline
sweep_times	list of times	none	With triage_mode: batch: when sweeps run; empty = sweep on request
announce_style	full | minimal	full	full names every bumped item on reorder; minimal reports only the new top of the queue

Preference areas — customizable dimensions; a stated preference gets recorded in config.yaml and applied:

• Labels: reporting scheme (P0-P3, High/Normal/Low, MoSCoW) — affects how levels are announced, never the level tests
• Risk posture: tie-break direction when torn without evidence — affects the default-down in Core Rules #3
• Sources: which channels count as paging-grade vs digest — overrides rows in signals.md Source Defaults
• Cadence: grooming day, drift-check day, aging thresholds — affects the weekly routines in batch.md
• Escalation: whether the P0/P1 question goes to the user or a named delegate — affects Core Rules #4

Traps

Trap	Why it fails	Do instead
Sender rank as urgency	An exec's "someday idea" outranks nothing; rank predicts importance, not cost of delay	Run the level tests; if the user consistently overrides for a sender, learn that as a rule
Severity as priority	A crash in a feature nobody uses outranks nothing; impact alone misorders the queue	Score severity × reach × trend (bugs.md)
Newest-task pull	Recency feels urgent; arrival time is not cost of delay	Slot by test result, re-sort, report the position
Doing work mid-triage	Each "quick fix" during a sweep restarts its context; the pile outlives the morning	Classify everything first, then work the ordered queue (batch.md)
Averaging mixed signals	"Urgent but no rush" averaged to P1.5 satisfies neither reading	Ask — the contradiction is the signal
Escalating on repetition	A third mention is frustration, not new urgency	Acknowledge, give queue position and expected start
Demoting polite requests	"Whenever you get a chance" from some users means "today"	Check for a date before demoting; calibrate per sender (signals.md)
Rolling a passed date forward	A silently moved date is a decision hidden from the user	Re-triage the item the day its date passes (batch.md)

Where Experts Disagree

• Interrupt-driven vs. batch triage. Batch (fixed triage passes) wins when true P0s are rare and deep work dominates; interrupt-driven wins for on-call contexts. Pick per user context, tell the user which mode you're running, and record it as triage_mode.
• FIFO vs. WSJF within a level. FIFO is predictable and reads as fair to requesters who watch the queue; WSJF delivers more value when only outcomes are visible. Perceived fairness is a real cost — choose by who is watching.

Related Skills

More Clawic skills, get them at https://clawic.com/skills/triage (install if the user confirms):

• task-list — maintaining the queue itself once triage has assigned levels
• incident-response — when a P0 is a production incident: triage decides the interrupt, that skill runs the handling
• time-blocking — protecting focus time that P2/P3 must not interrupt
• inbox — processing message streams before items become triaged tasks

Feedback

• If useful, star it: https://clawic.com/skills/triage
• Latest version: https://clawic.com/skills/triage

Part of Clawic, the verified skill library. Get this skill: https://clawic.com/skills/triage.