diff options
| -rw-r--r-- | .ai/workflows/daily-prep.org | 140 | ||||
| -rw-r--r-- | claude-templates/.ai/workflows/daily-prep.org | 140 |
2 files changed, 164 insertions, 116 deletions
diff --git a/.ai/workflows/daily-prep.org b/.ai/workflows/daily-prep.org index 319e94f..6589355 100644 --- a/.ai/workflows/daily-prep.org +++ b/.ai/workflows/daily-prep.org @@ -81,7 +81,7 @@ Canonical sections (full-prep mode produces all; standup-only produces just =* S | 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 (with Email/Slack/Linear Response sub-sections) | +| =* 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 | @@ -104,7 +104,36 @@ 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. The Phase 3 sub-steps 3b–3f below still describe writing content into the prep doc's Response sub-sections — reword them to "create/update the todo.org task, link from the prep doc" on the next workflow pass.) +(Craig's instruction, 2026-05-12, extended 2026-05-15. Sub-steps 3b–3f below implement 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 surfaced by Phase 3 sub-steps 3b–3f (email, Slack, Linear, PRs) 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 @@ -175,13 +204,11 @@ This step keeps the daily prep honest. If a 1-hour task consistently takes 3 hou Assemble priorities automatically from multiple sources. No interactive confirmation. Craig reviews the prep doc as a whole when it's done. -Write the assembled list as =TODO= entries under the prep doc's =* Day's Priorities= section. Order by urgency — most time-sensitive or blocking first. If Craig wants to add or remove a priority, he edits the prep doc directly. - -Sources contributing to Day's Priorities: todo.org, email, Slack, Linear. +For each Action item: create or update a =:quick:reactive:= task in =todo.org= per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. Then, if the item belongs in today's plan, add a thin-link entry under the prep doc's =* Day's Priorities= section. Order Day's Priorities by urgency — most time-sensitive or blocking first. If Craig wants to add or remove a priority, he edits the prep doc directly. -*Don't create empty response sub-section headers.* Only emit =** Email Response=, =** Slack Response=, or =** Linear Response= when there's at least one item to put under it. The =# Sources checked:= footer at the top of the prep doc shows which sources were scanned (✓ = ran, ✗ = skipped) — Craig already knows from the footer that Slack and Linear were checked even when those subsections aren't in the doc. Empty headers add visual noise and imply something was missed. +Sources contributing to Day's Priorities: todo.org, email, Slack, Linear, PRs. -*Linear digest / notification emails don't get their own TODO.* If sub-step 3b returns a Linear digest email saying "you have N unread notifications," that's not an Action item — Linear notifications surface either via 3e (the direct Linear query) or via the underlying per-notification emails Linear sends. Classify the digest as Noise-keep (or Noise-trash if the per-notification emails are also flowing through) and don't add a separate "Linear notifications check" entry to Day's Priorities. +*Linear digest / notification emails don't get their own task.* If sub-step 3b returns a Linear digest email saying "you have N unread notifications," that's not an Action item — Linear notifications surface either via 3e (the direct Linear query) or via the underlying per-notification emails Linear sends. Classify the digest as Noise-keep (or Noise-trash if the per-notification emails are also flowing through) and don't add a separate "Linear notifications check" todo.org task. *** Recommended Approach Pattern (used by sub-steps 3b, 3d, 3e) @@ -211,6 +238,7 @@ Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"= so they're accurate 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) @@ -287,16 +315,15 @@ For each Action item: - =.ai/session-context.org= — today's session context: what was read, decisions made or pending, follow-ups identified for later in the session. When in doubt, default to session-context. The next session can promote anything worth keeping into knowledge.org during wrap-up. 4. *People-Context Check (runs before the recommended response is drafted).* When the Action item involves a specific person (sender, recipient, or a named third party referenced in the body), look that person up in =deepsat/knowledge.org= (Key People table, plus the Team Details section if present). Pull role and reporting line, relationships to other key people (family, prior employer, advisor vs. employee), tone and working-style signals, and recent context that affects how Craig should phrase the response. If the person isn't in =knowledge.org=, capture what's known there before writing the draft — the people layer is persistent context, every future prep gets faster when this layer is complete. Skip the check for purely transactional senders (Mercury, GitHub notifications, Linear bots). The recommended-approach + recommended-response then incorporates the people-context: tone, channel choice (email vs Slack vs in-person), and framing should reflect the relationship. -5. *Add to the prep doc* under Day's Priorities as an =Email Response= sub-section: +5. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Reply / Read / Approve / Decline / Schedule), the source link as =[[mail-link][From X: Subject]]= form, and tags =:quick:reactive:[person]:=. The recommended-approach + recommended-response content (per the Recommended Approach Pattern) goes in the task body, not the heading. +6. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example - ** Email Response - *** [[mail-link][From X: Subject]] - - One-line description of why action is needed. - - Suggested action: reply with status / approve / decline / schedule. - <recommended approach + recommended response per the Recommended Approach Pattern above> + ** TODO [#B] Reply to <Person> re: <subject> — [[file:../todo.org::*Reply to <Person>][todo.org]] + <one line on why today — deadline, blocker, who's waiting> #+end_example + Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content into knowledge.org or session-context per the routing above, then drop it from further processing. Don't add to the prep doc. +For each FYI item: read it, capture substantive content into knowledge.org or session-context per the routing above, then drop it from further processing. Don't add to the prep doc or =todo.org=. For each Noise-keep item: no per-message action beyond the read-state pass at sub-step 3c. Don't add to the prep doc. @@ -311,7 +338,7 @@ mcp__google-docs-work__trashMessage --messageId <id> # DeepSat account python3 .ai/scripts/maildir-flag-manager.py trash --reindex /path/to/message.eml #+end_src -Don't duplicate Email Response items as standalone Day's Priorities entries — the =Email Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the email body, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3c: Mark processed email as read @@ -352,20 +379,19 @@ For each Action item: 1. *Read* the message and surrounding thread context. 2. *Capture substantive content* in =deepsat/knowledge.org= (or the project's equivalent) for persistent project facts, or =.ai/session-context.org= for today's context. Same routing rules as Sub-step 3b — default to session-context when unsure. 3. *People-Context Check* — same as sub-step 3b's step 4. When the message involves a specific person, look them up in =knowledge.org= before drafting. Skip for transactional bot pings. -4. *Add to the prep doc* under Day's Priorities as a =Slack Response= sub-section: +4. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Reply / React / Address / Schedule), the source link as =[[slack-permalink][From X in #channel: brief description]]= form, and tags =:quick:reactive:[person]:=. The recommended-approach + recommended-response content goes in the task body. +5. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example - ** Slack Response - *** [[slack-permalink][From X in #channel: brief description]] - - One-line description of why action is needed. - - Suggested action: reply / react / move to thread / schedule. - <recommended approach + recommended response per the Recommended Approach Pattern above> + ** TODO [#B] Reply to <Person> re: <topic> — [[file:../todo.org::*Reply to <Person>][todo.org]] + <one line on why today — who's blocked, 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 sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry. +For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry or todo.org task. After processing all items, mark *only the specific DMs and @mentions we touched* as read in Slack — not channel-wide. The Slack MCP should expose a per-message mark-read capability; if the available MCP doesn't support it, skip this step and let Craig manage Slack read state himself. Do NOT mark channel chatter as read; only the items the query returned. -Don't duplicate Slack Response items as standalone Day's Priorities entries — the =Slack Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the message text, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3e: From Linear @@ -388,32 +414,29 @@ For each Action item: 1. *Read the ticket* — description, recent comments, state history. 2. *Capture substantive content* in =deepsat/knowledge.org= (people roles, system facts, strategic decisions) or =.ai/session-context.org= (today's review notes). Same routing rules as Sub-step 3b — default to session-context when unsure. 3. *People-Context Check* — same as sub-step 3b's step 4. When the ticket involves a specific person (assignee, reviewer, commenter, @mentioned), look them up in =knowledge.org= before drafting. Skip for bot updates and automated transitions. -4. *Add to the prep doc* under Day's Priorities as a =Linear Response= sub-section: - #+begin_example - ** Linear Response - *** [[https://linear.app/...][SE-NNN]] Ticket title (state, assignee) - - Why action needed: one-liner (e.g., "Vrezh moved to Needs Review, awaiting Craig"). - - Suggested action: review code / post comment / change state to X. - <recommended approach + recommended response per the Recommended Approach Pattern above> - #+end_example - - Linear's =recommended response= can be a draft comment, a proposed state change with rationale, or a combined action like "comment + reassign to Vrezh" — the response is "what Craig should do," not just reply text. +4. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Review / Comment / Resolve / Address), the source link as =[[https://linear.app/...][SE-NNN ticket title]]= form, and tags =:quick:reactive:[person]:=. The recommended approach + recommended response (draft comment, proposed state change, combined action like "comment + reassign to Vrezh" — "what Craig should do," not just reply text) goes in the task body. - *When the action item is a comment or @mention,* don't write "read X's comment." Fetch the comment via =mcp__linear__list_comments= and paste it inline as a child header so Craig can answer in the prep doc: + *When the action item is a comment or @mention,* paste the comment text into the task body so Craig can draft a reply against it. Fetch via =mcp__linear__list_comments=: #+begin_example - *** [[https://linear.app/...][SE-NNN]] Ticket title — <Author> @mentioned Craig in a comment - - Why action needed: direct @mention; ties to <related ticket if any>. - - Suggested action: answer inline below; I'll post the reply on the ticket. - **** <Author> — <YYYY-MM-DD HH:MM> — comment on SE-NNN + ** TODO [#B] Reply to <Author> on [[https://linear.app/...][SE-NNN]] :quick:reactive:[author]: + Why action needed: direct @mention; ties to <related ticket if any>. + + *** <Author> — <YYYY-MM-DD HH:MM> — comment on SE-NNN #+begin_quote <the comment text, verbatim> #+end_quote - ***** Craig's reply (fill in / approve, then I post it to the ticket) + *** Craig's reply (fill in / approve, then I post it to the ticket) <placeholder> #+end_example Same idea for an FYI comment Craig should see — paste it, don't just reference it. (Feedback memory: =feedback_linear_comment_as_child_header=.) +5. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: + #+begin_example + ** TODO [#B] Review SE-NNN <ticket title> — [[file:../todo.org::*Review SE-NNN][todo.org]] + <one line on why today — Needs Review, blocker, deadline> + #+end_example + Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry. +For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry or todo.org task. *Two deliberate divergences from email/Slack:* @@ -422,7 +445,7 @@ For each FYI item: read it, capture substantive content per the routing above, t *Volume note:* if a query returns >20 tickets, surface the count and prioritize Action signals first (Needs Review assigned to Craig, @mentions, blocked tickets, deadlines). -Don't duplicate Linear Response items as standalone Day's Priorities entries — the =Linear Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the ticket description, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3f: From Open PRs @@ -444,17 +467,17 @@ For each Action item: 1. *Read the PR* — diff summary, recent commits, review state, any unresolved threads. 2. *People-Context Check* — same as sub-step 3b's step 4 for the PR author and the requesting reviewer. -3. *Add to the prep doc* under Day's Priorities as a `** PR Review` sub-section: +3. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Review / Re-review / Unblock), the source link as =[[PR-URL][PR #N title (author)]]= form, and tags =:quick:reactive:[author]:=. The recommended-approach + recommended-response content goes in the task body. +4. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example -** PR Review -*** [[PR-URL][PR #N — title (author, branch)]] -- Why action needed: review requested / re-review after force-push / blocked on Craig's response. -- Suggested action: full review / quick re-review / unblock thread. -<recommended approach + recommended response per the Recommended Approach Pattern above> +** TODO [#B] Review PR #N <title> — [[file:../todo.org::*Review PR #N][todo.org]] +<one line on why today — review requested, blocking author, re-review after force-push> #+end_example -For FYI items: include a short *Craig's own PRs awaiting review (FYI, not action)* sub-list under the PR Review section so the queue stays visible without inflating the action surface. One line per PR: number, short title, who's been requested. +Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. + +For FYI items (Craig's own PRs awaiting review, draft PRs in flight): don't create a todo.org task. Surface them in =* Heads-up= (Phase 7) as a one-line note ("Craig's open PRs awaiting review: #145, #167") so the queue stays visible without inflating the action surface. *Two deliberate divergences from email/Slack:* @@ -463,27 +486,27 @@ For FYI items: include a short *Craig's own PRs awaiting review (FYI, not action *Per-project repo configuration.* The repo path is project-specific. For projects without a primary repo (personal documentation projects, etc.), skip this sub-step and mark `prs ✗ (no primary repo)` in the audit footer. For projects with multiple repos in active development, scan each in turn; surface Action items with the repo name prefixed in the title. -Don't duplicate PR Review items as standalone Day's Priorities entries — the `PR Review` sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the PR description, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3g: Cross-source dedup and urgency re-sort -After 3a-3f have written all their entries to Day's Priorities, do a final cleanup pass. +After 3a-3f have written all their =:quick:reactive:= todo.org tasks and Day's Priorities thin links, do a final cleanup pass. -*Cross-source dedup.* Scan the Email Response, Slack Response, Linear Response, and PR Review sub-sections for items that reference the same conversation or topic. Common cases: +*Cross-source dedup.* Scan the =:reactive:= tasks created this prep cycle for items that reference the same conversation or topic. Common cases: -- Vrezh DMs Craig about a Linear ticket *and* comments on the ticket itself — both surface as separate drafts +- Vrezh DMs Craig about a Linear ticket *and* comments on the ticket itself — both surface as separate =:reactive:= tasks - An email points at "let's discuss on the ticket" — the ticket also has activity - A Slack thread is the followup to an email exchange For each candidate duplicate pair, surface to Craig: #+begin_quote -These two items look like the same conversation: [Email link] and [Linear link]. Should I collapse them under one source, or keep both? +These two reactive tasks look like the same conversation: [task with Email link] and [task with Linear link]. Should I collapse them into one, or keep both? #+end_quote -Wait for Craig's call. If he says collapse, keep the source he picks and add a cross-reference link in the kept item ("see also: [other-link]"). Don't auto-collapse. +Wait for Craig's call. If he says collapse, keep the source he picks, paste the other source link into the task body as "see also: [other-link]", and drop the other task. Drop the matching Day's Priorities thin link too. Don't auto-collapse. -*Urgency re-sort.* Items currently appear in sub-step order (todo.org, then Email Response, then Slack Response, then Linear Response). Re-order all top-level entries under =* Day's Priorities= by urgency: +*Urgency re-sort.* Re-order all entries under =* Day's Priorities= by urgency: 1. Items with deadlines today or already overdue 2. Items where Craig is blocking someone (Slack blocked-on-Craig, Linear Blocked tickets, Needs-Review assigned to Craig) @@ -492,9 +515,7 @@ Wait for Craig's call. If he says collapse, keep the source he picks and add a c 5. Time-sensitive but lower-stakes items 6. Everything else -Within each tier, preserve the source-section structure (Email Response, Slack Response, Linear Response sub-sections stay grouped) — just re-order the top-level entries that aren't already sub-sectioned. - -Craig can re-order further when he reviews the prep doc; this just gives him a sane starting order. +Day's Priorities entries are all thin links to todo.org tasks now (no grouped source sub-sections), so re-ordering is a flat sort — just move the heading lines into urgency order. Craig can re-order further when he reviews the prep doc; this just gives him a sane starting order. *** Sub-step 3h: Phase 3 audit footer (forcing function) @@ -799,3 +820,6 @@ 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.) diff --git a/claude-templates/.ai/workflows/daily-prep.org b/claude-templates/.ai/workflows/daily-prep.org index 319e94f..6589355 100644 --- a/claude-templates/.ai/workflows/daily-prep.org +++ b/claude-templates/.ai/workflows/daily-prep.org @@ -81,7 +81,7 @@ Canonical sections (full-prep mode produces all; standup-only produces just =* S | 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 (with Email/Slack/Linear Response sub-sections) | +| =* 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 | @@ -104,7 +104,36 @@ 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. The Phase 3 sub-steps 3b–3f below still describe writing content into the prep doc's Response sub-sections — reword them to "create/update the todo.org task, link from the prep doc" on the next workflow pass.) +(Craig's instruction, 2026-05-12, extended 2026-05-15. Sub-steps 3b–3f below implement 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 surfaced by Phase 3 sub-steps 3b–3f (email, Slack, Linear, PRs) 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 @@ -175,13 +204,11 @@ This step keeps the daily prep honest. If a 1-hour task consistently takes 3 hou Assemble priorities automatically from multiple sources. No interactive confirmation. Craig reviews the prep doc as a whole when it's done. -Write the assembled list as =TODO= entries under the prep doc's =* Day's Priorities= section. Order by urgency — most time-sensitive or blocking first. If Craig wants to add or remove a priority, he edits the prep doc directly. - -Sources contributing to Day's Priorities: todo.org, email, Slack, Linear. +For each Action item: create or update a =:quick:reactive:= task in =todo.org= per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. Then, if the item belongs in today's plan, add a thin-link entry under the prep doc's =* Day's Priorities= section. Order Day's Priorities by urgency — most time-sensitive or blocking first. If Craig wants to add or remove a priority, he edits the prep doc directly. -*Don't create empty response sub-section headers.* Only emit =** Email Response=, =** Slack Response=, or =** Linear Response= when there's at least one item to put under it. The =# Sources checked:= footer at the top of the prep doc shows which sources were scanned (✓ = ran, ✗ = skipped) — Craig already knows from the footer that Slack and Linear were checked even when those subsections aren't in the doc. Empty headers add visual noise and imply something was missed. +Sources contributing to Day's Priorities: todo.org, email, Slack, Linear, PRs. -*Linear digest / notification emails don't get their own TODO.* If sub-step 3b returns a Linear digest email saying "you have N unread notifications," that's not an Action item — Linear notifications surface either via 3e (the direct Linear query) or via the underlying per-notification emails Linear sends. Classify the digest as Noise-keep (or Noise-trash if the per-notification emails are also flowing through) and don't add a separate "Linear notifications check" entry to Day's Priorities. +*Linear digest / notification emails don't get their own task.* If sub-step 3b returns a Linear digest email saying "you have N unread notifications," that's not an Action item — Linear notifications surface either via 3e (the direct Linear query) or via the underlying per-notification emails Linear sends. Classify the digest as Noise-keep (or Noise-trash if the per-notification emails are also flowing through) and don't add a separate "Linear notifications check" todo.org task. *** Recommended Approach Pattern (used by sub-steps 3b, 3d, 3e) @@ -211,6 +238,7 @@ Generate timestamps with =date "+%Y-%m-%d %a @ %H:%M:%S %z"= so they're accurate 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) @@ -287,16 +315,15 @@ For each Action item: - =.ai/session-context.org= — today's session context: what was read, decisions made or pending, follow-ups identified for later in the session. When in doubt, default to session-context. The next session can promote anything worth keeping into knowledge.org during wrap-up. 4. *People-Context Check (runs before the recommended response is drafted).* When the Action item involves a specific person (sender, recipient, or a named third party referenced in the body), look that person up in =deepsat/knowledge.org= (Key People table, plus the Team Details section if present). Pull role and reporting line, relationships to other key people (family, prior employer, advisor vs. employee), tone and working-style signals, and recent context that affects how Craig should phrase the response. If the person isn't in =knowledge.org=, capture what's known there before writing the draft — the people layer is persistent context, every future prep gets faster when this layer is complete. Skip the check for purely transactional senders (Mercury, GitHub notifications, Linear bots). The recommended-approach + recommended-response then incorporates the people-context: tone, channel choice (email vs Slack vs in-person), and framing should reflect the relationship. -5. *Add to the prep doc* under Day's Priorities as an =Email Response= sub-section: +5. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Reply / Read / Approve / Decline / Schedule), the source link as =[[mail-link][From X: Subject]]= form, and tags =:quick:reactive:[person]:=. The recommended-approach + recommended-response content (per the Recommended Approach Pattern) goes in the task body, not the heading. +6. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example - ** Email Response - *** [[mail-link][From X: Subject]] - - One-line description of why action is needed. - - Suggested action: reply with status / approve / decline / schedule. - <recommended approach + recommended response per the Recommended Approach Pattern above> + ** TODO [#B] Reply to <Person> re: <subject> — [[file:../todo.org::*Reply to <Person>][todo.org]] + <one line on why today — deadline, blocker, who's waiting> #+end_example + Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content into knowledge.org or session-context per the routing above, then drop it from further processing. Don't add to the prep doc. +For each FYI item: read it, capture substantive content into knowledge.org or session-context per the routing above, then drop it from further processing. Don't add to the prep doc or =todo.org=. For each Noise-keep item: no per-message action beyond the read-state pass at sub-step 3c. Don't add to the prep doc. @@ -311,7 +338,7 @@ mcp__google-docs-work__trashMessage --messageId <id> # DeepSat account python3 .ai/scripts/maildir-flag-manager.py trash --reindex /path/to/message.eml #+end_src -Don't duplicate Email Response items as standalone Day's Priorities entries — the =Email Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the email body, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3c: Mark processed email as read @@ -352,20 +379,19 @@ For each Action item: 1. *Read* the message and surrounding thread context. 2. *Capture substantive content* in =deepsat/knowledge.org= (or the project's equivalent) for persistent project facts, or =.ai/session-context.org= for today's context. Same routing rules as Sub-step 3b — default to session-context when unsure. 3. *People-Context Check* — same as sub-step 3b's step 4. When the message involves a specific person, look them up in =knowledge.org= before drafting. Skip for transactional bot pings. -4. *Add to the prep doc* under Day's Priorities as a =Slack Response= sub-section: +4. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Reply / React / Address / Schedule), the source link as =[[slack-permalink][From X in #channel: brief description]]= form, and tags =:quick:reactive:[person]:=. The recommended-approach + recommended-response content goes in the task body. +5. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example - ** Slack Response - *** [[slack-permalink][From X in #channel: brief description]] - - One-line description of why action is needed. - - Suggested action: reply / react / move to thread / schedule. - <recommended approach + recommended response per the Recommended Approach Pattern above> + ** TODO [#B] Reply to <Person> re: <topic> — [[file:../todo.org::*Reply to <Person>][todo.org]] + <one line on why today — who's blocked, 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 sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry. +For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry or todo.org task. After processing all items, mark *only the specific DMs and @mentions we touched* as read in Slack — not channel-wide. The Slack MCP should expose a per-message mark-read capability; if the available MCP doesn't support it, skip this step and let Craig manage Slack read state himself. Do NOT mark channel chatter as read; only the items the query returned. -Don't duplicate Slack Response items as standalone Day's Priorities entries — the =Slack Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the message text, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3e: From Linear @@ -388,32 +414,29 @@ For each Action item: 1. *Read the ticket* — description, recent comments, state history. 2. *Capture substantive content* in =deepsat/knowledge.org= (people roles, system facts, strategic decisions) or =.ai/session-context.org= (today's review notes). Same routing rules as Sub-step 3b — default to session-context when unsure. 3. *People-Context Check* — same as sub-step 3b's step 4. When the ticket involves a specific person (assignee, reviewer, commenter, @mentioned), look them up in =knowledge.org= before drafting. Skip for bot updates and automated transitions. -4. *Add to the prep doc* under Day's Priorities as a =Linear Response= sub-section: - #+begin_example - ** Linear Response - *** [[https://linear.app/...][SE-NNN]] Ticket title (state, assignee) - - Why action needed: one-liner (e.g., "Vrezh moved to Needs Review, awaiting Craig"). - - Suggested action: review code / post comment / change state to X. - <recommended approach + recommended response per the Recommended Approach Pattern above> - #+end_example - - Linear's =recommended response= can be a draft comment, a proposed state change with rationale, or a combined action like "comment + reassign to Vrezh" — the response is "what Craig should do," not just reply text. +4. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Review / Comment / Resolve / Address), the source link as =[[https://linear.app/...][SE-NNN ticket title]]= form, and tags =:quick:reactive:[person]:=. The recommended approach + recommended response (draft comment, proposed state change, combined action like "comment + reassign to Vrezh" — "what Craig should do," not just reply text) goes in the task body. - *When the action item is a comment or @mention,* don't write "read X's comment." Fetch the comment via =mcp__linear__list_comments= and paste it inline as a child header so Craig can answer in the prep doc: + *When the action item is a comment or @mention,* paste the comment text into the task body so Craig can draft a reply against it. Fetch via =mcp__linear__list_comments=: #+begin_example - *** [[https://linear.app/...][SE-NNN]] Ticket title — <Author> @mentioned Craig in a comment - - Why action needed: direct @mention; ties to <related ticket if any>. - - Suggested action: answer inline below; I'll post the reply on the ticket. - **** <Author> — <YYYY-MM-DD HH:MM> — comment on SE-NNN + ** TODO [#B] Reply to <Author> on [[https://linear.app/...][SE-NNN]] :quick:reactive:[author]: + Why action needed: direct @mention; ties to <related ticket if any>. + + *** <Author> — <YYYY-MM-DD HH:MM> — comment on SE-NNN #+begin_quote <the comment text, verbatim> #+end_quote - ***** Craig's reply (fill in / approve, then I post it to the ticket) + *** Craig's reply (fill in / approve, then I post it to the ticket) <placeholder> #+end_example Same idea for an FYI comment Craig should see — paste it, don't just reference it. (Feedback memory: =feedback_linear_comment_as_child_header=.) +5. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: + #+begin_example + ** TODO [#B] Review SE-NNN <ticket title> — [[file:../todo.org::*Review SE-NNN][todo.org]] + <one line on why today — Needs Review, blocker, deadline> + #+end_example + Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. -For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry. +For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry or todo.org task. *Two deliberate divergences from email/Slack:* @@ -422,7 +445,7 @@ For each FYI item: read it, capture substantive content per the routing above, t *Volume note:* if a query returns >20 tickets, surface the count and prioritize Action signals first (Needs Review assigned to Craig, @mentions, blocked tickets, deadlines). -Don't duplicate Linear Response items as standalone Day's Priorities entries — the =Linear Response= sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the ticket description, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3f: From Open PRs @@ -444,17 +467,17 @@ For each Action item: 1. *Read the PR* — diff summary, recent commits, review state, any unresolved threads. 2. *People-Context Check* — same as sub-step 3b's step 4 for the PR author and the requesting reviewer. -3. *Add to the prep doc* under Day's Priorities as a `** PR Review` sub-section: +3. *Create the =:quick:reactive:= todo.org task* per the *Triage Action items become =:quick:reactive:= todo.org tasks* rule above. The heading carries the verb (Review / Re-review / Unblock), the source link as =[[PR-URL][PR #N title (author)]]= form, and tags =:quick:reactive:[author]:=. The recommended-approach + recommended-response content goes in the task body. +4. *If the item belongs in today's plan, link from Day's Priorities* using the thin-link form: #+begin_example -** PR Review -*** [[PR-URL][PR #N — title (author, branch)]] -- Why action needed: review requested / re-review after force-push / blocked on Craig's response. -- Suggested action: full review / quick re-review / unblock thread. -<recommended approach + recommended response per the Recommended Approach Pattern above> +** TODO [#B] Review PR #N <title> — [[file:../todo.org::*Review PR #N][todo.org]] +<one line on why today — review requested, blocking author, re-review after force-push> #+end_example -For FYI items: include a short *Craig's own PRs awaiting review (FYI, not action)* sub-list under the PR Review section so the queue stays visible without inflating the action surface. One line per PR: number, short title, who's been requested. +Items that don't belong in today's plan stay in =todo.org= and surface on a future day's prep via sub-step 3a's =:reactive:= pull. + +For FYI items (Craig's own PRs awaiting review, draft PRs in flight): don't create a todo.org task. Surface them in =* Heads-up= (Phase 7) as a one-line note ("Craig's open PRs awaiting review: #145, #167") so the queue stays visible without inflating the action surface. *Two deliberate divergences from email/Slack:* @@ -463,27 +486,27 @@ For FYI items: include a short *Craig's own PRs awaiting review (FYI, not action *Per-project repo configuration.* The repo path is project-specific. For projects without a primary repo (personal documentation projects, etc.), skip this sub-step and mark `prs ✗ (no primary repo)` in the audit footer. For projects with multiple repos in active development, scan each in turn; surface Action items with the repo name prefixed in the title. -Don't duplicate PR Review items as standalone Day's Priorities entries — the `PR Review` sub-section IS the priority surface for those items. +The =:quick:reactive:= todo.org task is the durable home; the Day's Priorities thin link surfaces it for the day. Don't paste the PR description, recommended approach, or response draft into the prep doc — those live in the todo.org task. *** Sub-step 3g: Cross-source dedup and urgency re-sort -After 3a-3f have written all their entries to Day's Priorities, do a final cleanup pass. +After 3a-3f have written all their =:quick:reactive:= todo.org tasks and Day's Priorities thin links, do a final cleanup pass. -*Cross-source dedup.* Scan the Email Response, Slack Response, Linear Response, and PR Review sub-sections for items that reference the same conversation or topic. Common cases: +*Cross-source dedup.* Scan the =:reactive:= tasks created this prep cycle for items that reference the same conversation or topic. Common cases: -- Vrezh DMs Craig about a Linear ticket *and* comments on the ticket itself — both surface as separate drafts +- Vrezh DMs Craig about a Linear ticket *and* comments on the ticket itself — both surface as separate =:reactive:= tasks - An email points at "let's discuss on the ticket" — the ticket also has activity - A Slack thread is the followup to an email exchange For each candidate duplicate pair, surface to Craig: #+begin_quote -These two items look like the same conversation: [Email link] and [Linear link]. Should I collapse them under one source, or keep both? +These two reactive tasks look like the same conversation: [task with Email link] and [task with Linear link]. Should I collapse them into one, or keep both? #+end_quote -Wait for Craig's call. If he says collapse, keep the source he picks and add a cross-reference link in the kept item ("see also: [other-link]"). Don't auto-collapse. +Wait for Craig's call. If he says collapse, keep the source he picks, paste the other source link into the task body as "see also: [other-link]", and drop the other task. Drop the matching Day's Priorities thin link too. Don't auto-collapse. -*Urgency re-sort.* Items currently appear in sub-step order (todo.org, then Email Response, then Slack Response, then Linear Response). Re-order all top-level entries under =* Day's Priorities= by urgency: +*Urgency re-sort.* Re-order all entries under =* Day's Priorities= by urgency: 1. Items with deadlines today or already overdue 2. Items where Craig is blocking someone (Slack blocked-on-Craig, Linear Blocked tickets, Needs-Review assigned to Craig) @@ -492,9 +515,7 @@ Wait for Craig's call. If he says collapse, keep the source he picks and add a c 5. Time-sensitive but lower-stakes items 6. Everything else -Within each tier, preserve the source-section structure (Email Response, Slack Response, Linear Response sub-sections stay grouped) — just re-order the top-level entries that aren't already sub-sectioned. - -Craig can re-order further when he reviews the prep doc; this just gives him a sane starting order. +Day's Priorities entries are all thin links to todo.org tasks now (no grouped source sub-sections), so re-ordering is a flat sort — just move the heading lines into urgency order. Craig can re-order further when he reviews the prep doc; this just gives him a sane starting order. *** Sub-step 3h: Phase 3 audit footer (forcing function) @@ -799,3 +820,6 @@ 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.) |