Synthesis Daily Rituals

Daily Rituals — Global Checklists

Standard day-start and day-end rituals for synthesis engineering projects. These are the global (per-person) checklists. Each project may have a project-specific supplement that extends these with channel-specific sync, repo-specific checks, and stakeholder-specific communications.

v2.10.0 — Cockpit Mode: Budget-Bound, Stakes-Routed Day Plans

In v2.10.0 (2026-06-12), the day plan gains an alternative canonical mode — Cockpit Mode — for users whose discretionary time is scarce and preemption-prone (heavy meeting load, frequent same-day scheduling). The classic mode (full prioritized task board) remains valid; Cockpit Mode is the recommended default when the user's open-item count persistently exceeds what their calendar can absorb. Design rationale and the originating six-week evidence base live with the user's working-system design doc; the durable protocol is here.

The three rules of Cockpit Mode:

1. Budget before backlog. The plan generation step reads the user's calendar FIRST, computes discretionary windows, and commits at most ~70% of them — the remainder is an explicit preemption buffer. The plan header states the arithmetic (Budget: windows … = N min. Committed: M min (≤70%). Buffer: N−M min). A plan that ignores the calendar is a wish list.

1. Stakes-routed outbound (the tier matrix). Every outbound communication is classified at creation:

• Tier A — agent sends, clearly agent-labeled (per the user's bot-labeling rule): routing/triage pings, scheduling requests, receipt acknowledgments, info relays with citations, follow-up nudges on delegated items. Sent within the work block; every send logged to a ## On your behalf section in the day plan (the TICKER). Tier A never expresses the user's opinions, makes commitments, or touches sensitive relationships. Requires the user's standing approval of the matrix before activation; until then, Tier A routes to Tier B.
• Tier B — one-tap queue: drafts in the user's voice (kudos, substantive replies) and decisions-with-recommendation, presented in batches of ≤5 with APPROVE / EDIT / SKIP affordances answerable in one line. Two review windows per day.
• Tier C — user-original: deep work and relationship-critical writing. Maximum 3 per plan, each assigned to a named calendar window.

Ambiguity routes to Tier B, never to Tier A.

1. Preemption is normal, not failure. When a same-day meeting lands on a committed window, the lowest-priority Tier-C item drops to the queue automatically — no re-planning ceremony. Dropped and expired items are caught by the synthesis-catchup-ledger ratchet (see that skill); decay rules apply at plan-generation time (stale kudos auto-expire to a consolidated-send; DECAYING items carry do-by dates; event-bound items expire at their event).

Plan format additions (cockpit-vocabulary compatible): a **Budget:** line in the header; one ## ⚡ Decision needed H2 when a decision is pending (max ONE per day where possible); ## 🎯 Today — N deep items (the Tier-C slots); ## ☑️ One-tap batch (Tier B, with a queued-overflow paragraph); ## On your behalf (Tier A log); ## 📰 Brief (readable in ≤90 seconds). Consumers (synthesis-console) treat On your behalf as a new lower-row collapsible until typed support ships.

Relationship to rituals: day-start still runs the full sync stack (Steps 1–5 unchanged) — Cockpit Mode changes only Step 6 (Day Plan) and Step 7 (Morning Messages: Tier A items send instead of queueing, once the matrix is approved). The user's ritual calendar blocks become review windows; briefs should be prepared BEFORE the block begins whenever the agent runs scheduled/continuous.

v2.9.0 — Temporal & State Verification as Day-Start Step 1; new synthesis-checkpoint dependency

In v2.9.0 (2026-05-27), the Day-Start ritual gains a new Step 1 — "Temporal & State Verification" — that runs BEFORE all other day-start steps. It anchors today's date from date, runs git log per active project to verify "last session," and reconciles cached last_session fields against git timestamps. Triggered by the 2026-05-27 inbox-cleanup mis-dated-session-log incident; codified to prevent recurrence in any synthesis project.

Step renumbering across the day-start: NEW Step 1 = Temporal & State Verification. Old Step 1 (Context Optimization) → Step 2. Old Step 2 (Sync) → Step 3, with sub-steps 3a/3b/3c. Old Step 3 (Catch-Up Read) → Step 4. Old Step 4 (PR Review Queue) → Step 5. Old Step 5 (Day Plan) → Step 6. Old Step 6 (Morning Messages) → Step 7. The Day-End checklist is unchanged in numbering; Day-End Step 7 (Context Capture) gains explicit push-confirmation language matching the new discipline.

New dependency: synthesis-checkpoint — a lightweight skill that codifies the date-verification + state-verification protocol. The day-start ritual delegates to synthesis-checkpoint for the per-project verification work in Step 1.

The discipline this enforces (cross-tool, codified in CLAUDE.md item 13c–13e and the synthesis-context-temporal-continuity project): treat session-log entry dates, "N days ago" claims, and CONTEXT.md fields as caches subject to drift. Verify against date and git log before quoting them into any output.

v2.8.0 — Weekly Loose-Ends Review on Fridays

In v2.8.0 (2026-05-22), the Day-End ritual gains a Friday-only "Weekly Loose-Ends Review" step that scans the prior two weeks of work for incomplete, missed, or forgotten items and consolidates the surviving ones into a carryover list for Monday's day-start.

Rule: on Fridays, before the Repo Guard final-verification step, scan the past 14 calendar days of daily plans + project context files + open commitment tables. For every surfaced item, classify it as STILL RELEVANT (carry into Monday), OBSOLETE (annotate-and-close in place), or AMBIGUOUS (surface to user). The output is a ## Weekly Loose-Ends Review section in Friday's daily plan plus a populated ## Carried Items section in Monday's plan.

Why: the workweek's cracks accumulate invisibly. A missed close-of-business ritual on Wednesday means Thursday's plan doesn't pick up Wednesday's open threads. By Friday, several items can be quietly stranded. Without an explicit weekly catch, the user's mental model of "what's open" drifts from reality — and the longer the drift, the harder the eventual reconciliation. Running this on Friday afternoon catches stale items WHILE context is still warm; Monday begins with a clean carryover instead of an archaeological dig.

Why Friday and not Monday: Monday is when the carryover gets ACTIONED. Friday is when the carryover gets ASSEMBLED. Assembling on Monday means starting the week with backwards-looking work; assembling on Friday means closing the week with a clean handoff to next week. The split also lets the user (or the agent) drop OBSOLETE items into context that's still fresh — Monday's view of "is this still relevant?" is fuzzier than Friday's.

Where in the day-end checklist: new Step 10, just before Repo Guard (which stays the terminal step). The skill detects day-of-week and skips silently on non-Fridays. See Day-End Checklist below.

Idempotent re-runs: if a Friday day-end ritual is missed and the agent runs the Weekly Loose-Ends Review on a later weekday (Saturday catch-up, Monday morning if Friday was skipped), it should still produce the same scan output — the scan is date-bounded, not weekday-bounded. The Friday-default is about WHEN it normally fires, not about whether the scan is meaningful on other days.

v2.7.0 — Source-Code Sync as a First-Class Ritual Step

In v2.7.0 (2026-05-21), source-code synchronization becomes an explicit, first-class step in both the day-start and day-end rituals — running BEFORE the daily plan is drafted (so any drafts that need to be grounded in code can read current source) and BEFORE end-of-day verification (so tomorrow's day-start begins from a clean, current state).

Rule: for every source-code repo associated with active work in the current workspace, fetch from all configured remotes and fast-forward the default branches (typically main and develop, plus any other long-running branches the team uses) BEFORE drafting the daily plan and BEFORE the end-of-day repo-guard verification. The skill stays generic — the list of repos per workspace is declared in the workspace CLAUDE.md (or equivalent project context file), not hardcoded.

Why:

• Drafts must be grounded in current code. The grounding protocol (see below) requires draft messages to be grounded in primary sources before sending. If local source is days behind origin, a draft that cites a function or PR may be quoting a stale version. Pulling first means the grounding research uses the current code.
• Avoid surprise conflicts at end-of-day. Running fetch + fast-forward at day-end (just before the repo-guard verification) surfaces upstream divergence early — the user doesn't discover at 6 PM that develop moved fifty commits and a feature branch needs rebasing.
• One step, not "I'll do it later." Folding it into the ritual makes it deterministic. The earlier git fetch --all checkbox in v2.6.0 and prior was easy to skip and only fetched (no fast-forward) — v2.7.0 makes the step substantive and visible.

What goes where:

• This skill defines the GENERIC pattern (fetch from all push remotes, fast-forward default branches, surface diverged or behind-state, report which repos were touched).
• The WORKSPACE-SPECIFIC list of repos lives in the workspace's CLAUDE.md (e.g., ~/workspaces//CLAUDE.md's "Workspace Repos" table). Each repo's specific multi-remote configuration is implicit from git remote -v inside that repo.
• The PROJECT-SPECIFIC supplement may add per-project considerations (e.g., "after fetch, check whether feature/X is stale and needs rebase"). See "How to Create a Project Supplement" near the end of this file.

Sequence within day-start: Context Optimization (Step 1) → Source-code sync (Step 2a — NEW) → Slack sync (Step 2b — was Step 2) → Meeting transcripts (Step 2c — was Step 2b) → Catch-up read (Step 3) → PR review queue (Step 4) → Day plan (Step 5) → Morning messages (Step 6).

Sequence within day-end (v2.8.0+): Transcript sync (Step 1) → Source-code sync (Step 2 — v2.7.0) → Integration sweep (Step 3) → … → Weekly Loose-Ends Review (Step 10 — v2.8.0, Fridays only) → Repo guard final verification (Step 11 — was Step 10 in v2.7.0).

v2.6.0 — Draft Numbering Convention (numbers, not letters)

In v2.6.0 (2026-04-29 very late evening), the convention for labeling drafts in a daily plan is fixed to sequential integers (Draft 1, Draft 2, Draft 3, …) rather than alphabet letters (Draft A, Draft B, …).

Rule: the first draft of the day is Draft 1. Each subsequent draft increments by 1. No letter labels. No K-2 / K-3 sub-versioning — if a single piece of work produces multiple draft messages (e.g., the same praise routed to two audience-specific channels), each one gets its own integer (Draft 11, Draft 12, Draft 13). The chronological count of drafts in the plan equals the highest integer in use, which makes it easy to answer "how many drafts today?" by reading a single label.

Why: numbers are easier to count at a glance, have no 26-item ceiling, and don't impose a mental "is K the 11th letter?" tax. The K-2 / K-3 sub-versioning that letter-labels invite is uglier than 11 / 12 / 13 and creates label-shape inconsistency in the file. Letter labels also make it harder to grep for "all drafts from #N onward" because alphabet ordering is lexicographic, not arithmetic.

Retraction handling: if a draft is retracted (caught fabrication, sent-then-deleted, etc.), reserve the number with a brief marker — e.g., ### Draft 8 — retracted plus a one-line note pointing to the session log — rather than renumbering subsequent drafts. Renumbering after a retraction creates label-drift across the file and any cross-references in chat. The reserved number is the durable record that the slot existed.

Cross-file consistency: when renumbering a daily plan that's already been referenced from CONTEXT.md or session logs (those use the labels in effect at the time), update only the daily plan and add a brief note acknowledging the cross-reference gap. Historical narrative in session logs preserves the labels in use at the time — that's the right behavior, not a bug.

Pre-draft check: when adding a new draft to a daily plan, the first thing the agent does is scan the file for the highest existing Draft N integer and use N+1. No alphabet thinking.

v2.5.0 — Draft Fence Convention (nested code blocks)

In v2.5.0 (2026-04-29), the canonical fence convention for draft message bodies is documented to handle the case where a draft contains its own triple-backtick code blocks (install commands, code samples, log excerpts).

Rule:

• Default fence for a draft body is 3 backticks ( ` ). Use this when the message body contains no triple-backtick code blocks.
• If the draft body contains ANY internal triple-backtick blocks, the outer fence must be at least one backtick longer than the longest internal fence. In practice this means 4-backtick outer fence ( `` ) when the message contains 3-backtick blocks.

Why: CommonMark closes a fenced code block at the first fence of equal-or-greater length. A 3-backtick outer wrapper is closed by the first 3-backtick inner fence — splitting the draft into multiple disjoint blocks and breaking the synthesis-console renderer (which attaches its action bar to the first fenced block after **Send to:**). A 4-backtick outer wrapper survives 3-backtick inner blocks unchanged; the inner fences become literal content of the outer fence, which is exactly what we want for a draft body containing install snippets or code samples.

Pasting into Slack: when the user clicks Copy in synthesis-console, the action reads .innerText from the rendered ` block — outer fence delimiters are stripped, inner `` markers are preserved as literal text. Slack then re-interprets the inner ` as Slack code blocks. End-to-end behavior is correct.

Cross-reference:

• Consumer-side handling lives in synthesis-console docs/cockpit-design.md "Drafts" section (the consumer is being updated to handle multi-segment drafts robustly via augmentDraftBlocks, but the producer-side convention here is independently correct and should be applied regardless).
• Lesson backing this rule: lessons/2026-04-29-document-as-contract-with-llm-producers.md.

v2.4.0 — Canonical Plan Format Contract

In v2.4.0 (2026-04-29), the daily plan file format became a versioned contract between this skill (the producer) and synthesis-console v0.8+ (the consumer that renders plans as a cockpit dashboard).

The contract is defined by the canonical H2 vocabulary below. The console's parser is tolerant of synonyms and emoji prefixes, but agentic skills (LLMs) must prefer the canonical names where possible because:

• Canonical names are unambiguously typed by the console (NEEDS YOU / TODAY / DRAFTS / lower-row collapsibles)
• Synonyms are accepted via substring + case-insensitive match, but each new variant adds parser maintenance burden
• Non-canonical names fall through to "other" and render as plain markdown — visible but not specially typed

When the LLM driving this skill decides to deviate from the template, it MUST stay within the recognized vocabulary table (next section). New section types should be proposed as additions to this contract, not invented ad-hoc.

The producer-consumer contract is documented in two places:

• This file's "Canonical Plan Format" section below (authoritative for skill writers).
• synthesis-console/docs/cockpit-design.md (authoritative for parser implementers).

These two files must stay in sync. When

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: synthesisengineering
• Source: synthesisengineering/synthesis-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.