aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-05-13 15:09:35 -0500
committerCraig Jennings <c@cjennings.net>2026-05-13 15:09:35 -0500
commit27bd06aba562bd692582bf0ddc12cc9cd5f08d13 (patch)
tree8001a069758ebbf79c089f4c7e1704decb0fb62c
parent0e1036f791bf5c597996a2f12b546619ab831c0c (diff)
downloadrulesets-27bd06aba562bd692582bf0ddc12cc9cd5f08d13.tar.gz
rulesets-27bd06aba562bd692582bf0ddc12cc9cd5f08d13.zip
feat(workflows): thin-link Day's Priorities + auto-sync after triage
In daily-prep, Day's Priorities entries are now thin links to todo.org tasks rather than copies of their content. The substance — descriptions, drafts, research, sub-tasks, STALLED asks, recommended-approach blocks — lives in the matching todo.org task that Phase 3 creates or updates. Completed-today entries still convert to dated log headings as the day's record. Phase 3's Linear action-item step also gets a comment-as-child-header pattern: paste the @mention or comment inline rather than referencing it, so the reply can be drafted in the prep doc. In triage-intake, mbsync -a now runs at the end of every triage by default — no more "ask before syncing" — and a Synced line in the summary records the run.
-rw-r--r--.ai/workflows/daily-prep.org34
-rw-r--r--.ai/workflows/triage-intake.org5
2 files changed, 37 insertions, 2 deletions
diff --git a/.ai/workflows/daily-prep.org b/.ai/workflows/daily-prep.org
index 68e6eb9..e739847 100644
--- a/.ai/workflows/daily-prep.org
+++ b/.ai/workflows/daily-prep.org
@@ -89,6 +89,23 @@ Canonical sections (full-prep mode produces all; standup-only produces just =* S
Order in the prep doc follows the table top-to-bottom: Heads-up first (frame-setter), Day's Priorities next (action surface), then schedule, then standup, then deadlines, then forward-commitment.
+** Day's Priorities entries are thin links to todo.org tasks (2026-05-12 rule)
+
+Each actionable entry under =* Day's Priorities= is a *pointer to a todo.org task*, not a copy of its content. Form:
+
+#+begin_example
+** TODO [#X] <task title> — [[file:../todo.org::*<task title>][todo.org]]
+<one line on why it's today's priority — deadline, blocker, what just landed>
+#+end_example
+
+All the substance — descriptions, drafted messages, research findings, sub-tasks, =STALLED= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.
+
+Exceptions that stay in the prep doc as content (not links):
+- *Completed-today entries* — once a task is done, its heading becomes a dated log entry (=** YYYY-MM-DD Day @ HH:MM ...=, see [[file:../../.claude/...][feedback_done_tasks_become_dated_log_headings]] — i.e. the dated-heading rule) and stays in the prep doc as the day's record. If the work also has a durable todo.org home, the dated entry links to it.
+- The =* Standup Briefs=, =* Heads-up=, =* Upcoming Deadlines=, and =* [Next day]'s Anchor Tasks= sections — those are prep-doc-native and don't map to todo.org tasks.
+
+(Craig's instruction, 2026-05-12. 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.)
+
* Approach: How We Work Together
** Continuous flow (no mid-phase gates)
@@ -382,6 +399,20 @@ For each Action item:
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.
+ *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:
+ #+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
+ #+begin_quote
+ <the comment text, verbatim>
+ #+end_quote
+ ***** 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=.)
+
For each FYI item: read it, capture substantive content per the routing above, then drop. No prep-doc entry.
*Two deliberate divergences from email/Slack:*
@@ -765,3 +796,6 @@ or plans. Exclude work whose output lives entirely in Craig's local files (knowl
todo.org, session notes, transcript processing, local tooling setup, MCP server config).
Filter: "If I didn't mention this, would someone on the team make a worse decision or
duplicate the work?" If no, cut it.
+
+*** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks — never duplicated content
+Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, STALLED 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.)
diff --git a/.ai/workflows/triage-intake.org b/.ai/workflows/triage-intake.org
index a0657b5..36f9530 100644
--- a/.ai/workflows/triage-intake.org
+++ b/.ai/workflows/triage-intake.org
@@ -89,7 +89,7 @@ All three mail accounts are synced to local Maildirs and =mu=-indexed: =~/.mail/
<path-1> <path-2> ...
#+end_src
*Always pass explicit paths.* Never call =mark-read= with no positional args — the bare default is "mark every unread message across every configured INBOX maildir on the machine," which happens to be the same set here but becomes a footgun the moment a project's extension narrows the scope. =--reindex= re-runs =mu index= so the local index reflects the new flags. =--dry-run= previews without modifying.
-3. Flag changes land on disk; =mbsync= propagates them to the servers on its next run. If the user wants the servers updated immediately, run =mbsync -a= after — but don't auto-sync; ask first (matches =summarize-emails.org='s "ask before syncing").
+3. Flag changes land on disk. *Always run =mbsync -a= at the end of a triage-intake* so the read flags propagate to the servers before the workflow closes — don't leave them queued for the next sync, and don't ask first (Craig's standing instruction, 2026-05-12). The "conflicting changes (N,M)" notices mbsync prints when both sides touched flags are normal — it resolves them. (This overrides the older "ask before syncing" posture inherited from =summarize-emails.org=.)
4. Trash obvious junk separately and *only with user approval* — never trash without an explicit go-ahead.
*** Slack — every conversation surfaced
@@ -107,7 +107,8 @@ One concise summary back to the user:
- *What moved (by source)* — one line per change worth knowing.
- *Actionable* — numbered, with the proposed next step per item.
- *Cleared* — total count of emails (across the three accounts) and Slack conversations marked read.
-- *Pending decisions* — anything needing user input before action (draft replies awaiting approval, ambiguous routing, =mbsync= sync offer, etc.).
+- *Pending decisions* — anything needing user input before action (draft replies awaiting approval, ambiguous routing, etc.).
+- *Synced* — confirm =mbsync -a= ran and note any non-trivial output.
* Principles