---
title: The Daily Brief
description: One message on your phone first thing in the morning, under five minutes, fixed section order, hard character cap, every line demanding a response — and the pipeline behind it.
track: rituals
url: https://www.chiefofstaff.io/guides/the-daily-brief
published: 2026-09-01
author: chiefofstaff.io editorial system
outcome: produce a daily brief in the fixed section order, under the channel's character cap, with each item framed as the decision it asks for, and refuse to include anything that is merely interesting.
prerequisites: the-task-graph, manager-not-operator
source: chiefofstaff.io
---

# The Daily Brief

One message on your phone first thing in the morning, under five minutes, fixed section order, hard character cap, every line demanding a response — and the pipeline behind it.

## The Product

Everything else in the system exists so that this one artifact can be good. The daily brief is delivered every morning — 6 a.m. in the reference system; whatever time you actually wake and look — to the phone as a single message with a hard length cap — about 4,000 characters, imposed by the channel and kept even though it hurts, because it forces selectivity. It is a sub-five-minute read, and **every line must demand a response.** Anything that is merely interesting waits for the weekly digest.

![Anatomy of the daily brief: Atlas changes, decisions today, top three by day shape, meeting prep, waiting-for aging, spotlight, family blocks — on a phone, under the cap.](/img/diagrams/daily-brief-anatomy.svg)

## The Sections, in Fixed Order, Every Day

1. **Atlas changes since the last brief.** High-impact edits called out individually; the rest as a count with a link to the curation log. This is the audit rail made visible — you never have to go looking for what the assistant changed.
2. **Decisions needed today.** Items that block someone or expire today, each framed as the actual decision: *"Subscription renews Friday (3-day window). Keep or cancel?"* — not a topic and a task ID.
3. **Top three priorities**, filtered by the day's calendar shape. Long free blocks surface `@deep` work; a travel day surfaces `@async` and `@quick`.
4. **Meeting prep.** One line per meeting: who, why, the ask, and a link to the prep document if one exists.
5. **Waiting-for items aging.** Everything delegated more than seven days ago, oldest first, with a nudge suggestion.
6. **Spotlight.** Exactly one aged or forgotten item per brief — a task that quietly stopped moving, a delegation past its follow-up, a someday item from months ago — rotated so the long tail gets one honest look a day without swamping the message.
7. **Today's family and personal blocks**, with equal billing to everything above. This is the section that stops work eating dinner.

Sections render only when non-empty. The order never changes, because a reader who knows where things are reads faster.

## Behind the Scenes

The brief command runs the whole morning pipeline:

1. **Pull the inbound channel first, unconditionally.** Overnight messages and replies land before anything else is computed. The word "unconditionally" is in the routine because the assistant once skipped the pull, reasoning it had pulled earlier that session — and asserted "no inbound" while an unprocessed message sat in the log.
2. **Run a deterministic prep script.** A shell script gathers everything mechanical: git log since the last brief, open-task queries, aging delegations, and the exact lookback window — computed from the previous brief's timestamp with a small overlap, not a hard-coded "24 hours", so a skipped day never loses anything. Date math and file gathering never belong in a prompt.
3. **Fan out to the curators in parallel.** Email, calendars, tasks — each with a hard per-source budget (the email curator returns at most five items, the work inbox three) so no single source can swamp the message. Each curator's report is also written to a dated folder in `Efforts/reports/` so the raw input survives in git.
4. **Enrich against the vault.** Before any line names a sender, vendor, or counterparty, the assistant greps `Atlas/people/` and `Atlas/ventures/` for a match. "Unrecognised sender" is only valid after both lookups come back empty — this rule exists because a family member's calendar invite once shipped as "unrecognised sender" when her note had been in the vault for ten days.
5. **Draft unconfirmed tasks** for every actionable item a curator surfaced that is not yet tracked, at low priority, with provenance in the description. See [Incremental handling](/guides/incremental-handling).
6. **Synthesise.** The model's actual job: select what demands a response, filter the top three by day shape, frame each line as its decision.
7. **Measure, deliver, archive, commit.** The channel coordinator independently measures the payload against the cap and refuses to send if the count disagrees with the claim. Then: send, archive the brief, log everything, commit.

## Outage Policy

Two classes of curator. The **day-shaping** ones — email and calendar — hold the whole brief if they fail: a partial brief that silently omits your inbox is worse than a one-line escalation saying "email curator down; fix is X." The **additive** ones — tasks read-back, drive — degrade gracefully with a note in the relevant section. The distinction is a decision record, and the trigger to revisit it is written down.

## What Keeps It Good

- **Frame lines as decisions.** If a line cannot be answered from a phone with a few words, it is not ready.
- **Budget, don't summarise.** Fewer items with the full decision beats many items with a topic each.
- **Keep the cap.** If your channel has no limit, impose one. The cap is the editorial policy.
- **Read what changed.** The first section is where trust is built or lost. When an edit there is wrong, that is a feedback-log entry.
- **Deep-link when there is a source.** An email-sourced line carries a tappable "open thread" link so the brief is a starting point, not a summary you then have to go find.

## Start Crude

Your first brief has no curators and no channel. It reads the vault and the task graph and prints seven sections to the terminal. It will be thin. Ship it anyway, every day, by hand, for two weeks — then automate. The format has to stabilise before the machinery does.

## See it

The [demo vault](/demo/vault/calendar/briefs/archive/2026-09-05) has a first brief, built from vault contents alone with nothing connected. It is fictional, and it was built by Claude Code sessions running [the bootstrap prompt](/start#prompt) — not written by hand.