---
name: attention-digest
description: On-demand inbound triage — scan the owner's live comms (mail, chat, calendar, meetings, expense) and return "what needs me" ranked into four buckets (Needs you now · Hanging · Direct-report watch · Worth knowing), read-only, then write a dated note and deliver the brief (in chat; by email where a mail send is configured). Use when the owner says "what needs me", "what's on fire", "triage my inbox / my attention", "what am I missing", or "who's waiting on me". NOT the scheduled morning digest (that's the outbound daily digest / the digest-now skill), and NOT for filing pasted content (vault-ingestion). Requires the attention-digest module.
served: true
---

# Attention Digest — on-demand "what needs me"

The **inbound** counterpart to the morning digest. The daily digest reads the *vault* and pushes the day's plan out; this reads the owner's **live comms** and pulls in what needs a response — on demand. It is **read-only** over every source: it never replies, archives, marks-read, or otherwise mutates a source.

The egress rules are canonical in `AGENTS.md`; this skill is the trigger and the procedure.

**Two surfaces, don't confuse them.** This skill is the **on-demand brief** — you run it in-session over the connected MCP connectors and return the four-bucket read. The module *also* ships an **automatic engine**, `alexandria_vault.engine.attention_digest` (in the installed package), which the runner schedules: it reads the owner's inbound **email** over IMAP and *files* the commitments it finds as `- [ ]` todos in the right area TODO (then writes a dated note + emails the owner). That engine is the scheduled email→todo path; this skill is the interactive triage. They share the `attention_digest` config and the `type: attention-digest` dated note.

## When this skill fires
The owner asks, in chat, some form of *"what needs me right now / what's on fire / triage my attention / what am I missing / who's waiting on me."* It is **on-demand and owner-only** — never scheduled, never sent to anyone but the owner.

## Sources — config-driven, probe before use
1. Read `config.attention_digest.sources` (default `["mail", "calendar"]`). Allowed: `mail · chat · meetings · calendar · expense`. This is what lets a deployment swap Slack→Teams or one expense tool for another — the buckets never hardcode a vendor.
2. For each configured source, **probe for that surface's MCP tools in this session and prefer what resolves** (the same rule as AGENTS "Transports"): mail → the Gmail/mail connector; chat → Slack/Teams; calendar → the calendar connector; meetings → the meeting-notes tool; expense → the expense tool. A configured source whose tools don't resolve is **skipped with a one-line note** ("chat: no connector available"), never an error.
3. Look back `config.attention_digest.lookback_hours` (default 48). **Read only** — pull recent items; change nothing.

## Rank into four buckets
Consult the owner-tunable rubric in **`Agent/Attention Digest Prompt.md`** (its fenced block; if that note is missing or empty, use the defaults here). Sort every surfaced item into exactly one bucket, and drop pure noise:
- **Needs you now** — time-sensitive AND the owner is the blocker: a direct ask with a near deadline, an approval gate, an escalation. Lead here.
- **Hanging** — threads awaiting the owner or stalled: unanswered questions *to* the owner, promises the owner made, replies overdue back to the owner.
- **Direct-report watch** — items involving the owner's reports. Draw the roster from `config.attention_digest.watch` if set, else the `team` roster (`config.team[].name`): what a report is blocked on, asked for, or flagged.
- **Worth knowing** — FYI: informational, already-handled, or low-urgency context the owner would want to have seen.

Keep each item to one tight line — *who · what · why it matters · the single next action* — with a `[[link]]` to the person or area home. Prefer recency and the owner's direct involvement.

## Confidentiality — the hard rule
- Vault subjects must never be transmitted to an **external** surface (a web / search / enrichment call) without the owner's say-so. Reading the owner's own mailbox is fine; enriching a private subject against the open web is not.
- The digest is **owner-only** — write it to the vault and send it only to the owner's own address (`config.attention_digest.to`, else `owner.emails[0]`). Never to a team member or any non-owner recipient.

## Output
1. **Write a dated note** — `Daily/YYYY-MM-DD Attention Digest.md` (frontmatter `type: attention-digest`, `date`, `tags: [attention-digest]`), the four buckets as `###` sections, each item linked to its home. It is a **view, not a home**: don't duplicate canonical tasks/facts. Where an item implies an action, point at — or, on the owner's OK, add to — the relevant `<Area> TODO.md` rather than restating it here. One commit.
2. **Send it to the owner** — email the four-bucket brief to the owner via the mail connector (owner address only). If no send tool resolves, present it in chat and say so.

## Scope — read-only, inbound, owner-only, by design
This skill only **reads** comms, **writes** one vault note, and **delivers to the owner** (chat, or their own address). It never replies to or mutates a source, and never sends to a non-owner. It is **on-demand** — the *scheduled* email→todo pass is the module's `attention_digest.py` engine, not this skill. It does not file pasted content — that's `vault-ingestion`.
