inbox-info

What this skill does

# Inbox Information Research

## Overview

The user reads email with NeoMutt against a Maildir indexed by `mu`
(maildir-utils). This skill wraps `mu find` / `mu view` to answer questions
about the inbox without scanning Maildir files directly. It also helps
convert flagged emails into themed `nytid todo` items.

**Canonical "needs handling" signal:** the user **flags** every email they
need to act on (the `\Flagged` / "starred" IMAP flag). Default to
`flag:flagged` for triage queries — not `flag:unread`.

This skill is **strictly read-only**: query `mu`, suggest `nytid todo`
commands, and let NeoMutt own flag/state changes.

## Known Setup

Embedded so the skill activates with zero tool calls. Re-verify with
`mu info` only if a query misbehaves.

- **Maildir+ account root** (use with `mu` — it indexes the whole tree):
  `/home/dbosk/mail/kth`
- **Key leaf folders** — encode the lifecycle of a message, not just
  routing:
  - `INBOX/` — **waiting / not yet processed**. Unread mail lives here
    by definition; flagged mail here is *active work*. **For triage,
    this is the folder to target.**
  - `Processed/` — **done**. Messages the user has handled and moved
    out of INBOX. The user *intentionally keeps flags here* — a flag
    in Processed means "I had to act on this", retained as a labeled
    signal for tuning `~/.muttrc.scores` and spotting patterns. **Do
    not** treat them as actionable triage items, but **do not** ignore
    them as noise either — they're training data.
  - `Processed-archived/` — **archived, not interesting**. Older
    Processed mail. Even less relevant than `Processed/` for triage.
- **Xapian DB**: `/home/dbosk/.cache/mu/xapian`
- **Verified**: 2026-05-27

The account root contains subfolders (`INBOX/`, `Sent/`, `Archive/`,
`Processed/`, `Processed-archived/`, etc.) but no `cur/new/tmp` of its
own. Pointing `neomutt -f` at the root opens the folder browser, not
messages — limits then filter an empty set. Always target a specific
leaf for mutt.

**Implication for triage queries:** unread mail = "waiting to be
processed" (the user moves mail to `Processed/` when done; unread mail
still in INBOX is therefore by-definition actionable). Old unread mail
in INBOX is *stale* — never got around to it. Flagged mail in
`Processed/` is *not* a triage target — it's done — but it *is* a
historical record of "things that needed action", deliberately
retained for score-tuning. Use the user's flag-discipline to your
advantage:

- **Flag-cleared anywhere** = "I didn't have to act on this" (FYI/noise).
- **Flagged in INBOX** = "this needs action, still pending".
- **Flagged in Processed/** = "this needed action and is now done"
  (labeled training point).

**Lazy fallback — call `mu info` only if:**
- a query returns unexpectedly zero results,
- the user reports the index seems stale,
- or `mu find` errors out.

## Research Workflow

### Step 1: Pick the right query

| Question | Query |
|----------|-------|
| "What needs handling?" | `mu find 'flag:flagged' --fields 'd f s' --sortfield date --reverse` |
| "What's been flagged forever?" | `mu find 'flag:flagged AND date:..1m' --fields 'd f s' --sortfield date` |
| "Recent from X?" | `mu find 'from:NAME date:1m..' --fields 'd f s' --maxnum 20` |
| "Anything on topic Y?" | `mu find 'subject:Y OR body:Y' --threads --fields 'd f s'` |
| "How many of Z?" | `mu find QUERY --fields i \| wc -l` |
| "Show me message N" | `mu view <path>` (path from `--fields l`) |

Bound output: always use `--maxnum N` and `--fields` to keep results compact.

### Step 2: Classify against the user's taxonomy

The authoritative classifier lives in `~/.muttrc.scores`. For the full
extracted taxonomy — every category regex, every high-signal sender,
every noise filter — see
`references/muttrc-scores-taxonomy.md`. Read it when classification is
non-trivial or when the user updates their scoring config.

The common categories (priority order) are:

| Category | Subject regex | Notes |
|----------|---------------|-------|
| **Missing grades / Ladok** | `ladok\|betyg\|tillgodoräk` | **First-class — always its own bucket** |
| Urgent | `brådska\|bråttom\|urgent\|viktig\|important` | |
| TA management | `assning\|asse\|assistent\|\bTA\b` | |
| Course operations | `kompletter\|examin\|rättning\|redovis\|labb?\|rapport\|rest(er\|labb\|uppgift\|inlämn)` | grading, make-ups, lab reports |
| Course analysis / PM | `(kurs)?.?(analys\|PM\|pm\|utvärdering)` | |
| Timesheets / pay | `tidrapport\|timersättning\|timesheet\|lön\|timmar\|arvode` | |
| Sick / personal | `sjuk\|sick\|\bill\b` | |
| Reviewing | `reviewer.*invitation\|invitation.*reviewer` | |
| Scheduling | from `[email protected]` or `@timeedit.com` | |

**Course codes** to recognize:
- DD1301 (`datorintro`/`dataintro`)
- DD131[057] (`programmering`/`prg`)
- DD1320 (`tilda`)
- DD1337 (`inda`)
- DD2520 (`tilkry`/`tillkry`)
- DA2215, DD2302 (`vetcyb`, science/security)
- DA150X (`dkex`/`dkand`/`kex`, bachelor thesis)
- DA231X (`exjobb`, master thesis)
- LH219V (pedagogy)

**Programme tags** to recognize: `CINEK|CMAST|CITEH|CDATE|CFATE|CTMAT|CTFYS|CLGYM`.

**High-signal senders** (from `~/.muttrc.scores`): Celina Soori, Yara Faris,
Yasmina Altayy, Liisa Wettemark, Edita Korlat, Francisco Gomes, Bedour
Alshaigy, plus institutional addresses (`[email protected]`,
`[email protected]`, `[email protected]`, etc.). When a
flagged email is from one of these, give it its own cluster.

**Known noise** (excluded from triage even if flagged): Google Scholar,
KTH Magazine, IEEE, ACM, SIAM, Nature Briefing, The Download, KTH Alumni,
etc. — see negative scores in `~/.muttrc.scores`.

### Step 3: Handle ambiguous subjects (students often write bad ones)

Many emails arrive with vague subjects: "Hi", "Hej", "Question", "Help",
"Course", a bare first name, or just a course code. Don't trust subject
regex alone. Two-tier approach:

1. **Subject regex first** (cheap) — sort flagged emails into the
   obvious buckets.
2. **Body query for ambiguous matches**:
   `mu find 'flag:flagged AND body:/ladok|betyg/' --fields 'd f s'`
   catches grade-adjacent emails whose subjects don't mention grades.
3. **Read the full message** with `mu view <path>` only for the
   borderline cases — never as a default step.
4. If still unclassified, put it in a residual **"uncategorized flagged"**
   group rather than forcing a wrong bucket.

### Step 4: Group flagged emails into themed todos

When the user asks for todos from flagged email, propose **themed batches**
— never one todo per message. Cluster by category, course code, sender, or
topic, then suggest one `nytid todo add` per group.

For the full rules with rationale and worked examples, see
`references/todo-conversion-rules.md`. Headlines:

- **NEVER use `--who dan-claude`.** Email-derived todos are for the user
  themselves. dan-claude doesn't answer the user's email. Omit `--who`
  entirely so the default (current user) applies.
- **Missing grades is always its own group**, separate from other course
  traffic, even when only 1–2 messages match.
- **Every todo description must embed a review command** so the user can
  re-open the relevant emails with one paste.

### Step 5: Choose the right review-command form

Two forms. Default to **Form A** unless you specifically need mu's richer
query language for read-only browsing.

**Form A — mutt `limit` on the real Maildir (DEFAULT).** State changes
(mark read, reply, unflag) persist to the real inbox:

```
neomutt -f /home/dbosk/mail/kth/INBOX \
  -e 'push "<limit>~F ~s \"betyg\\|ladok\\|grade\"<enter>"'
```

Note `INBOX`, not the account root — see "Known Setup" above.

Mutt patterns: `~F` flagged, `~s "regex"` subject, `~b "regex"` body,
`~f "regex"` from, `!~s "regex"` negation. Combine with space (AND) or `|` (OR
within a single regex). **Date filters**: `~d "<3m"` newer than 3 months ago
(within last 3 months), `~d ">3m"` older than 3 months ago. Offsets: `d` day,
`w` week, `m` mo