Daily Briefing — In-Project App Spec (testable v1)

What it is (one line): A personal daily briefing built as a Claude Project that reads your inbox + calendar (+ an optional tasks/notes source) and returns one morning briefing — what needs your eyes, today's meetings + prep, open action items, and a work-plus-life day. It reads and tells you what to do; it never sends or edits on your behalf. Optional power path: the same logic run in Claude Code (Opus) for filesystem access and a saved/scheduled briefing.

Source: 6/22 TPC Momentum Monday transcript — the "give me the brief; here's what you need to go do" pattern (read-only, you act); Steven's "class set up to prompt me which chat/cowork/code, even which model, to use"; Kathryn's chat → cowork → code progression. Generalized for cross-client use.

Sibling (do not duplicate): the TPC-specific phased rollout at business-aos/cyp/tpc/events/2026-07-in-person/personal-daily-ops-app-spec.md. That one rolls this out to the 7 TPC members at the retreat. This doc is the clean, client-agnostic, testable build.

Status: DRAFT to test. Generic — no client specifics. The only per-user piece is a short context doc. Member/client-facing version needs a voice pass before a non-technical owner sees it.

Why this build first

It's the "first agent" an owner feels immediately: read-only, high felt-value, and it sidesteps the write-blocker (Claude can read inbox/calendar but can't reliably send or edit in Google/Microsoft). One shape covers what four different people asked for — inbox triage, meeting prep, action-item roundup, and a day that fits work and life.

Two ways to run it

A) In-project (default — anyone on Claude Team / Pro / Max). A Claude Project holds the instructions + connectors + a context doc. You type "daily briefing" and it reads your accounts and returns the briefing in chat. Read-only. No setup beyond connecting your email + calendar.

B) Claude Code / Opus (power path — when they want more). The same briefing logic run in Claude Code: reads local files across every client/folder (which cloud projects can't — they're knowledge-siloed), writes the briefing to a file (briefing-YYYY-MM-DD.md), and can be scheduled to run each morning. For users who remote into a desktop and want it saved or automated. Mirrors Steven's pattern — the project can even tell you when to move to Code.

The two share one set of instructions; B is A plus filesystem + save + schedule.

What it reads (inputs)

• Email — Gmail or Microsoft 365 / Outlook connector.
• Calendar — Google or Outlook.
• Optional — a "today" source: a tasks/goals/notes doc the user keeps, or per-client status docs. In the Code path this is a local folder it reads live.

Read-only throughout. One account per connector (see limits).

What it returns (the briefing)

Fixed sections — each user can trim in their context doc:

1. What needs your eyes — flagged inbox items (business + personal), ranked, each with the sender and a one-line why. Skips newsletters/automated unless the context doc says otherwise.
2. Today — meetings in time order; one prep line each (what it's about, what to bring, last touch).
3. Open action items — what's outstanding + the next step, from the notes/status source.
4. Your day — work + life — a suggested time-block plan that respects work hours and life anchors.
5. One focus — the single most important thing today.

Example output (shape)

What needs your eyes (3)

• Client A — replied asking to move Thursday; needs a yes/no today.
• Bank — wire confirmation pending your approval.
• Personal — kid's school form due tomorrow.

Today

• 10:00 Client B review — last met 5/20; bring the updated plan.
• 1:00 Team check-in — you owe the Q3 number.

Open action items

• Send Client C the proposal — drafted, needs your final paragraph.

Your day (work + life)

• 8–10 deep work (proposal) · 10–12 meetings · 12:30 walk · 2–4 client work · 5:30 hard stop.

One focus: Get the Client C proposal out.

The Project setup (in-project)

1. Instructions (paste into the Project's custom instructions):

You are my daily briefing. When I say "daily briefing" (or "good morning"), read my
connected email and calendar plus my context doc, then return ONE briefing in this format:

1. WHAT NEEDS MY EYES — scan my inbox; list ONLY what genuinely needs me (a decision, a
   client waiting, time-sensitive). Rank them. Each: sender + one-line why. Skip
   newsletters/automated mail unless my context doc says to flag it.
2. TODAY — my meetings in time order; for each, one prep line (what it's about, what to
   bring, when we last met).
3. OPEN ACTION ITEMS — from my tasks/notes source: what's outstanding + the next step.
4. MY DAY (WORK + LIFE) — a suggested time-block plan that fits my work hours and the life
   anchors in my context doc.
5. ONE FOCUS — the single most important thing today.

Rules: READ ONLY. Do not send, reply to, or edit anything — tell me what to do and I'll act.
Be concise. If a connector returns nothing, say so plainly. Use my context doc for
priorities, recurring meetings, what "needs my eyes" means, and my hours/anchors.

2. Connectors: enable the email + calendar connector for the account(s) you want read.

3. Knowledge — the context doc (the only per-user customization):

# My context
- Role / what I do:
- Top 3 priorities right now:
- What "needs my eyes" means (and what to skip):
- Recurring meetings + what each is for:
- People/clients to always flag:
- Work hours:
- Life anchors (non-negotiable — exercise, family, pickups):
- Where my tasks/action items live:

That context doc is what makes it client-agnostic: same app, different doc per person.

The Code / Opus version (power path)

• Same instructions, packaged as a Claude Code command/skill.
• Reads a local folder (and per-client files across the filesystem — no project wall).
• Writes briefing-YYYY-MM-DD.md to a chosen folder so the briefing is saved, not just in chat.
• Schedulable — a morning run, so it's waiting when they sit down.
• The in-project version can route a user here when they want it saved/automated or need cross-client reads.

Test plan ("we could test")

1. Stand it up: create the Project, paste the instructions, enable one email + one calendar connector, fill the context doc.
2. Run it: type "daily briefing."
3. Acceptance criteria:

• Pulls real items from the connected inbox + calendar (not generic).
• "Needs my eyes" matches what the user would actually have flagged (check against their gut for that morning).
• Meeting prep lines are accurate (right meeting, useful prep).
• The day-plan respects the work hours + life anchors in the context doc.
• Nothing is sent or edited — read-only holds.
• Runs start-to-briefing in a couple minutes.

1. Pilot: run it for the test client for ~5 mornings; capture what they'd add/cut. Tune the instructions + their context doc, not the architecture.

Guardrails / limits (capability facts verified 6/22)

• Read-only. Claude can read inbox/calendar and create files, but can't edit Google/Microsoft docs or send/create on your behalf. The briefing tells you what to do; you act.
• Cloud projects are knowledge-siloed — they can't read across other projects. Cross-client status comes from a single notes doc (in-project) or the filesystem (Code path).
• One account per connector — business/personal split is limited on Google; Microsoft 365 covers work mail + calendar together.
• Data protection lives on the business tier (Claude Team). Scope what the project is allowed to read.

Open questions — for the Arden build session

1. Which client are we testing with, and their stack (Google vs. Microsoft 365)? That sets the connectors.
2. v1 = in-project only, or stand up the Code/Opus path in the same test?
3. The tasks/action-item source — a doc they already keep, or do we give them a simple "today" doc to maintain?
4. Naming — "Daily Briefing" is the working name; the user names their own.