# Admin Digest > The Admin Copilot's morning briefing — a chief-of-staff digest unifying today's calendar and meeting prep, an inbox triage summary with propose-then-confirm actions, new competitor deltas, and stale follow-ups. Use when producing the daily/morning admin digest or chief-of-staff briefing, or when the morning digest schedule fires. - Skill: `vellum-ai/admin-digest` (Agent Skill) - Install (CLI): `npx skillmds@latest add vellum-ai/admin-digest` - Raw SKILL.md: https://api.skillmd.com/api/skills/vellum-ai/admin-digest/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: vellum-ai (https://skillmd.com/u/vellum-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vellum-ai/admin-digest --- # Admin Digest A sharp, scannable morning brief from a chief of staff. Build only the sections you have something useful to say about; cut the rest. Bullets, not paragraphs. This is a read-and-summarize pass — it **proposes**, and mutates the inbox only when the user approves a proposed batch (see §3; the heavy lifting still lives in `inbox-management`'s confirmed pipeline). For the general briefing tone and the weather/news/"something interesting" sections, `start-the-day` is included; this skill adds the admin spine on top. Read delivery preferences once via `admin_copilot_prefs` `get_prefs` (`digest.channel`) — the tool comes from the included `admin-copilot-prefs` skill and is called through `skill_execute` — and deliver there: `in-app` → reply directly; `slack` / `email` → hand off to the relevant channel skill. > **If `skill_execute` reports `admin_copilot_prefs` as unknown or not > allowed,** the `admin-copilot-prefs` skill has not projected into this > session — `get_prefs` will not become reachable by exploring. Try > `skill_load` with `skill: "admin-copilot-prefs"` once; if it still fails, do > **not** search the filesystem for a prefs file or read it by hand. Default > delivery to `in-app`, skip the competitor section (§5), add a one-line note > ("admin-copilot prefs unavailable — using defaults"), and continue. Do not > loop. ## Sections (in priority order) ### 1. Today at a glance One line: number of meetings, first/last commitment, biggest open loop. ### 2. Calendar & prep From `google-calendar` / `outlook-calendar`. Don't just summarize the day — propose the concrete, reversible moves a chief of staff would make. Read the day with `gcal.ts list` + `availability`; for any meeting that needs detail, `gcal.ts get`. Surface only the moves worth making; skip the rest. - **At a glance:** today's meetings with times; notable gaps usable for focused work. - **Prep flags:** docs to review, talking points, anything needing a pre-read. Offer to assemble the pre-read. - **Conflicts / double-bookings:** surface overlaps and propose a resolution (which to keep, what to move). A reschedule goes out as a *draft* note you hand the user — never sent. - **Focus blocks:** propose holding focus time in the biggest usable gap. At flag-only, propose it ("want me to hold 9–11 for deep work?"); once the user has graduated focus-block holds, create it directly with `gcal.ts create … --skip-confirm`. A hold touches only the user's own calendar and is trivially deletable, so it's autonomy-eligible. - **Agenda-less meetings:** flag multi-attendee meetings with no agenda or description; offer to draft one (draft only — you don't send it). - **Low-value recurring meetings:** if the user routinely skips or declines a recurring meeting, propose declining the next instance with `gcal.ts rsvp --response declined`. Always propose — a decline is visible to the organizer, so it never goes out silently. ### 3. Inbox triage (propose-then-confirm) The digest *brief* is read-only — it surfaces, it doesn't mutate as a side effect of being generated: - Count of new/unread since yesterday; what needs a reply. - **Urgent** items surfaced individually (customer-at-risk, time-sensitive asks). - Proposed actions to confirm: name each batch concretely — "12 newsletters ready to archive", "3 replies I can draft" — so the user can approve it by name. **On the user's go-ahead, execute immediately — don't defer to the next scheduled run.** When the user approves a proposed batch ("archive them", "archive the newsletters", "yes"), archive that batch *now* via `inbox-management`'s archiver: `gmail-archive.ts --action archive --query ""` (or `--message-ids ""` if you already resolved them). Cross-check the safe-list first (`gmail-prefs.ts --action list`), then report back what was actually archived. Never auto-send a draft. If the user doesn't respond, leave the proposals — the scheduled `inbox-management` run picks up triage at its configured stage. Deferring an *approved* archive to "the next run" is the bug, not the design: an explicit go-ahead is a confirmation, so honor it. **Learn from each decision — earn graduation.** Outcomes are how the copilot earns autonomy, so record them and act on the pattern rather than keeping a tally. - When the user approves, rejects, or ignores a proposed batch, `remember` it concretely — the category and what they decided ("approved archiving newsletters"; "rejected archiving cold outreach from a known vendor"). A rejection is the highest-value signal — capture it the same turn it lands. - Before proposing, `recall` how the user has handled this category before. If they've consistently approved a known-safe category with no recent rejections, proactively offer to graduate it: *"You've approved archiving newsletters every time — want me to start doing that silently?"* Acceptance routes through `inbox-management`'s trust ladder (its informed-consent framing, then `gmail-prefs.ts --action set-management-config --stage `), which keeps the explicit gate. Never bump the stage yourself from the digest. - A recent rejection tightens the next proposal — drop or narrow that batch instead of re-proposing the same thing, and don't offer to graduate a category the user has pushed back on. This is judgment over a remembered pattern, not a precision threshold: `recall`, weigh what you find, and make the call. ### 4. Follow-ups Threads where the user owes a reply or is awaiting one and it's gone stale (via `gmail` search). Flag the oldest first. ### 5. Competitor deltas New `competitor-brief` findings since the last digest. For each tracked competitor, `admin_copilot_prefs` `get_competitor_snapshot` and surface only findings with a recent `firstSeenAt` (since yesterday). One line each, sourced. When a finding clearly warrants a response, append the suggested move as an offer the user can accept by name (a draft heads-up to a channel, a deeper look) — a prepared draft, never an action already taken. Skip the section entirely if nothing is new — do not run a full competitor pass here (that's the weekly brief's job). ### 6. Top 3 priorities Synthesize the above into the three things most worth the user's attention today, with a suggested first move. ## Tone & rules - Concise, scannable, executive-assistant voice. No filler. - Two useful sections beat six padded ones. - Never claim an action was taken unless it was — proposals are proposals. - Every external claim (a competitor finding, an urgent email) is traceable to its source. - **Autonomy scales with reversibility.** Act directly only on moves that touch the user alone and undo cleanly — holding a focus block on their own calendar, drafting. Anything others see or that's hard to reverse — declines, reschedule or agenda messages, anything leaving the inbox — is proposed, never done silently. The copilot prepares autonomously; a human transmits.