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

#+TITLE: Daily Prep Workflow
#+AUTHOR: Craig Jennings & Claude
#+DATE: 2026-02-23

* Overview

This workflow prepares Craig for the next workday by reviewing scheduled meetings, identifying priorities, and blocking time on the calendar. It ensures Craig walks into every meeting prepared and has a plan for the day's focused work.

This is typically run the evening before or morning of the workday in question.

* 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.

* Exit Criteria

- All meetings for the day are reviewed with prep notes
- 1:1 meetings have talking points drawn from todo.org and session history
- Day's priorities are identified and confirmed by Craig
- Time blocks are placed on the calendar for focused work
- Any quick tasks (< 5 min) are done during prep itself
- Craig feels ready for the day

* When to Use This Workflow

- When Craig says "let's prep for tomorrow" or "daily prep" or similar
- During evening wrap-up if there are meetings the next day
- Morning of a workday before meetings start
- When Craig asks for the standup brief alone ("what's my standup report", "let's do the daily standup report", "give me the standup brief") — see Standup-only mode below

* Modes

The workflow runs in one of two modes based on the trigger phrase. Pick the mode at workflow start. Don't switch mid-run.

** Full-prep mode (default)

Trigger: "let's prep for tomorrow", "daily prep", or any general prep-cycle phrase.

Runs Phase A → Phases 1-5 → Phase 6 (only if a standup is on the calendar) → Phase 7 → Phase 8 → Phase 9.

** Standup-only mode

Trigger: "what's my standup report", "let's do the daily standup report", "give me the standup brief", or similar standup-specific phrasing.

Runs *only* a slim Phase A + Phase 6 + a conditional Phase 8 + Phase 9. Skip Phases 1-5 and Phase 7 entirely.

*** Slim Phase A (standup-only)

Fetch only what Phase 6 needs:

1. =todo.org= — for WAITING items (blockers) and DONE-since-cutoff (completed work).
2. Previous prep doc — anchor for the lookback. Glob =daily-prep/*-daily-prep.org=, sort by date, take the file *before* the one the root =daily-prep.org= symlink currently resolves to (i.e. the prior prep day, not today's).
3. Most recent =.ai/sessions/= summary — for the "what did I do" question.

Skip the calendar fetches, the Proton grep, and the [#A]/[#B] todo pull. Phase 6 Step 1's sweep handles the rest.

*** Where the brief lands

- If a prep doc for today already exists at =daily-prep/YYYY-MM-DD-daily-prep.org=, append or replace its =* Standup Brief= section.
- If no prep doc for today exists, create =daily-prep/YYYY-MM-DD-daily-prep.org= with only the =* Standup Brief= section populated, then repoint the root symlink at it (=ln -sf daily-prep/YYYY-MM-DD-daily-prep.org daily-prep.org=). Full prep can be added later by re-running in full-prep mode.

See *Phase 8* for the prep-doc home and symlink convention.

*** Phase 8 in standup-only mode

If standup-only created a new dated file in =daily-prep/= (no prep doc for today existed), repoint the root =daily-prep.org= symlink at it. "Where the brief lands" above already does this; Phase 8 is a no-op when it did. If today's prep doc already existed and the brief was appended to it, the symlink already resolves to it — nothing to do.

Use standup-only mode when Craig wants the brief fast (e.g., right before standup) without rebuilding the day's plan.

* Prep Doc Structure

The prep doc has a fixed set of top-level sections. Don't invent new ones. If substantive content surfaces that doesn't fit one of these headings, mention it in chat after the workflow finishes rather than adding it to the prep doc.

Canonical sections (full-prep mode produces all; standup-only produces just =* Standup Briefs=):

| Section                          | Phase that writes it | Purpose                                                                    |
|----------------------------------+----------------------+----------------------------------------------------------------------------|
| =* Heads-up=                     | Phase 7              | Substantial situational context that changes Craig's frame for the day     |
| =* Day's Priorities=             | Phase 3              | Actionable items for today (thin links to =:quick:reactive:= todo.org tasks) |
| =* Meetings / Work Blocks=       | Phase 4              | Chronological schedule for the day (meetings + work blocks interleaved)    |
| =* Standup Briefs=               | Phase 6              | Yesterday / Today / Blockers content for the standup meeting               |
| =* Upcoming Deadlines=           | Phase 7              | Next 4-6 weeks of relevant deadlines, briefly                              |
| =* [Next day]'s Anchor Tasks=    | Phase 7              | Explicit forward commitments for tomorrow. Phase 2 of next-day's prep reads this |

Order in the prep doc follows the table top-to-bottom: Heads-up first (frame-setter), Day's Priorities next (action surface), then schedule, then standup, then deadlines, then forward-commitment.

** Day's Priorities entries are thin links to todo.org tasks (2026-05-12 rule)

Each actionable entry under =* Day's Priorities= is a *pointer to a todo.org task*, not a copy of its content. Form:

#+begin_example
** TODO [#X] <task title> — [[file:../todo.org::*<task title>][todo.org]]
<one line on why it's today's priority — deadline, blocker, what just landed>
#+end_example

All the substance — descriptions, drafted messages, research findings, sub-tasks, =VERIFY= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.

Exceptions that stay in the prep doc as content (not links):
- *Completed-today entries* — once a task is done, its heading becomes a dated log entry (=** YYYY-MM-DD Day @ HH:MM ...=, see [[file:../../.claude/...][feedback_done_tasks_become_dated_log_headings]] — i.e. the dated-heading rule) and stays in the prep doc as the day's record. If the work also has a durable todo.org home, the dated entry links to it.
- The =* Standup Briefs=, =* Heads-up=, =* Upcoming Deadlines=, and =* [Next day]'s Anchor Tasks= sections — those are prep-doc-native and don't map to todo.org tasks.

(Craig's instruction, 2026-05-12, extended 2026-05-15. The triage engine (sub-step 3b) implements the convention: each Action item becomes its own =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags, and the prep doc references it via a thin link under =* Day's Priorities= when it belongs in today's plan. No grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-sections in the prep doc — the source mix lives in the tags on each todo.org task.)

** Triage Action items become =:quick:reactive:= todo.org tasks (2026-05-15 rule)

Every Action item the triage engine surfaces (sub-step 3b, across email / Slack / Linear / PRs / calendar) becomes its own top-level =** TODO= in =todo.org= with =:quick:= + =:reactive:= tags. The prep doc's =* Day's Priorities= section links to those tasks as thin links per the rule above — no grouped Response sub-sections.

Form:

#+begin_example
** TODO [#B] Read [[https://linear.app/deepsat/issue/SE-378][SE-378 Kostya Testing Results]] :quick:reactive:kostya:
** TODO [#B] Re-review Vrezh's PR #167 after fixes :quick:reactive:vrezh:
** TODO [#B] Reply to Subbu re: RTX action items :quick:reactive:subbu:
#+end_example

Rules:

- Plain-prose heading, lead with the verb (Read / Re-review / Reply / Address / Schedule / Review).
- Default priority =[#B]=. Bump to =[#A]= only if the item blocks a teammate or a deadline lands inside 7 days.
- Always =:quick:= + =:reactive:=. Add person/entity tags (=:vrezh:=, =:kostya:=, =:subbu:=, =:rtx:=, etc.) when the dependency is sharp.
- Link the source in the heading when it has a URL — Linear issue, GitHub PR, Gmail thread, Slack permalink — using =[[url][label]]= form. The recommended approach and response content (when relevant) goes in the task body, not the heading.
- Placement in =todo.org=: end of =* Work Open Work= (before =* Work Incubate=) unless a =* Triage= / =* Inbox= section exists near the top.

If the item belongs in today's plan, also add a thin link under =* Day's Priorities= in the prep doc:

#+begin_example
** TODO [#B] <task title> — [[file:../todo.org::*<task title>][todo.org]]
<one line on why it's today's priority — deadline, blocker, what just landed>
#+end_example

Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via Phase 3 sub-step 3a's =:reactive:= pull.

* Approach: How We Work Together

** Continuous flow (no mid-phase gates)

Phases A through 7 run continuously. Don't stop between phases for Craig's input or confirmation. Information surfaced in later phases (especially Phase 3 email/Slack/Linear scans) frequently reframes what Craig wants from earlier phases — meeting goals, carry-forward decisions, priority order, time blocking. Stopping at Phase 1 to ask "what do you want from this meeting?" means asking Craig to react with stale context, before scans surface the email that might change his answer.

Build all phases through Phase 7, then present the assembled draft and surface every question and proposed adjustment at the final review.

Exception: stop only if a scan turns up something that *blocks* further building. Examples: a meeting was canceled and the whole day's structure changes; a security or compliance issue Craig must adjudicate before email triage proceeds. Otherwise keep going.

This rule applies to all phases including Phase 1's "collaborative review" line and Phase 2's planned-vs-actual review. Both are framed as collaborative in their phase descriptions; the collaboration happens once, at the end, against the assembled prep doc.

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

Before any synthesis or interaction, pull every source the prep doc needs in a *single batch of parallel tool calls*. These reads are all independent — issue them in one message, not as a sequential round-trip per source:

1. =mcp__google-calendar__list-events= for the *personal* account, scoped to the day being prepped.
2. =mcp__google-calendar__list-events= for the *work* account, same scope.
3. Grep =~/.emacs.d/data/pcal.org= for items on that day. This is the Proton Calendar export (=pcal= = personal calendar). The same directory has =gcal.org= and =dcal.org= for Google personal + DeepSat, but those are already covered by the MCP queries in steps 1 and 2 — only =pcal.org= adds non-redundant items.
4. Read =todo.org= — collect [#A] and [#B] tasks plus anything with DEADLINE: or SCHEDULED: touching the day.
5. List + read the *previous* prep doc. Glob =daily-prep/*-daily-prep.org= (all prep docs live there, born and kept — no separate archive). Sort by date and take the file *before* the one the root =daily-prep.org= symlink currently resolves to — usually yesterday's, but may be older if Craig was off (PTO, weekend, missed days). If the symlink doesn't resolve yet (no prep ever run), take the most recent file by date. The lookback for the standup brief is anchored on this file's date, so accuracy matters.
6. Read the most recent =.ai/sessions/= summary file (for the standup brief's "What did I do since last standup?" question).

Phases 1-5 below all work from this in-memory snapshot. *Do NOT re-query the calendars in Phase 4* — the time-blocking pass uses the same data Phase A fetched. A typical daily-prep used to run 4-5 sequential round-trips just for data gathering; this collapses to one.

** Phase 1: Meeting Review

Working from the Phase A calendar snapshot, present each meeting with:

1. *Time and duration*
2. *Meeting name*
3. *Owner* (who scheduled/owns the meeting)
4. *Official agenda* (from calendar description)
5. *What Craig needs from this meeting* -- decisions to drive, points to make, information to convey, people to persuade

For the last item, Claude may not know Craig's goals for the meeting. Present what's known and Craig will clarify during review.

*** 1:1 Meeting Prep

1:1 meetings get deeper preparation:

1. Check todo.org for tasks tagged with or related to the person
2. Review session histories since the last 1:1 with that person for relevant events, decisions, and context
   - Default lookback: since the last 1:1 with that person
   - Craig may ask to go further back for long-running items
3. Identify:
   - Status updates Craig should share (progress on things they care about)
   - Questions Craig needs to ask
   - Decisions that need their input
   - Action items owed to or from them

Capture the meeting list with what's known about each (time, owner, official agenda, who's accepted vs declined, what Craig might need). Don't stop here for Craig's input. Bring questions about meeting goals to the final review at the end of Phase 7, when the cross-source picture from Phase 3 is in hand. The collaborative review of the meeting list happens once, against the assembled prep doc, not as a mid-flow gate.

** Phase 2: Planned vs. Actual Review

Before setting tomorrow's priorities, review what was planned for today against what actually happened. This catches work that slipped and prevents it from silently disappearing.

1. Pull the current day's prep doc (if one exists). If it has a populated =* [Today]'s Anchor Tasks= section (written by yesterday's Phase 7 as the explicit handoff), use that as the canonical carry-forward list. Otherwise fall back to inferring carry-forward by listing the day's planned work blocks.
2. For each block, note: completed, partially done, or not started
3. For items that didn't happen, identify why (took longer than expected, blocked, deprioritized, meetings ran over)
4. Carry forward anything that still matters into the priority list for the next day, with updated time estimates based on what we learned today
5. Add all carried-forward items as =TODO= entries in the new prep doc's Day's Priorities section — don't just note them in the Planned vs Actual table. Unfinished tasks from yesterday become today's tasks automatically unless Craig cuts them.

This step keeps the daily prep honest. If a 1-hour task consistently takes 3 hours, the estimates need to change. If work keeps getting bumped by meetings, that's a pattern worth raising.

** Phase 3: Day's Priorities

Assemble priorities automatically from multiple sources. No interactive confirmation. Craig reviews the prep doc as a whole when it's done.

Phase 3 pulls priorities from two places: =todo.org= directly (sub-step 3a) and the triage engine's fresh Action items (sub-step 3b, which creates the =:quick:reactive:= tasks per the rule above). Sub-step 3c surfaces the ones that belong in today's plan as thin links under =* Day's Priorities=, sub-step 3d sorts them by urgency, and Craig edits the prep doc directly to add or drop a priority.

Sources contributing to Day's Priorities: todo.org (3a) plus everything the triage engine covers (email, Slack, Linear, PRs, calendar).

*** Recommended Approach Pattern (applied by the triage engine when writing reactive-task bodies)

When a triage Action item involves a non-trivial decision or judgment that benefits from analysis, the engine includes a =recommended approach= subheader before the response draft in the task body. The approach is the executor's analysis (situation, options, recommendation with rationale, considerations Craig should weigh) so Craig can evaluate the recommendation itself, not just the wording. This pattern is kept here as the shared reference; the triage engine and any response-drafting step follow it.

Skip the approach subheader for routine acknowledgments, simple status replies, or "yep, looks good" approvals.

Source-specific examples of when to *include* the approach subheader:

- *Email:* decisions like grant applications, partnership replies, public-facing or sensitive responses
- *Slack:* @mentions with explicit asks, items where someone is blocked waiting on Craig
- *Linear:* @mentions requesting input, Blocked tickets Craig owns, Needs-Review items where the call isn't trivially obvious

Format (consistent across all three sources):

#+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"= so they're accurate, not estimated.

*** Sub-step 3a: From todo.org

1. Pull all [#A] tasks from todo.org.
2. Add time-sensitive items (DEADLINE: or SCHEDULED: touching the day).
3. Carry forward unfinished items surfaced by Phase 2 — but skip any item already added by step 1 or 2 above. A task that was [#A] yesterday and didn't finish gets carried forward by Phase 2 and would also re-appear in step 1's [#A] pull. Dedupe by org-mode heading text or =:ID:= property if present.
4. Pull open =:reactive:= tasks (created by prior preps under the *Triage Action items become =:quick:reactive:= todo.org tasks* convention) — these are pending quick-fire responses that should stay visible until processed. Dedupe against steps 1-3. Surface them as thin links in Day's Priorities; Craig drops the ones that don't fit today's plan.

Priorities typically include:
- Messages to send (Slack, email)
- Meetings to schedule
- Documents to send out for review
- Follow-ups to make
- Prep work needed before a meeting

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

Don't scan email / Slack / Linear / PRs inline here. Run the =triage-intake.org= engine. It fans out across its source plugins, classifies each item against the shared four-bucket model (Action / FYI / Noise-keep / Noise-trash), synthesizes a single deduped summary, writes every Action item into =todo.org= as its own =:quick:reactive:= task, and executes the triage actions (star / mark-read / trash) on Craig's confirmation. That is the same work sub-steps 3b-3g used to do inline; the engine now owns it, so a source change lives in one plugin instead of being duplicated here.

*Source coverage comes from the engine's Phase 0 plugin load.* triage-intake Phase 0 globs both =.ai/workflows/triage-intake.*.org= (general plugins: cmail, github-prs, personal-calendar, personal-gmail) and =.ai/project-workflows/triage-intake.*.org= (the project's own, e.g. the work account's Gmail, Slack, Linear, and GHE PRs). So everything daily-prep used to scan inline stays covered as long as the project ships its source plugins there. If a source isn't covered, the gap is a missing plugin in =.ai/project-workflows/=, not a daily-prep regression.

The engine tracks its own "since when?" sentinel. Pass it the prior prep doc's mtime as the window if the project wants the prep cadence to drive triage scope; otherwise let it use its sentinel.

*** Sub-step 3c: Surface today's reactive items in Day's Priorities

The engine (3b) and sub-step 3a's =:reactive:= pull have populated =todo.org= with the open quick-fire tasks. For each that belongs in *today's* plan (a deadline, a blocker, or someone waiting decides "today"), add a thin link under =* Day's Priorities=:

#+begin_example
** TODO [#B] <verb> <Person / topic> — [[file:../todo.org::*<task title>][todo.org]]
<one line on why today>
#+end_example

Items that don't fit today stay in =todo.org= and resurface on a future prep via 3a's =:reactive:= pull. Don't duplicate task bodies into the prep doc; the thin link is the whole entry (2026-05-12 rule).

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

Re-order the entries under =* Day's Priorities= by urgency: (1) deadlines today or overdue, (2) Craig blocking someone, (3) deadlines within ~48h, (4) other [#A], (5) time-sensitive lower-stakes, (6) everything else. Entries are all thin links now, so it's a flat reorder of heading lines. Craig refines when he reviews; this just gives a sane starting order.

*** Sub-step 3e: Phase 3 audit footer (forcing function)

After 3a-3d, write a single comment line directly below the =#+DATE:= header recording which sources the triage engine actually covered:

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

Take the per-source marks from the engine's synthesis (its Phase C reports per-plugin coverage). Replace ✓ with ✗ plus a parenthetical reason for any source the engine couldn't reach (e.g. =Slack ✗ (MCP disconnected)=). A source scanned with no items keeps its ✓ — empty is a valid result; this line catches a source that did not run at all.

** Phase 4: Time Blocking

Once priorities are confirmed, block time on the calendar to accomplish them. Phase 4 also writes the prep doc's =* Meetings / Work Blocks= section — a single chronological list interleaving meetings with focused-work blocks, top to bottom in time order.

*** Quick Tasks (< 5 minutes)
Tasks like "schedule a meeting with Ryan" or "send a Slack message" should be done during the prep workflow itself, not scheduled separately. Draft the message or create the calendar event on the spot.

*** Focused Work Tasks
For anything requiring more than a few minutes:

1. Ask Craig for a time estimate on each item
2. Use the Phase A calendar snapshot — *do not re-query the calendars*. The same events are already in context.
3. *Compute the day's active window.* Default 10:00 to 17:00, every day of the week (weekends included). If the prep is being run *same-day* (the prep doc's date matches today's date) and the workflow start-time is later than 10:00, the window starts at the start-time instead. Existing calendar appointments, known personal commitments (guests arriving, travel, off-time blocks Craig flagged), and the last-30-min next-day-prep reservation remove time from the window. Whatever's left is fillable with priorities. Don't auto-treat Saturday or Sunday as "off." Fill the window with tasks. If Craig wants personal time on a weekend, he marks it on the calendar or flags it during prep.
4. List the schedule with open slots clearly marked. Show the active window's start, end, and remaining fillable minutes after subtracting appointments.
5. Propose when each task fits, considering:
   - Meeting proximity (prep work should be near the meeting it supports)
   - Energy/focus (harder tasks earlier if possible)
   - A half hour around lunchtime to eat when possible (protein shake or leftovers is fine -- this can be compressed or skipped on heavy days)
   - Always reserve the last 30 minutes of the workday for daily prep for the following day. This is non-negotiable -- it's what keeps the cycle going.
6. Craig confirms or adjusts the proposed schedule

*** Placing Calendar Blocks
- Place time blocks on Craig's personal Google calendar (=Craig Google=)
- Can also place blocks on DeepSat calendar directly using MCP server with =account_id: "work"=
- Use the calendar event workflows (add-calendar-event.org) for creating events

** Phase 5: Prep Work

With the schedule set, work on anything that needs to be ready for the day's meetings. Examples:

- Watch tutorial videos and take notes
- Draft or polish documents for review
- Prepare talking points or materials
- Research topics that will come up in meetings
- Draft messages that are part of the day's priorities

This phase is where the bulk of the session time goes. Work through items in priority order, with meeting-related prep taking precedence based on meeting time.

** Phase 6: Standup Brief

Generate the standup brief late in the workflow so the rest of the day's analysis is already done. The brief draws from Phase 2 (Planned vs Actual), Phase 3 (Day's Priorities), and the activity sweep below. Phase 6 writes the prep doc's =* Standup Briefs= section.

Skip this phase entirely on days with no standup on the calendar.

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

Before drafting, check these sources for activity since the previous prep doc's date (the lookback anchor from Phase A step 5):

1. *Sent email* — both accounts. Outgoing threads from Craig: decisions communicated, replies to action items, follow-ups, intros made.
2. *Slack* — Craig's recent messages across channels and DMs. Decisions, status updates, threads where Craig participated.
3. *todo.org* — items marked DONE since the cutoff. New TODOs added that hint at fresh context (new commitments, new blockers).
4. *Linear* — tickets Craig moved to a new state, commented on, or created. Use the Linear MCP to query.

These surface team-visible work that lives outside session history (work done in mu4e, Slack, the Linear UI, or off-Claude conversations).

*** Step 2: Draft the brief

Combine session history + the Step 1 sweep + Phase 3 priorities + todo.org WAITING items into the three-question structure below.

*Meeting selection.* Recurring meetings are excluded from both the Yesterday and Today sections — they're not news to the team. For non-recurring meetings:

- *Yesterday section:* include only meetings Craig actually attended. Filter on Craig's own response status from the calendar event:
  - =accepted= → include
  - =tentative= or =declined= → exclude (don't assume attendance)
- *Today section:* include all non-recurring meetings regardless of response status. Craig still needs to communicate what he plans to attend or decide between.

The Google Calendar MCP returns =responseStatus= per attendee — filter on Craig's own response, not the event's overall status. Recurring events expose =recurringEventId= or =recurrence=; treat the presence of either as the recurring marker.

*Content rules.*

- *Stay first-person.* Report what Craig did, said, or decided. Don't volunteer others for work or report what others said they would do — that's their standup, not Craig's. If a teammate's commitment is relevant context, frame it as something Craig is waiting on, not as a status update on their behalf.
- *Match deadline precision to what's actually known.* If a deadline is "early next week," don't tighten it to "Monday." If the commitment is "before the proposal goes out," don't sharpen it to "Friday EOD." Vague is honest when vague is the truth.

1. *What did I do since last standup?* Anchor the lookback at the previous prep doc's date (Phase A step 5). Pull session history, session-context.org, completed tasks, and the Step 1 sweep results from that date forward. Since DeepSat standup is a workday-recurring meeting, the previous prep doc's date is the previous standup date even if intervening days were weekends or PTO. Use explicit day references ("Monday" not "yesterday") since the prep doc may be written the evening before.
2. *What am I doing today?* Pull from the day's priorities (Phase 3 output). Keep it to 2-3 items max.
3. *Blockers: mine or yours?* The bar is "did this actually stop me from making progress?", not "is someone else involved?" A WAITING item in todo.org is only a blocker if Craig already tried to move forward and got stopped. Mere dependencies don't qualify unless they've already impaired progress. Default to under-reporting — draft without borderline items and let Craig add them back in Step 3. FYI items (decisions or context worth flagging that aren't blockers) come after blockers and stay loose.

The brief should be concise enough to read aloud in under 60 seconds. Include enough context that Craig doesn't have to think on his feet, but not so much that it turns into a status report.

*** Step 3: Present the draft and ask what's missing

Show Craig the full draft brief — Yesterday, Today, Blockers/FYI sections all populated. Then ask:

#+begin_quote
Anything I missed? Common categories: off-Claude meetings or phone calls, paperwork or forms submitted, intros made or received, vendor conversations, anything else not captured in session/email/Slack/Linear.
#+end_quote

Recognition is faster than recall. Craig can react to "did you make any intros?" much faster than to "what did you do?" The categories are prompts, not a checklist.

*** Step 4: Refine and finalize

Apply Craig's additions and any wording adjustments. The brief is now ready for standup.

*** Step 5: Offer to capture learnings

After Step 4, scan Craig's refinements for non-obvious patterns:

- Did he cut a category of item the workflow said to include?
- Did he add a category the workflow didn't tell you to look for?
- Did he change wording in a way that suggests a phrasing rule (e.g., "say 'continued focus on X' instead of 'worked on X'")?

If a refinement looks like a generalizable rule, offer it back to Craig:

#+begin_quote
I noticed you [removed all 1:1 meetings from Yesterday / added the off-Claude phone call with Ryan / changed "completed proposal draft" to "continued focus on proposal"]. Want me to add this to the workflow? Proposed rule: "[concrete rule text]"
#+end_quote

Wait for explicit confirmation before editing the workflow. Never edit on your own judgment.

If Craig confirms, append the rule to the *Updates and Learnings* section at the bottom of this file with today's date and a one-line description. If the new rule supersedes existing text inside Phase 6, also update the inline text and note "(updated YYYY-MM-DD — see Updates and Learnings)" in the affected section so the audit trail is complete.

If the refinement looks like a one-off, don't propose a rule. Default to under-proposing — false-positive rules clutter the workflow. The bar is "would I want this guidance the next time I draft a brief?" If yes, propose. If no, drop it.

** Phase 7: Final Section Writeups

Three sections remain after Phase 6: =* Heads-up=, =* Upcoming Deadlines=, and the next day's =* [Day]'s Anchor Tasks=. Phase 7 writes them, drawing on what earlier phases already surfaced.

Order doesn't matter between the three sub-steps. They write to distinct sections and don't depend on each other.

*** Sub-step 7a: Heads-up

Write a top-level =* Heads-up= section near the top of the prep doc (above =* Day's Priorities=).

Heads-up is the executive summary of what would change Craig's frame for the day. Terse, situational, day-shaping. Pull from sources earlier phases surfaced:

- *Substantial FYIs* from the triage engine's synthesis (sub-step 3b) — items like "Eric quietly progressed two partnership threads on Apr 24" or "Vrezh force-pushed all three branches overnight" that affect what Craig should expect today
- *Schedule changes* from Phase 1 — "Arusyak 15:00-16:00 is being rescheduled" or "DeepSat GTM declined for tonight"
- *Urgent deadlines bubbling up* — items in =* Upcoming Deadlines= that hit within ~2 days, surfaced as standalone Heads-up items so Craig sees them immediately
- *Active Reminders* (from Phase A's notes.org read) that frame today specifically — "first thing in the morning, register for SOFWeek"

Format: bullet list, one situational note per line, no sub-bullets. Keep each entry to one sentence. If a Heads-up item needs more context, link to the source (email, ticket, prep section) instead of inlining.

Lightweight FYIs (status pings, "FYI we shipped", small acknowledgments) stay in =.ai/session-context.org= and don't surface in Heads-up.

*** Sub-step 7b: Upcoming Deadlines

Write a top-level =* Upcoming Deadlines= section.

Source: scan todo.org for =DEADLINE:= entries plus deadlines mentioned in notes.org or knowledge.org. Filter to roughly the next 4-6 weeks. Order chronologically.

Format: bullet list, one deadline per line, format =- [Day YYYY-MM-DD] — short description=. Mention the owner if it isn't Craig and the deadline still concerns him (e.g., "Subbu owns; Craig's technical content due ahead of this").

Volume control: if more than ~10 deadlines fit the window, narrow the window or surface only the ones that are blocking, externally-imposed, or have non-trivial prep ahead.

Don't duplicate deadlines that are already today's =* Day's Priorities= entries. Day's Priorities is for action; Upcoming Deadlines is for awareness.

*** Sub-step 7c: Next day's Anchor Tasks

Write a top-level =* [Day]'s Anchor Tasks= section. Compute the next day's name from today's date — *don't* skip weekends. For a Friday prep doc this becomes =* Saturday's Anchor Tasks=, for a Saturday prep doc it becomes =* Sunday's Anchor Tasks=, etc. Use known PTO markers if any (a fully-blocked PTO day can be skipped to the next available day).

Source: items Craig is explicitly committing to do tomorrow. Pull from:

- Items planned for today that didn't get done (from Phase 2's Planned vs Actual)
- Items that genuinely fit tomorrow better than today (criterion below)
- Prep work needed before tomorrow's meetings
- Anything Craig flagged during today's session as "I'll do this tomorrow"

*Criterion for pushing an item to tomorrow rather than fitting it today.* Push only if at least one is true:

1. *Hard-blocked today* — waiting on a person, a system, or a deadline that hasn't passed yet
2. *Needs a contiguous block* today's window can't provide
3. *Prep work for a tomorrow-only meeting* (do the prep close to the meeting)
4. *Team-dependent* and the team isn't available today (e.g., Craig's at one location and the team's at another)

If none of those apply, the item stays in today's Day's Priorities and gets a time block in Phase 4. Don't auto-punt independent reading, registration, local-machine work, or "I'll get to it tomorrow" items just because today is a weekend or feels light.

Items further out than tomorrow (Monday-only items written on a Saturday, for example) stay in =todo.org= with appropriate priority and SCHEDULED markers. Don't list them in the prep doc — they'll resurface in the relevant day's prep via Phase 3 sub-step 3a.

Format: bullet list or =** TODO= headings, with optional time estimates (e.g., "— 1.5 hrs"). Each item should be a clear task — passive monitoring or context goes elsewhere (Heads-up or session-context).

This section is the explicit handoff to next-day's Phase 2. If it's empty, write the header with "(none flagged)" so the next day's prep doesn't mistake an empty section for a missing one.

** Phase 8: Repoint the Current-Day Symlink

Prep docs are *born* in their permanent home and never move. The home is
=daily-prep/= at repo root: every prep doc is created directly as
=daily-prep/YYYY-MM-DD-daily-prep.org= (Phase A onward writes there), and the
dated files accumulate in place. There is no archive move — =daily-prep/= is
both the working location and the archive.

A single stable symlink at the project root — =daily-prep.org= — points at the
current day's file. The only day-to-day change is repointing it. After the new
prep doc exists, point the symlink at it:

#+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 (=C-c p d=), next-day Phase 2, the standup
lookback — resolve =daily-prep.org= rather than computing a filename or
searching =inbox/=. Nothing prep-related lands in =inbox/= anymore.

Setup / migration (first run in a project on this convention):

- If =daily-prep/= doesn't exist yet, create it.
- Move any existing =inbox/*-daily-prep.org= (the old born-in-inbox location)
  into =daily-prep/=, and any stale prep doc under =assets/= (an even older
  convention) likewise. Then create the root =daily-prep.org= symlink at the
  most recent one.
- Don't put prep docs in =deepsat/meetings/= — the prep doc covers personal
  calendar, all 1:1s, and all projects, not just DeepSat work.

This keeps =inbox/= free of prep-doc churn and makes "today's prep" a single
predictable path instead of a dated filename that has to be reconstructed.

** Phase 9: Project Extension

If =.ai/project-workflows/daily-prep.org= exists, read and execute its instructions as additional steps appended to this workflow. The project file contains add-ons specific to the project. It is *not* a replacement for this template — it picks up where this workflow's main flow ends.

Surface the extension once per session ("Project has additional daily-prep steps — running them now") so the choice is visible.

This is the project-extension hook from [[file:startup.org][startup.org]]'s workflow discovery rule, made explicit at the workflow level so it's not buried in discovery instructions. Runs in both full-prep and standup-only modes.

* Principles to Follow

** Prep Supports Action
The goal is for Craig to walk into every meeting and task with what he needs. If prep doesn't lead to better outcomes, it's wasted time.

** Craig Drives Priorities
Claude surfaces information and proposes priorities, but Craig decides what matters. Don't assume -- ask.

** Quick Tasks: Just Do Them
If something takes less than 5 minutes, do it during prep rather than scheduling it. Draft the Slack message, create the calendar invite, send the email.

** Respect the Calendar
When proposing time blocks, respect existing commitments across all calendars. Don't double-book. Account for transition time between meetings.

** First-Person Perspective
When preparing 1:1 talking points, frame everything from Craig's perspective -- what does Craig need to communicate, ask, or decide? Not what the other person needs.

* 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: Vrezh 1:1, Standup/IPM, Product Review, Backlog Planning).

*** 2026-02-23: Use explicit day references, not relative terms
When referring to past meetings or events, always include the explicit day (e.g., "from Monday's meeting" not "from this morning's meeting"). The prep doc may be written the day before and read the day of -- relative references like "this morning" or "today" become ambiguous. Include the day name so Craig doesn't have to calculate days in his head while focused on making a point.

*** 2026-02-23: Prep doc output
The prep was originally written to =inbox/YYYY-MM-DD-daily-prep.org= where the date is the day being prepped for. (Superseded 2026-06-01 — prep docs now live in =daily-prep/= with a root =daily-prep.org= symlink. See the 2026-06-01 entry below and Phase 8.)
The startup workflow checks for this file and asks whether to open it. Note: need to resolve where the daily prep reference in startup.org lives so template syncing doesn't overwrite it (see todo.org task).

*** 2026-02-23: Check for dependencies between tasks and meetings
Tasks and meetings often depend on each other. SkyFi prep needs to happen before the Vrezh 1:1 so Craig can ask informed questions; Linear learning needs to happen before the backlog planning meeting where they'll use it. Always check for these dependencies and ask Craig when unsure.

*** 2026-02-23: Energy management matters as much as time management
Front-load high-effort, high-stakes work early in the day (about an hour after waking). Save research, reading, and lighter tasks for late afternoon when energy dips. Craig tries to eat lunch and have coffee/tea around 12:30 PM to sustain energy for the afternoon. This principle should guide time block placement alongside calendar constraints.

*** 2026-02-23: Link references in the prep doc
When listing tasks, documents, or directories in the prep doc, include links to the source
(todo.org line numbers, file paths, directories). Craig shouldn't have to search for context
when he's in the middle of a meeting or working through the day.

*** 2026-02-23: Note dependencies between time blocks
When an earlier time block feeds into a later meeting, call it out explicitly in the prep doc
(e.g., "by this point, should have already checked Okta access"). Helps Craig verify he's
on track as the day progresses.

*** 2026-02-23: Prep doc is a living document through the day
Craig may annotate the prep doc with "cj:" comments as he works through it. Process those
when asked or at the start of the next session. Remove the comment markers after acting on them.

*** 2026-02-23: Ask probing questions about task nature
When a task like "SkyFi outreach" could mean either a 5-minute email or a 1-hour call, ask. The answer often splits the task into prep + action, which schedule differently. These questions are very helpful and should be a regular part of the workflow.

*** 2026-03-08: Keep Day's Priorities, drop separate Time Blocking table
The output prep doc should have a "Day's Priorities" section followed by a single chronological
"Meetings / Work Blocks" section that interleaves meetings, prep blocks, and focused work blocks
in time order. No separate Time Blocking table — the chronological Meetings / Work Blocks section
serves that purpose.

*** 2026-03-09: Day's Priorities use org-mode TODO headings, not numbered lists
Each priority is a =** TODO= heading under =* Day's Priorities=, not a numbered list item.
Format: =** TODO Task name — description. Links to todo.org or other files. ~time estimate.=
Do not use bold or italic markup in the prep doc — org headings, TODO keywords, and plain text
provide enough structure.
Mark completed items as =** DONE= with a =CLOSED:= timestamp on the next line.
Order by urgency and priority — most important/time-sensitive first. Craig should be able to
work top-to-bottom and know he's tackling the right thing next.
This makes priorities trackable in org-mode (agenda, todo filtering) and lets Craig toggle
status directly in Emacs as the day progresses.

The workflow phases (identify priorities, propose time blocks) still happen during the prep
conversation — the change is only to the output format.

*** 2026-03-08: Always include Planned vs Actual
Craig finds the Planned vs Actual review table valuable. Always include it in the prep doc
when a previous day's prep doc exists. This is Phase 2 of the workflow and should never be skipped.

*** 2026-04-01: Always use human-readable ticket titles
When referencing Linear tickets (or any issue tracker IDs), always use the human-readable
title with the ID in parentheses — e.g., "Setup Database for dev environment (SE-93)" not
just "SE-93." Craig can't remember what ticket IDs map to, and bare IDs force him to look
them up. Use the Linear MCP tools to fetch the title if needed.

*** 2026-03-27: Standup briefs — only team-visible goals, not personal productivity
Only include work that left Craig's local environment: pushed to a repo, shared with
the team, posted in Slack, changed something in Linear, or shifts what the team believes
or plans. Exclude work whose output lives entirely in Craig's local files (knowledge.org,
todo.org, session notes, transcript processing, local tooling setup, MCP server config).
Filter: "If I didn't mention this, would someone on the team make a worse decision or
duplicate the work?" If no, cut it.

*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks — never duplicated content
Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, VERIFY asks, recommended-approach — lives in the matching todo.org task, which Phase 3 creates or updates. Completed-today entries still become dated log headings in the prep doc (the day's record), linking to their durable todo.org home if there is one. Full statement in *Prep Doc Structure ▸ Day's Priorities entries are thin links to todo.org tasks* above. Follow-up: Phase 3 sub-steps 3b–3f still say "add to the prep doc" — reword them to "create/update the todo.org task, link from the prep doc" on the next pass. (Supersedes the 2026-03-09 "Day's Priorities use org-mode TODO headings" entry's implication that the content lives in the prep doc — the headings still use TODO keywords / dated-log headings, but the body is a link.)

*** 2026-05-15: Triage Action items become =:quick:reactive:= todo.org tasks — no grouped Response sub-sections
Craig's call, originally landed in the work project's =triage-intake= workflow on 2026-05-15 and propagated here on 2026-05-16. Each Action item surfaced by Phase 3 sub-steps 3b/3d/3e/3f (email, Slack, Linear, PRs) becomes its own =** TODO [#B] <verb-led description> :quick:reactive:[person]:= in =todo.org=. The Day's Priorities section in the prep doc references it via a thin link when it belongs in today's plan, otherwise the task stays in =todo.org= for later. Replaces the prior pattern of building grouped =** Email Response= / =** Slack Response= / =** Linear Response= / =** PR Review= sub-headings under Day's Priorities — those sub-sections no longer exist. Source mix now lives in the tags on each task, not in the prep doc structure. Full statement in *Prep Doc Structure ▸ Triage Action items become =:quick:reactive:= todo.org tasks* above. (Closes the 2026-05-12 follow-up about rewording sub-steps 3b–3f.)

*** 2026-05-31: Delegate triage to the triage-intake engine
Phase 3's inline source scans — sub-steps 3b (email), 3c (mark-read), 3d (Slack), 3e (Linear), 3f (PRs), and 3g's cross-source dedup, ~280 lines — duplicated what the =triage-intake.org= engine has owned since its 2026-05-26 engine/plugin refactor. Collapsed them to four steps: 3b runs the engine (it fans out across general + project source plugins, classifies, synthesizes, writes the =:quick:reactive:= tasks, and executes star/mark-read/trash on confirmation); 3c surfaces today's reactive items as Day's Priorities thin links; 3d re-sorts by urgency; 3e writes the audit footer from the engine's per-source coverage. Source coverage carries because the engine's Phase 0 globs both =.ai/workflows/= and =.ai/project-workflows/= plugins, so the work account's Gmail/Slack/Linear/GHE plugins are still scanned — the delegation must not drop them, and Phase 0's two-dir glob is what guarantees it. The Recommended Approach Pattern stayed here as the shared reference (the engine applies it when writing reactive-task bodies); a future tidy could move it into the engine. Also closes the 2026-05-12 follow-up about rewording sub-steps 3b-3f.

*** 2026-06-01: Prep docs live in =daily-prep/= with a root =daily-prep.org= symlink — no inbox churn, no archive move
Craig's call. The prep doc is now *born* in =daily-prep/YYYY-MM-DD-daily-prep.org= and never moves; the dated files accumulate there as both working location and archive. A single stable symlink at the project root — =daily-prep.org= — points at the current day's file, repointed each prep run with =ln -sf=. Replaces the prior model where the doc was born in =inbox/YYYY-MM-DD-daily-prep.org=, yesterday's stayed in =inbox/=, and older docs were =mv='d into the =daily-prep/= archive (old Phase 8). Consumers resolve the root symlink instead of computing a dated filename or searching =inbox/=: the Emacs opener =C-c p d= (=cj/open-project-daily-prep=, repointed from =inbox/today-prep.org= to =daily-prep.org= — handoff filed to the =.emacs.d= project 2026-06-01), next-day Phase 2, and the standup lookback (Phase A step 5, which now globs =daily-prep/= and takes the file before the symlink's target). Touchpoints updated: Phase A step 5 + slim-Phase-A step 2 (lookback), standup-only "Where the brief lands," Phase 8 (rewritten as "Repoint the Current-Day Symlink"). Cross-workflow: =triage-intake.org='s sentinel-anchor fallback dropped its =inbox/= prep-doc path. (=wrap-it-up.org= was left as-is — its =inbox/= references are about =lint-followups.org= routing, not the prep doc, so they stay correct.) Migration is one-time per project: move existing =inbox/*-daily-prep.org= into =daily-prep/= and create the root symlink at the most recent.