inbox-triage

---
name: inbox-triage
description: Use when the user wants their inbox processed on a recurring or on-demand basis: classified, researched, drafted (never sent), and reported, after inbox-setup has run.
category: Productivity
version: 1.0.0
tools: []
---

# Inbox-Triage — Recurring Email Triage

Paired with **inbox-setup**: this skill consumes the Knowledge Base records inbox-setup produces — email taxonomy, patterns, evaluation framework, rate card, blocklist, tracker. Run on a recurring schedule (1-3x daily) or on demand. Classify recent emails, research new senders, generate decision recommendations, draft replies (**NEVER SEND**), deliver a clean report, and update the knowledge base with what was learned this run.

## Invocation Triggers

"triage my inbox," "inbox triage," "check my email," "run email triage," "process my inbox," "what's new in my email," "handle my email," "email triage."

## Prerequisites

Search the Knowledge Base at the start of every run (fail-fast if missing):

**Core (required):** Email Taxonomy (classification + report preferences), Email Patterns (voice, persona, templates, hard rules).
**Optional core (use if present):** Evaluation Framework, Rate Card.
**Evolving (read AND update every run):** Blocklist, Tracker.
**Output:** a Triage Log entry for this run, labeled by date and run.

If either core required record is missing → **halt** and direct the user to run inbox-setup first.

## DRAFTS ONLY — Never Send

**This skill creates drafts. It NEVER sends.** This is the safety property that makes the skill safe to run automatically, stated multiple times in this skill on purpose. Non-negotiable. Any send-shaped action during a run is a hard failure of the run.

## Step 0: Light Intake (0-2 Optional Override Questions)

This skill is **light-intake by design** — it runs on a recurring cadence with preferences pre-baked from inbox-setup. Ask ONLY the override questions that matter this run.

**Q1 (optional, only when an on-demand run is outside normal cadence):** "Override the default search window? Pick: yes (specify hours) / no (use default)." *Why: if you're running outside your normal 2x/day cadence, you may want a wider window (24h after a long break) or narrower (2h for a quick check).* Skip if cadence is normal.

**Q2 (optional, only when the user signals category-skip intent):** "Skip any categories this run? E.g. 'skip newsletters,' 'skip financial.'" *Why: sometimes you just want to scan opportunities or clear active threads.* Skip if no signal given.

**Stop condition:** max 2 questions. Default invocations skip both and run with the Knowledge Base defaults.

## Step 1: Determine Search Window

Default lookback is **9 hours** (works for a 2x/day cadence with slight overlap so nothing between runs is missed). Compute `window_start = now − lookback` and label the run Morning/Afternoon/Evening by current hour.

Cadence-to-default-window mapping (override via Q1): once daily → 26h; 2x daily → 9h; 3x daily → 6h; on-demand only → 24h (and asks Q1).

## Step 2: Email Search

Run two searches: inbox + sent after `window_start` (primary), and starred/unread (secondary, catches flagged items missed by the primary). Use whatever email tool is connected for this session (Gmail, Outlook/Microsoft 365, IMAP, etc.) — if none is available, halt with a clear message that no email tool is registered. Collect for each email: sender, subject, date, snippet, thread ID, labels.

## Step 3: Classification

Apply the taxonomy from the Email Taxonomy record. For the **lowest-priority** category (newsletters / automation / spam): skip thread reads entirely — the context cost isn't worth it. For everything else: read the full thread.

## Step 4: Sender Research

For senders not already in the tracker, blocklist, or prior logs: check the blocklist first (auto-skip on match), then the tracker (note existing context on a known thread). For opportunity senders per the evaluation framework, use web_search for company legitimacy, social presence, and intermediary status. Skip research entirely for known senders, internal email, automated notifications, and obvious low-priority mail.

## Step 5: Recommendations

For decision-required emails, apply the Evaluation Framework (skip this step entirely if no such record exists). Categorize each:

| Category | When | Output |
|---|---|---|
| **TAKE IT** | Meets criteria | Recommend engaging; draft reply |
| **WORTH CONSIDERING** | Has potential, needs user judgment | Surface key context; draft for user to edit |
| **PASS** | Doesn't meet criteria | Brief "why" (1-3 sentences); draft polite decline |
| **FLAG FOR REVIEW** | Unusual; needs direct user decision | Surface fully; NO draft (user decides response shape) |

Each recommendation includes a brief "why," relevant context, and a pricing/timeline comparison if applicable.

## Step 6: Drafts

For every reasonable reply candidate, create a draft using the Email Patterns voice rules. Draft for: opportunity responses (TAKE IT / WORTH / PASS), active conversations needing reply, action items, important personal emails. Do NOT draft for: clearly no-response emails (newsletters, automation, FYI), threads where the user already replied, or blocked senders (unless new info changes the calculus).

Draft in the existing thread when possible to preserve context; set `to` and `subject` (`Re: [original]`). **Never send — create drafts only.**

The draft body must honor the voice register, forbidden tokens, sign-off patterns, persona context, hard rules, and reply length from Email Patterns. If an Evaluation Framework exists, match tone to the recommendation: TAKE IT → engaged + concrete next step; WORTH → curious + 1-2 clarifying questions; PASS → polite decline + brief reason, no hedging promises; FLAG → no draft.

## Step 7: Report Delivery

Honor the user's preference from the Email Taxonomy record; default to an email draft to self. Subject: "Inbox Triage — [Day], [Month Date] ([Run Label])."

**Sections, in order:** (1) **Overview** — 2-3 sentences on what happened and anything urgent. (2) **Stats** — counts processed, drafts created, action needed, skipped. (3) **Action Needed** — overdue items, decisions, drafts to review, deadlines. (4) **Quick Reference** — one line per email, alphabetical by sender: sender, one-sentence summary, recommendation. (5) **Detailed Cards** — opportunities, active threads, flags, each with sender/subject/category, recommendation + reasoning, key context, and no draft-text previews (drafts are already in the email client). (6) **Footer** — generation timestamp + knowledge-base update summary.

If delivered as HTML: inline CSS only (Gmail strips `<style>`), color-coded by recommendation — green TAKE IT, amber WORTH CONSIDERING, red PASS, purple FLAG FOR REVIEW, blue active conversation.

## Step 8: Knowledge Base Update

**Blocklist:** append new declined senders + reason + date; append new decline patterns observed this run (e.g. "all emails containing 'looking for backend engineers' from gmail addresses → cold recruiter pattern"); remove entries the user has overridden (replied to a "blocked" sender → unblock).

**Tracker:** append new follow-ups needing future action; update existing follow-ups (deadline or status changed); mark resolved items complete; flag overdue items; remove resolved items older than 30 days; log the update.

**Learning signals to watch across runs:** drafts sent as-is vs. edited vs. deleted (tone calibration); PASS recommendations the user overrides (framework adjustment); engaged vs. ignored emails (taxonomy refinement); new decline patterns (blocklist additions). After 5+ runs, suggest knowledge-base improvements (e.g. "You always decline emails from X — add as auto-skip?").

## Step 9: Internal Log

Record for this run: emails processed with classifications, recommendations made, drafts created (with IDs/thread refs), knowledge-base updates made, follow-ups added/resolved, and notable observations. This log is the audit trail confirming no send operation occurred.

## Step 10: Empty Inbox Handling

Even with zero new emails: check the tracker for items due today or overdue, generate a minimal report ("No new actionable emails since last run"), flag any overdue items, and escalate per tracker rules. Skip drafting and research steps entirely on an empty inbox.

## Critical Rules (Stated Multiple Times)

1. **DRAFTS ONLY — NEVER SEND.** Non-negotiable.
2. **Privacy.** No passwords/credentials in the knowledge base; reference threads by ID for sensitive content.
3. **Accuracy over speed.** When unsure, flag for review — a wrong auto-draft is worse than no draft.
4. **Respect the knowledge base.** Documented preferences are source of truth; don't override with judgment.
5. **Transparency.** Note every knowledge-base change in the triage log.
6. **First runs need oversight** — set this expectation with the user.

## Error Handling

| Situation | Behavior |
|---|---|
| Required records missing | Halt; direct user to run inbox-setup |
| No email tool available | Halt with a clear message about the required tool |
| web_search unavailable for sender research | Skip research; note senders not researched |
| Draft creation fails | Skip that draft; note in log; report continues |
| User has 100+ new emails | Stay within reasonable limits; flag volume; offer to focus on priority categories only |
| Sender appears in both blocklist and tracker | Tracker wins (active conversation); note the inconsistency in the log |

## Anti-Patterns To Reject

- **Sending emails** (drafts only — non-negotiable)
- Operating without the required knowledge-base records
- Storing passwords/credentials in the knowledge base
- Skipping the learning-loop updates at end of run
- Overriding the user's documented preferences with own judgment
- Reading lowest-priority threads (waste of effort)
- Including draft-text previews in the report (drafts are already in the email client)
- Provider lock-in — support whatever email tool is actually connected
- Silently failing on missing tools