diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-16 01:25:54 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-16 01:25:54 -0500 |
| commit | 8209c5f264c76cba052f4f9710fb86ed56f19903 (patch) | |
| tree | 8aa478d15023624bc6e7b0412c763f29963447df | |
| parent | c67b9aaed47f054b269c0244193e1189e022b939 (diff) | |
| download | rulesets-8209c5f264c76cba052f4f9710fb86ed56f19903.tar.gz rulesets-8209c5f264c76cba052f4f9710fb86ed56f19903.zip | |
docs(workflows): route triage Action items to todo.org as :quick: tasks
Every Action item surfaced by Phase 3 sub-steps 3b/3d/3e/3f (email, Slack, Linear, PR Review) now becomes its own ** TODO in todo.org with :quick: + :reactive: tags plus sharp person/entity tags. The prep doc's * Day's Priorities section references each task as a thin link when it belongs in today's plan; otherwise the task stays in todo.org and surfaces on a later prep via the new sub-step 3a step 4 pull.
The grouped ** Email Response / ** Slack Response / ** Linear Response / ** PR Review sub-headings disappear from the prep doc. Source mix lives in the tags on each task. The Recommended Approach Pattern still applies. The analysis and draft response live in the task body, not in the prep doc.
Mirrors the convention adopted in the work-side triage-intake workflow on 2026-05-15. Closes the 2026-05-12 follow-up about rewording sub-steps 3b–3f.
| -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.) |
