inbox-triage

What this skill does

# Inbox-Triage — Recurring Email Triage

> **Paired with `inbox-setup`.** This skill consumes the 7-file knowledge base that `inbox-setup` writes at `${WORKSPACE}/Email/`. The file contracts MUST match exactly. See [`references/kb_file_contract.md`](references/kb_file_contract.md) — this is the mirror of the setup-side contract, viewed from the read side.

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

Required reads at start (fail-fast if missing):

**Core (required):**
- `${WORKSPACE}/Email/email-taxonomy.md` — classification + report preferences
- `${WORKSPACE}/Email/email-patterns.md` — voice, persona, templates, hard rules

**Optional core (read if exists):**
- `${WORKSPACE}/Email/evaluation-framework.md`
- `${WORKSPACE}/Email/rate-card.md`

**Evolving (read AND update every run):**
- `${WORKSPACE}/Email/blocklist.md`
- `${WORKSPACE}/Email/tracker.md`

**Output:**
- `${WORKSPACE}/Email/triage-log/<YYYY-MM-DD>-<run-label>.md` — per-run log

If any core required file is missing → **halt**, direct user to run `inbox-setup` first. Use `scripts/kb_reader.py` to perform the read + validation.

## 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 body. Non-negotiable.

The `scripts/draft_safety_validator.py` enforces it post-run. Any send-shaped tool call in the action log fails validation. See [`references/drafts_only_safety.md`](references/drafts_only_safety.md) for the full discipline canon.

## Step 0: Grill-Me Intake (Light — 0–2 Optional Override Questions)

Inbox-triage is **light-intake by design** — it runs on a recurring cadence with preferences pre-baked into the knowledge base from `inbox-setup`. The grill-me discipline here is asking ONLY the override questions that matter THIS run.

### Q1 (optional, asked only when on-demand run is outside normal cadence)

> **Override the default 9-hour search window? Pick: yes (specify hours) / no (use default).**
>
> *Why I'm asking:* If you're running on-demand 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, asked only when user invokes with category-skip intent)

> **Skip any categories this run? E.g., "skip newsletters", "skip financial".**
>
> *Why I'm asking:* Sometimes you just want to scan opportunities or just want to clear active threads. Category skip narrows the run scope.

Skip if user gave no category-skip signal.

**Stop condition:** Max 2 questions. Default invocations skip both questions and run with KB-default preferences. The skill is optimized for fast recurring execution; intake is the exception, not the norm.

## Step 1: Determine Search Window

Compute via current date math. Default lookback: **9 hours** (works for 2x/day cadence with slight overlap so emails between runs aren't missed).

Use `scripts/search_window_calculator.py --cadence <CADENCE> --now <ISO>`:

```
now = current_datetime
window_start = now - 9_hours   (default for 2x-daily)
run_label = "Morning" if now.hour < 12 else "Afternoon" if now.hour < 17 else "Evening"
```

Cadence-to-default-window mapping (override via Q1):

| Cadence (from email-taxonomy.md S1.Q5) | Default window |
|---|---|
| once daily | 26h |
| 2x daily | 9h |
| 3x daily | 6h |
| on-demand only | 24h (asks Q1) |

## Step 2: Email Search

Two queries (provider-agnostic adapter pattern):

- **Primary:** Inbox + sent after `window_start`
- **Secondary:** Starred unread (catch flagged items missed in primary)

Collect for each email: sender, subject, date, snippet, thread ID, labels.

Provider adapter mapping:

| Provider | Tool |
|---|---|
| Gmail | Gmail MCP |
| Outlook / Microsoft 365 | Outlook MCP |
| IMAP (Fastmail, ProtonMail, etc.) | IMAP MCP if available; halt otherwise |
| (no email tool available) | Halt with clear message: "No email tool registered for this session." |

## Step 3: Classification

Apply the taxonomy from `email-taxonomy.md`. For **lowest-priority** category (newsletters / automation / spam): skip thread reads entirely — context cost not worth it. For everything else: read full thread.

## Step 4: Sender Research

For senders not in tracker / blocklist / prior logs:

1. Check `blocklist.md` → if matched, auto-skip
2. Check `tracker.md` → if known thread, note existing context
3. For opportunity senders (per evaluation framework): web search for company legitimacy, social presence, intermediary status

**Skip research entirely** for: known senders (in tracker), internal email, automated notifications, obvious low-priority.

## Step 5: Recommendations

For decision-required emails, apply the framework from `evaluation-framework.md`. Categorize:

| Category | When | Output |
|---|---|---|
| **TAKE IT** | Meets criteria | Recommend engaging; draft reply (Step 6) |
| **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: brief "why", relevant context, pricing/timeline comparison if applicable.

**Skip Step 5 entirely if no `evaluation-framework.md` exists.**

See [`references/triage_decision_framework.md`](references/triage_decision_framework.md) for the framework canon.

## Step 6: Drafts

For every reasonable reply candidate, create a draft using `email-patterns.md` 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 user already replied
- Blocked senders (unless new info changes the calculus)

**Mechanics:**

- Draft only in the existing thread when possible (preserves context)
- Set `to`, `subject` (`Re: [original]`)
- **NEVER call any send operation. Only create drafts.**

The draft body MUST honor:
- Voice register from `email-patterns.md`
- Forbidden tokens (S3.Q2 pet peeves)
- Sign-off patterns
- Persona context
- Hard rules (S3.Q6 — non-negotiable)
- Reply length per `email-patterns.md`

If `evaluation-framework.md` exists, draft tone matches 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 user's preference from `email-taxonomy.md` "Report Preferences" section. Default: email draft to self with HTML.

**Subject:** `Inbox Triage — [Day], [Month Date] ([Run Label])`

**Sections (in order):**

1. **Overview** — 2–3 sentences. What happened? 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: sender / subject / category, recommendation + reasoning, key context. **NO draft text previews** (drafts are already in email client for user to read there).
6. **Footer** — Generation timestamp + KB update summary.

**Formatting (if HTML):**

- **Inline CSS only** (Gmail strips `<style>`)
- Color-coded by recommendation:
  - green → TAKE IT
  - a