path: root/.ai/workflows/daily-prep.org

#+TITLE: Daily Prep Workflow
#+AUTHOR: Craig Jennings & Claude
#+DATE: 2026-06-11

* Overview

This workflow builds and maintains the daily prep doc — the single document Craig works from all day. It assembles the day's frame (Heads-Up), the day's work (Day's Priorities), and the day's schedule with everything nested under it (Meetings / Focus Blocks), so Craig walks into every meeting prepared and every open block with a menu of ready, linked work.

The prep doc for a day is normally generated the afternoon before, during the end-of-day review block, and updated whenever the world moves.

* Problem We're Solving

Without daily prep, Craig risks:
- Walking into meetings without the right context loaded
- Missing opportunities to drive key decisions or raise important points
- Losing track of action items owed to or from specific people
- Not having focused work time protected on the calendar
- Reactive instead of proactive days

*Impact:* Unprepared meetings waste everyone's time. Unplanned days let urgent displace important.

The deepest failure mode this workflow guards against is *prep that exists but can't be reached*: a meeting prep doc that was built days earlier but only mentioned — not linked — under the wrong day's heading, found too late to use. Every meeting entry links its materials directly, and every meeting is verified against the live calendar, because meetings move.

* Exit Criteria

- Every calendar event for the day appears in =* Meetings / Focus Blocks=, verified against the live calendar (build time and update time — times move)
- Every meeting entry carries its join link, its prep materials as =file:= / URL links (never a bare mention), what Craig needs to contribute, what he needs to get, and likely questions with answers
- Any "I don't know" answer to a likely question has a prep block scheduled *the day before* the meeting, never day-of
- Day's Priorities are sourced from both the project tracker and =todo.org=, each entry mirroring its todo.org task and carrying its own context and links
- Craig has confirmed the Day's Priorities at the mandatory review gate (Create mode)
- Focus blocks are on the calendar (marked free), created the day before after Craig confirms the prep
- Drafts the day needs (reschedule messages, replies) are pre-written in the doc, ready to send
- Any quick tasks (< 5 min) are done during prep itself

* When to Use This Workflow

- End-of-day review block ("What Kind of Day Has It Been?") — generating tomorrow's prep is part of that block's standing agenda
- "Let's prep for tomorrow" / "daily prep" / similar — Create mode
- "Update today's prep" / after a triage-intake lands something that changes the day — Update mode
- A standup-brief refresh ("what's my standup report") is an Update-mode run scoped to the relevant standup's entry — there is no separate standup-only mode anymore

* Run Modes

There are only two times this workflow runs. Pick the mode at start; don't switch mid-run.

** Create

Build the prep doc for a future day — normally tomorrow, during the end-of-day review block. Runs the full phase sequence and *ends with a mandatory priorities review gate*: Craig confirms the Day's Priorities or reworks them interactively (add / remove / substitute priorities and blocks). Calendar writes (focus blocks, day-before prep blocks) happen only after the gate.

Disagreement at the gate is a signal that =todo.org= is stale — it should be easy to identify Craig's current priorities by looking at the file. When the gate produces substantive rework, surface that and offer a task review.

** Update

Refresh an existing day's prep when the world moved — typically after a triage-intake lands something, a meeting reschedules, or new information changes what the day can achieve. Re-fetch the calendars (never trust the build-time snapshot — times move), re-verify every meeting entry, refresh the affected sections, and surface the delta to Craig. No mandatory gate; the changes themselves are the review surface.

** Triage freshness (both modes)

If no triage-intake has run in the last *hour*, run one first — before anything else. Incoming information may change what the day can achieve; the prep reacts to it, never ignores it. The [[file:triage-intake.org][triage-intake engine]] fans out across its source plugins, classifies, synthesizes, and writes Action items into =todo.org= as =:quick:reactive:= tasks (see Phase 3).

* Prep Doc Template (strict)

The prep doc has exactly three top-level sections, in this order. Don't invent new ones. If substantive content surfaces that doesn't fit, mention it in chat after the workflow finishes rather than adding a section.

| Section                    | Purpose                                                              |
|----------------------------+----------------------------------------------------------------------|
| =* Heads-Up=               | Standing frame for the day — density, events, reminders, look-ahead  |
| =* Day's Priorities=       | The day's work, task-shaped, mirroring todo.org                      |
| =* Meetings / Focus Blocks= | The schedule — every calendar event, with all content nested under it |

The separate =* Standup Briefs= and =* Upcoming Deadlines= sections are *retired*: standup briefs nest under the standup meeting they're reported in, and upcoming deadlines live in the end-of-day review block's content. There is no anchor-tasks handoff section either — carry-forward lands directly in the next day's Day's Priorities, because the next day's prep is built during today's end-of-day block.

** =* Heads-Up=

Items that frame the day. Four standing items are *always* present, plus the look-ahead:

1. *Meeting-density framing.* One line on the day's shape, e.g. "Meeting-dense morning: 09:00 team discussion, 10:00 standup, 11:00 general standup. Real focus time only opens at noon."
2. *Calendar events from BOTH calendars* (work + personal): birthdays, holidays, anniversaries, vacations, trips, big events. "Your trip begins Friday." "It's <person>'s birthday today."
3. *Reminders due, imminently due, or past trigger* — from notes.org Active Reminders plus scheduled/deadline tasks. A reminder tied to a rescheduled meeting reports against the new date.
4. *Requested metrics* — a slot for any metric Craig has asked to track in the daily prep. Render the slot only when a metric is active; none are active by default. (Metric design is a separate discussion — don't invent metrics.)
5. *5-Day Look-Ahead* — one day per line, format =Fri 12:= / =Mon 15:=, including clear days marked =clear=. Built by Phase 1's forward scan with the invite quick-read and decline gate applied.

Format: terse, situational, one item per line. Link to sources rather than inlining context.

** =* Day's Priorities=

The day's work, sourced from BOTH the project's tracker (Linear, where the project uses one) and =todo.org=. Each entry is a task-shaped level-2 header that *mirrors the linked todo.org task exactly* — same status keyword, same priority cookie, same tags:

#+begin_example
** STATUS [#PRIORITY] TASK-DESCRIPTION :tags:

   Relevant Information: (rename as appropriate)
   [todo.org link, tracker ticket, PR, doc — every link the task needs]
   <what success on this task is; today's achievement goal when the task
   is bigger than a day; any relevant preparation>
#+end_example

Rules:

- *Links live in the content, never in the heading.* The body carries the todo.org link, the tracker ticket, the PR, the doc — along with all the other relevant information. The heading stays plain text (strip link markup when mirroring a task heading that carries one).
- *Property drawer optional.*
- *Body carries the entry's own context* — what success is, today's achievement goal when the task is bigger than a day ("Finish phase 2 of the spec and be ready to start phase 3 tomorrow"), and any relevant preparation (e.g. "this is also good prep for when the topic comes up in <meeting> on <day in the look-ahead window>").
- *Execution links ride with the entry.* When the task is actioned through a URL — a payment portal, a doc, a PR, a form — the body carries that link directly. If the URL isn't in the todo.org task body yet, hunt it down (source email, Slack thread) and add it to BOTH the todo.org body (durable home) and the prep entry.
- *The daily big-ball chunk is an entry here.* One important-but-not-urgent task per day, slated for a ~15-minute chunk (see Phase 3).
- Order by urgency (Phase 3's sort). Craig should be able to work top-to-bottom.

A "Goal:" or "Recap and Goal:" entry shape is fine for committed deliverables that need narrative context (where it stands, what's owed, to whom, by when) — same rules: links in body, success stated.

** =* Meetings / Focus Blocks=

The spine of the doc — most content lives here. The schedule renders as a chronological list of level-2 headers, one per calendar event, with ALL content for an event nested directly under its own header:

#+begin_example
** HH:MM–HH:MM — Exact Calendar Title
#+end_example

The title is the calendar event's subject *verbatim* — no annotations, no editorializing (not "(personal routine)", not "(recurring)"). Anything under the header must be actionable information or a useful reference during that event.

Per-event-type content rules:

*** Morning Prep (first block of the day)

Morning Prep is where Craig reads the prep doc, mentally walks the schedule, and refreshes his memory on proposals, status, and what to report. The workflow's job here: take what triage-intake surfaced and turn it into strategy, proactively supplying what Craig needs to keep the day on track. Content:

- *Conflict resolutions, ready to execute.* When a conflict or reschedule surfaces (e.g. the boss called a meeting overnight that overlaps an existing one — the triggers: who it's from, and that it appeared last night), check BOTH calendars' availability, recommend the best slot, and list the alternatives with their trade-offs ("only 30 minutes — could the agenda be cut to the high-priority topics?"). Close with the offer: "tell me which and I'll handle it." When no mutual free time exists, say so and include the direct-contact draft.
- *Drafts go IN the prep doc, ready to send* — not an offer to draft one. The Slack reschedule message, the heads-up note, the reply: pre-written, =/voice personal= applied, sitting in the doc so Craig's word (a cj-comment or a "send it") is the only remaining step.
- *Important FYIs* from triage that Craig must see before the day starts ("you got a [[slack-url][Slack message]] from <person> saying <big news>").
- A pointer to the next meeting's agenda when reviewing something first would help ("your next meeting discusses X — review the proposal you wrote").

*** Standups

The Yesterday / Today / Blockers brief nests *directly under the standup meeting it's reported in* — never in a separate section. Plain section labels, no parenthetical questions in the rendered doc.

- *Blockers is always present.* When there are none, write =Blockers: None= explicitly — silence is ambiguous.
- *Outcomes, not attendance.* Never "met with <person>" — instead what came out of it: "<person> finished the branch CI/CD work." Never "went to the managers' meeting" — instead the development from it that affects this audience.
- *No recurring 1:1s or ceremonies* in briefs — they're not news.
- *Match the standup's altitude.* An engineering standup gets engineering-goal material only: what moved the platform or the demo forward — architecture docs, PRs, tracker tickets, partner meetings with use-case implications, integration discussions, security findings, dataset discoveries. It does NOT get: 1:1s, attending other standups, personal-tooling maintenance, profile updates, sending messages or email, meeting prep, booking travel, or interviews with non-engineering candidates. The three questions are really: (a) how have I moved us closer to the engineering goals, (b) what will I work on that moves us closer, (c) what information do I have that might impact the team or its goals.
- A business-level (general) standup is different: features finished that leadership wanted, vacation/travel that affects availability or velocity, conference learnings, partner/customer decisions, cross-functional confusion worth clearing up. *Exclude routine maintenance and operational items — PR reviews don't belong here.* Foundational or strategic engineering work does; operations don't.

(Drafting rules — first-person, deadline precision, recurring-meeting filters, the team-visible test — are in Phase 6.)

*** Meetings

Every meeting entry carries:

- *Notable accept/declines* ("only <person> accepted; <other> is out").
- *Attendees and the join link* — an org link to the conference URL from the calendar event's conference data, so Craig clicks and joins from the prep doc. In-person/phone meetings omit it.
- *The meeting-prep doc, LINKED* — a =file:= link, never a bare mention. If a prep doc exists anywhere in the project, the meeting entry links it. This is the lesson of a real failure: the prep existed, but it sat unlinked under a different day's heading, and Craig — with minutes to spare — couldn't find it and had to wing a meeting that mattered. Be thorough, check every meeting, find and link all the relevant docs.
- *Summary* — who this is, why the meeting exists, what's known about the relationship and context.
- *What Craig needs to contribute* and *what he needs to get* from the meeting.
- *Likely questions, with answers.* When the honest answer is "I don't know," that forces a prep block scheduled *the day before* the meeting — never day-of. Schedule it in Phase 9.

*Verify every meeting against the live calendar at build AND update time.* Meetings move. A prep entry pointing at yesterday's time is worse than no entry.

*** Focus Blocks

Focus blocks are calendar events *marked free*: others see the time is claimed for focused work and self-select out unless something is genuinely important or urgent. The workflow CREATES them the day before, in Phase 9, after Craig confirms the prep at the gate. They're the first thing to shrink under schedule pressure; lunch shrinks second, with a 30-minute floor.

Content is a *menu, not an assignment* — "no plan survives contact with the enemy." Craig doesn't know what kind of day he'll have, how much sleep he'll get, or what will land on him; he chooses from the menu in the moment. Build it as:

- *Recommended item first*, then alternates. Recommendation reflects this week's priorities and any accepted deadline that's around the corner — deadline items list even when higher-priority items exist.
- *Every item LINKED* — this is a moment of action with no time to search. The PR, the tracker queue, the doc to review, the email thread; include a starter draft when the item is a reply.
- *Size the menu to the block.* Short block (≤30 min): the PR queue, tracker-chore grooming, prep for a later meeting. An hour or more: the bigger Day's Priorities items, even if they won't finish in the time allotted. Typically a rehash of Day's Priorities above, sized and linked.

*** Lunch

30-60 minutes, anywhere 11:00-13:30. An hour typically; 30 minutes on busy days — never less. NO tasks, no meeting prep. Personal time, not work time.

*** End-of-day review block ("What Kind of Day Has It Been?")

The last block of the workday, on the calendar as a recurring event (typically 16:30-17:00). Its content:

- The day's summary — what happened, what landed, what slipped.
- *Generating tomorrow's prep* — a Create-mode run of this workflow normally happens here.
- *The upcoming-deadlines list* — this replaces the retired deadlines section. Format: one per line, =Tomorrow: <item>= / =Mon 5/18: <item>= / =5/17–5/21: <event>=, roughly the next 4-6 weeks, chronological.

* Approach: How We Work Together

** Continuous flow, one gate at the end

Phases A through 7 run continuously — don't stop between phases for confirmation. Information surfaced in later phases (especially triage) frequently reframes earlier phases; stopping early means asking Craig to react with stale context. Build the whole doc, then present it at the Phase 8 gate with every question and proposed adjustment.

Exception: stop only if something *blocks* further building — a canceled meeting that restructures the day, or an issue Craig must adjudicate before triage can proceed.

** Phase A: Data Gathering (one parallel batch)

Pull every source in a *single batch of parallel tool calls*:

1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the prep day *plus the next 5 days* (prep-day subset feeds Phases 1 and 4; the forward window feeds the look-ahead).
2. =mcp__google-calendar__list-events= for the *work* account, same scope.
3. Grep =~/.emacs.d/data/pcal.org= for items on that day (Proton Calendar export; =gcal.org= / =dcal.org= are already covered by the MCP queries).
4. Read =todo.org= — [#A] and [#B] tasks plus anything with =DEADLINE:= or =SCHEDULED:= touching the day.
5. Pull the project tracker's view of Craig's plate (assigned issues, items in review, blocked items) where the project has one.
6. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink resolves to. If the symlink doesn't resolve yet, take the most recent file. The standup lookback anchors on this file's date.
7. Read the most recent =.ai/sessions/= summary (for the standup brief's lookback).

This fetch *is* the live calendar read for build time. In Update mode, re-run the calendar fetches — never reuse the build-time snapshot.

** Phase 1: Meeting Review

Working from the Phase A snapshot, capture for each meeting: time and duration, the exact calendar title, owner, official agenda, accept/decline status — and *what Craig needs from it*: not "attend" but the active role (decisions to drive, points to make, information to convey, people to persuade). Apply the decline gate: a meeting with no objective and no contribution for Craig is a send-regrets candidate, flagged for his call at the review gate.

*** 1:1 Meeting Prep

1:1s get deeper preparation: check todo.org for tasks tagged with or related to the person; review session histories since the last 1:1; identify status updates to share, questions to ask, decisions needing their input, and action items owed each way.

*** 5-Day Look-Ahead

Scan the forward window — read it, don't glance. For each meeting: the invite quick-read (who's invited and accepted, why it's being held, the timing, the objective). Three buckets:

1. *Meetings that need prep* — substantive meetings with no prep doc yet. Offer to run the [[file:meeting-prep.org][meeting-prep workflow]] or add a prep task; catching these days out is the point.
2. *Traps* — time-zone mismatch on a travel day, double-booking, a talk-heavy meeting that will overrun, a recurring meeting not needed this cycle.
3. *Focus blocks to protect* — open mornings/afternoons worth blocking before they're booked over.

Renders in Heads-Up as one line per day (=Fri 12:= … =Mon 15:= …), clear days marked =clear=, with the bucket findings attached to the days they concern.

** Phase 2: Planned vs Actual (Create mode)

Before setting tomorrow's priorities, review today's prep doc against what actually happened:

1. For each planned item: completed, partially done, or not started.
2. For items that didn't happen, identify why (ran long, blocked, deprioritized, meetings overran).
3. *Carry forward anything that still matters directly into the new doc's Day's Priorities*, with updated estimates based on what today taught. There is no hand-off section — the next day's prep is being built right now, so carry-forward lands as priorities entries.
4. Completed items: note them for the end-of-day summary.

This keeps the prep honest. A 1-hour task that consistently takes 3 hours means the estimates change; work that keeps getting bumped by meetings is a pattern worth raising at the gate. Update mode skips this phase.

** Phase 3: Day's Priorities

Assemble priorities from both sources; no mid-flow confirmation (the gate handles review).

*** Sub-step 3a: From todo.org and the tracker

1. Pull all [#A] tasks from todo.org.
2. Add time-sensitive items (=DEADLINE:= / =SCHEDULED:= touching the day).
3. Fold in Phase 2's carry-forward (dedupe against 1-2 by heading text or =:ID:=).
4. Pull open =:reactive:= tasks (created by prior triage runs) — pending quick-fire responses stay visible until processed. Dedupe against 1-3.
5. Pull the tracker items that demand action today (assigned with near deadlines, blocked-on-Craig, review requests).
6. *Pull one "big ball"* — a single important-but-not-urgent (Quadrant-2) task to chip at for ~15 minutes today: a spec, a vetting, an arch sweep, networking, a flashcard batch. Big strategic work only lands when broken into small daily pieces; one per day, Craig swaps or drops it at the gate.

*** Sub-step 3b: Triage external sources (delegate to triage-intake.org)

Don't scan email / Slack / tracker / PRs inline. Run the =triage-intake.org= engine (if the mode's freshness check already ran one this hour, use its synthesis). It classifies everything new against the four-bucket model, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the routine actions on confirmation. Source coverage comes from its Phase 0 plugin load — both =.ai/workflows/triage-intake.*.org= (general) and =.ai/project-workflows/triage-intake.*.org= (project-specific). A missing source is a missing plugin, not a daily-prep regression.

*** Sub-step 3c: Build the entries

For each item that belongs in *today's* plan, write a Day's Priorities entry per the template rules: heading mirrors the todo.org task exactly (status, priority cookie, tags — plain text, links stripped from the heading), body carries the links (todo.org, tracker, PR, doc, execution URL), what success is, today's achievement goal when the task outlasts the day, and any relevant preparation. Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's pulls.

*** Sub-step 3d: Urgency re-sort

Order: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. The gate refines; this gives a sane starting order.

*** Sub-step 3e: Audit footer

Write a single comment line below the =#+DATE:= header recording which sources triage actually covered:

#+begin_example
# Sources checked: todo.org ✓ | email-personal ✓ | email-work ✓ | Slack ✓ | tracker ✓ | prs ✓
#+end_example

Take per-source marks from the engine's synthesis. Replace ✓ with ✗ plus a reason for any source that didn't run (=Slack ✗ (MCP disconnected)=). Scanned-but-empty keeps its ✓.

*** Recommended Approach Pattern (shared reference)

When a triage Action item involves a non-trivial decision, the engine includes a =recommended approach= subheader before the response draft in the task body — situation, options, recommendation with rationale, considerations — so Craig can evaluate the recommendation, not just the wording. Skip it for routine acknowledgments and "yep, looks good" approvals. Format:

#+begin_example
***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended approach
<situation, options, recommendation with rationale, considerations>
***** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ recommended response
<draft response text, OR proposed action like a state change>
#+end_example

Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"=.

** Phase 4: Build Meetings / Focus Blocks

Write the schedule section: every calendar event as a level-2 header (=** HH:MM–HH:MM — Exact Calendar Title=), chronological, with content per the template's event-type rules.

1. *Verify against the live calendar* — the Phase A fetch at build time; a fresh fetch at update time. Times move; check every event.
2. *Join links on every meeting line* from the event's conference data (=conferenceData.entryPoints= — already in the Phase A output, no extra query).
3. *Compute the day's open window* (default 10:00-17:00, weekends included; same-day runs start at the current time). Subtract meetings, known commitments, lunch, and the end-of-day review block. What's left is focus-block space.
4. *Lay out focus blocks* in the remaining space and write each block's menu per the template rules (recommended first, alternates, everything linked, sized to the block).
5. *Place lunch* — 30-60 minutes somewhere in 11:00-13:30.
6. Don't create the calendar events yet — that's Phase 9, after the gate.

*** Quick Tasks (< 5 minutes)

"Schedule a meeting with <person>" or "send a quick reply" gets done during the prep itself, not scheduled. Draft the message or create the event on the spot.

** Phase 5: Prep Work

With the schedule drafted, produce what the day's entries need to be self-sufficient:

- *Pre-write every draft* the doc promises — reschedule messages, replies, heads-up notes — =/voice personal= applied, sitting in the entry ready to send on Craig's word.
- Hunt down and link every meeting's materials (prep docs, proposals, resumes, decks). A mention without a =file:= link is a defect.
- Answer the likely questions for each meeting; for every "I don't know," queue a day-before prep block for Phase 9.
- Research, talking points, and document polish for the day's meetings, in meeting-time order.

** Phase 6: Standup Briefs

Generate briefs late, so the day's analysis is already done. Each brief is written *under its standup's header* in Meetings / Focus Blocks. Skip on days with no standup.

*** Step 1: Sweep recent activity for off-Claude signals

Check, since the previous prep doc's date: sent email (both accounts), Slack (Craig's messages across channels and DMs), todo.org DONE-since-cutoff and fresh TODOs, and the tracker (state changes, comments, created items). These surface team-visible work that lives outside session history.

*** Step 2: Draft the brief(s)

Combine session history + the sweep + Day's Priorities + WAITING items into Yesterday / Today / Blockers, per the template's standup rules (altitude match, outcomes not attendance, =Blockers: None= explicit, no recurring 1:1s/ceremonies). Additional drafting rules:

- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others or report their commitments as status — frame a teammate's commitment as something Craig is waiting on, if it's relevant at all.
- *Match deadline precision to what's known.* "Early next week" doesn't tighten to "Monday." Vague is honest when vague is the truth.
- *Yesterday* anchors on the previous prep doc's date. Include only non-recurring meetings Craig actually attended (his own =responseStatus= = accepted). Use explicit day references ("Monday," not "yesterday") — the doc is written the evening before.
- *Today*: 2-3 items max, from Day's Priorities. Include non-recurring meetings regardless of response status.
- *Blockers*: the bar is "did this actually stop me from making progress?" — not "is someone else involved?" Default to under-reporting; Craig adds borderline items at the gate. FYIs come after blockers and stay loose.
- *Team-visible filter*: only work that left Craig's local environment — pushed, shared, posted, changed in the tracker, or shifts what the team believes or plans. "If I didn't mention this, would someone make a worse decision or duplicate work?" If no, cut it.
- Readable aloud in under 60 seconds.

*** Step 3: Capture learnings

When Craig's gate-time refinements to a brief look like a generalizable rule (cut a category, added one, a phrasing pattern), offer it back: "Want me to add this to the workflow? Proposed rule: …" Wait for explicit confirmation, then append to *Updates and Learnings* below and update the affected inline text. Default to under-proposing.

** Phase 7: Heads-Up

Write =* Heads-Up= last, when everything it summarizes exists: the density framing, both calendars' events, due/past-trigger reminders, the metrics slot (only if a metric is active), and the 5-day look-ahead lines from Phase 1. Pull substantial triage FYIs that change Craig's frame for the day; lightweight FYIs stay in =.ai/session-context.org=.

Also assemble the end-of-day block's upcoming-deadlines list: =DEADLINE:= entries from todo.org plus deadlines from notes.org, next 4-6 weeks, chronological, one per line. Don't duplicate items already in Day's Priorities — priorities are for action, the deadline list is for awareness.

** Phase 8: Priorities Review Gate (Create mode — MANDATORY)

Present the assembled doc and ask whether Craig agrees with the Day's Priorities. If not, work with him to add / remove / substitute priorities and blocks until he confirms. Surface here, in one pass: meeting-goal questions, decline candidates, look-ahead flags, carry-forward decisions, and proposed schedule adjustments.

If the gate produces substantive rework, say so plainly: that's a =todo.org= staleness signal — the file should make Craig's current priorities obvious. Offer a task review.

Update mode replaces the gate with a delta summary: what changed and why.

** Phase 9: Calendar Writes (after the gate)

Only after Craig confirms:

1. *Create the focus blocks* on the calendar for the prepped day — marked *free*, titled for focused work.
2. *Create day-before prep blocks* for every meeting question that landed on "I don't know" (and for look-ahead meetings needing prep that Craig accepted).
3. Any reschedules Craig approved at the gate: send the pre-written message, then move the event.

Use the project's calendar-event workflow (=add-calendar-event.org=) where it exists; respect existing commitments — don't double-book.

** Phase 10: Repoint the Current-Day Symlink

Prep docs are *born* in their permanent home and never move: =daily-prep/YYYY-MM-DD-daily-prep.org=, accumulating in place (working location and archive are the same directory). A single stable symlink at the project root points at the current day's file:

#+begin_src bash
# Relative target so the symlink stays valid if the project tree moves.
ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org
#+end_src

Consumers — the Emacs opener, next-day Phase 2, the standup lookback — resolve =daily-prep.org= rather than computing a filename. First run in a project: create =daily-prep/=, migrate any =inbox/*-daily-prep.org= or stale =assets/= prep docs into it, then link.

** Phase 11: Project Extension

If =.ai/project-workflows/daily-prep.org= exists, read and execute it as *additional* steps appended here — project add-ons (e.g. the project's specific standup names, calendars, recurring-event IDs), not a replacement. Surface once per session ("Project has additional daily-prep steps — running them now"). Runs in both modes.

* Principles to Follow

** Prep Supports Action
Craig should walk into every meeting and block with what he needs *in the doc, linked*. If prep doesn't lead to better outcomes, it's wasted time.

** Craig Drives Priorities
Claude surfaces information and proposes; Craig decides. The Phase 8 gate is where that happens — once, with full context, not piecemeal mid-flow.

** Be Thorough, Check Every Meeting
Every meeting verified against the live calendar, every prep doc linked, every likely question answered or scheduled for day-before prep. Consistency is the value — a prep that's excellent four days out of five fails on the day it matters.

** Quick Tasks: Just Do Them
Under 5 minutes: do it during prep. Draft the message, create the invite, send the email.

** Respect the Calendar
Don't double-book. Account for transitions. Focus blocks are marked free by design; lunch has a 30-minute floor.

** First-Person Perspective
Frame 1:1 talking points from Craig's side — what he needs to communicate, ask, or decide.

* Living Document

Update this workflow based on what works in actual daily prep sessions. Track learnings below.

** Updates and Learnings

*** 2026-02-23: Initial creation
Created during first daily prep session. Validated against tomorrow's schedule (2026-02-24: 1:1, Standup/IPM, Product Review, Backlog Planning).

*** 2026-02-23: Use explicit day references, not relative terms
The prep doc may be written the day before and read the day of — "this morning" is ambiguous. Include the day name.

*** 2026-02-23: Prep doc output
Originally =inbox/YYYY-MM-DD-daily-prep.org=. (Superseded 2026-06-01 — born in =daily-prep/= with a root symlink; see Phase 10.)

*** 2026-02-23: Check for dependencies between tasks and meetings
Prep work that feeds a meeting schedules before it. Ask Craig when unsure.

*** 2026-02-23: Energy management matters as much as time management
Front-load high-effort, high-stakes work early. Lighter work late afternoon. Lunch ~12:30 sustains the afternoon.

*** 2026-02-23: Link references in the prep doc
Tasks, documents, directories — link the source. Craig shouldn't search for context mid-meeting. (Strengthened 2026-06-11: links are now a structural requirement of every entry, not a courtesy.)

*** 2026-02-23: Note dependencies between time blocks
When an earlier block feeds a later meeting, say so in the doc.

*** 2026-02-23: Prep doc is a living document through the day
Craig annotates with "cj:" comments; process when asked or next session.

*** 2026-02-23: Ask probing questions about task nature
"Outreach" could be a 5-minute email or a 1-hour call. Ask; the answer often splits prep from action.

*** 2026-03-08: Keep Day's Priorities, drop separate Time Blocking table
Day's Priorities followed by a single chronological schedule section. (The schedule section was renamed Meetings / Focus Blocks 2026-06-11.)

*** 2026-03-08: Always include Planned vs Actual
The review happens every Create run (Phase 2). (Adjusted 2026-06-11: it feeds carry-forward into the new doc's priorities and the end-of-day summary rather than rendering as its own table — the strict template has three sections.)

*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
Priorities are org TODO headings, trackable in agenda/todo filtering, toggleable in Emacs. No bold/italic markup in the prep doc.

*** 2026-04-01: Always use human-readable ticket titles
"Setup Database for dev environment (SE-93)", never bare "SE-93". Fetch the title via the tracker MCP if needed.

*** 2026-03-27: Standup briefs — only team-visible goals, not personal productivity
Only work that left Craig's local environment. Filter: "if I didn't mention this, would someone make a worse decision or duplicate work?"

*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks
Entries pointed at todo.org tasks with all substance in the task body. (Superseded 2026-06-11 — entries now carry their own context, with links in the body. See the 2026-06-11 entry.)

*** 2026-05-15: Triage Action items become =:quick:reactive:= todo.org tasks — no grouped Response sub-sections
Each Action item surfaced by triage becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. Source mix lives in the tags, not in prep-doc structure. Still in force — the prep-doc side of the convention (thin links) was superseded 2026-06-11; the todo.org side stands.

*** 2026-05-31: Delegate triage to the triage-intake engine
Phase 3's ~280 lines of inline source scans collapsed into a delegation to the =triage-intake.org= engine; coverage carries via its two-dir plugin glob. The Recommended Approach Pattern stays here as the shared reference.

*** 2026-06-01: Prep docs live in =daily-prep/= with a root =daily-prep.org= symlink — no inbox churn, no archive move
The prep doc is born in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the root symlink repoints each run. Consumers resolve the symlink. Migration is one-time per project.

*** 2026-06-10: Execution links in priorities + join links on meetings
(1) An entry actioned through a URL carries that URL in its body; if the todo.org task lacks it, the prep build finds it and adds it to both. Worked example: a utility-bill task linked to todo.org but not the payment portal, so doing the task meant an email dig first. (2) Every meeting line carries an org link to its join URL from the event's conference data.

*** 2026-06-10: Manager Tools prep additions — 5-day look-ahead, daily big-ball, decline gate
(1) 5-Day Look-Ahead: Phase A widens the fetch to prep day + 5; Phase 1 scans the window for meetings-needing-prep / traps / focus-blocks-to-protect. (2) Daily big-ball: one Quadrant-2 task per day, ~15-minute chunk. (3) Decline gate: "what Craig needs" reframed from attending to contributing; no objective + no contribution = decline candidate.

*** 2026-06-11: Full template rewrite — strict three-section doc, two run modes, mandatory priorities gate
From Craig's instructive template spec (written 2026-06-10 evening, after reviewing generated preps) plus four refinements from his review of the first new-format prep. The doc is now exactly =* Heads-Up= / =* Day's Priorities= / =* Meetings / Focus Blocks=. Retired: the separate =* Standup Briefs= and =* Upcoming Deadlines= sections (briefs nest under their standup meeting; deadlines live in the end-of-day block), the =* [Day]'s Anchor Tasks= handoff (carry-forward lands directly in the next day's priorities, which are being built in the same sitting), the thin-link convention (entries mirror their todo.org task's heading and carry their own context — links in the body, never the heading), and standup-only mode (a brief refresh is an Update-mode run). New: two run modes (Create, with a MANDATORY end-of-flow priorities review gate whose disagreement signals todo.org staleness; Update, for when the world moves) both preceded by a triage-intake freshness check (no run in the last hour → run one first); event headers are the exact calendar title with ALL content nested under the event; per-event-type content rules (Morning Prep conflict-resolution strategy with drafts pre-written in the doc ready to send, standup altitude matching with =Blockers: None= explicit and operations excluded from business-level briefs, meetings carrying contribute/get/likely-questions with day-before prep blocks for "I don't know" answers and prep docs always =file:=-linked — the lesson of a prep that existed but couldn't be found in the minutes before a meeting that mattered, focus blocks as linked menus created day-before and marked free, lunch floor, the end-of-day "What Kind of Day Has It Been?" block carrying the deadlines list and generating tomorrow's prep); the look-ahead renders one day per line (=Fri 12:= …) with clear days marked =clear=; a requested-metrics Heads-Up slot rendered only when a metric is active (none yet); meetings verified against the live calendar at build and update time.