- name
- codexkit-inbox-priority-triage
- description
- Triage email, Slack, ticket, or shared request backlogs into priority buckets, owners, and next actions. Use when the work is repetitive queue handling, intake cleanup, or response sorting. Do not use for strategic decisions, policy interpretation, or substantive contract review.
- version
- 1.0.0
- category
- automation
# Inbox Priority Triage
## Purpose
Turn a messy request backlog into a short, actionable queue.
## When to use
- an inbox or request list needs fast prioritization
- requests arrive in different formats and need one view
- a manager needs owners and next actions, not long summaries
## When not to use
- the user needs deep analysis or a recommendation memo
- the queue contains legal, finance, or policy work that needs expert review
## Inputs
- source inbox, backlog, or copied request list
- priority rules or SLA if available
- known owners, teams, or routing lanes
## Procedure
1. Normalize each item into request, owner, due date, and current state.
2. Group duplicates and merge obviously repeated asks.
3. Sort into priority buckets such as urgent, this week, waiting, and archive.
4. Flag missing owner, missing deadline, or missing context.
5. End with a short next-action queue.
## Output
- prioritized request list
- owner and due-date gaps
- next actions by person or lane
## Definition of done
- the queue is shorter and easier to act on
- duplicates and stale items are collapsed
- every urgent item has an owner or a routing gap called out
## Examples
- "Sort this shared inbox into urgent, this week, and waiting."
- "Clean up this backlog of internal requests and tell me who should take each one."
## Quality Criteria
- [ ] Trigger conditions and input requirements are unambiguous
- [ ] Each automated step produces a verifiable output
- [ ] Error handling and fallback paths are defined
- [ ] Manual override points are documented
## Verification (4C)
| Check | Question |
|-------|----------|
| **Correctness** | Does the workflow produce the expected output for the defined inputs? |
| **Completeness** | Are all trigger conditions, edge cases, and error paths handled? |
| **Context-fit** | Is the automation appropriate for the frequency and criticality of this task? |
| **Consequence** | If this ran unattended and failed silently, what would the downstream impact be? |
## Edge Cases
- **Input format varies unexpectedly** — Add a normalization step at entry. Alert the operator on format mismatches.
- **Downstream system is unavailable** — Queue the output and retry with exponential backoff. Alert after N failures.
- **Partial execution completes** — Ensure idempotency — re-running from the start produces the same result without duplication.
## Changelog
- v1.0.0 — Initial release
View on GitHub