DAILY_SYNC.md

Daily Sync

You are the orchestrator for Adrian's end-of-day sync. Your job is to coordinate sub-agents that collect data from different sources, then synthesise into the Knowledge Base, run structural maintenance to keep files from growing forever, and finish with a staleness sweep.

This is an automated, unattended process. It runs on a scheduled job on Adrian's Mac with no human in the loop. You must not pause to ask questions, request confirmation, or wait for input — make reasonable judgment calls and proceed. At the end of the run, you must commit all changes to git so the work is captured in version history.

Today's date is {{DATE}}.

The working directory is 00 Work Notes/Butternut/ inside the Obsidian vault. All paths below are relative to that.

---

Knowledge Base Conventions

Read these before writing anything in Step 3 onwards. They define where content goes and how files are kept lean over time.

Project structure — folder per project

Every project lives at 00 Knowledge Base/projects/<project-slug>/ with _index.md as the entry point. Single file by default; expand into siblings as the project grows.

projects/
├── ai-gateway/
│   └── _index.md                    # single-file project — most live here
├── pause-save-flow/
│   └── _index.md
├── fin/                             # multi-file program
│   ├── _index.md                    # overview, current focus, related projects, program-level decisions/milestones, links
│   ├── procedures/                  # workstream files clustered by category
│   │   ├── change-portion-sizes.md
│   │   ├── refunds.md
│   │   └── ...
│   ├── connector-architecture.md    # cross-cutting workstream as a sibling
│   ├── guidance-system.md
│   └── archive/2026/                # closed workstreams, year-keyed by closure date
│       ├── superqa-integration.md
│       └── phone-channel-strategy.md

Promotion rules:

• A new project starts as <project>/_index.md. Nothing else.
• When _index.md crosses ~250 lines OR contains 3+ distinct ### workstream sections, split each ### workstream into its own sibling file. _index.md keeps the program overview, current focus, program-level decisions/milestones, and a one-line summary + wikilink per workstream.
• Optionally cluster related workstreams into a sub-folder (e.g. procedures/ for a service program). Don't sub-folder for the sake of it — only when the cluster has 3+ peers.
• A workstream file passes ~250 lines → split by sub-topic, or rotate older content into <file>.history.md alongside.
• A workstream is closed when all its TODOs are checked, there's been no activity for 30+ days, and there's no open question or active discussion. Move to <project>/archive/YYYY/<name>.md with frontmatter closed: YYYY-MM-DD (year keyed by closure date, not start date).

Wikilink form:

• Project page: [[<project>/_index|<project>]]
• Workstream file: [[<workstream-slug>]] (workstream filenames are unique enough to resolve without path)
• Archived workstream: [[<workstream-slug>]] (still resolves)

Learnings structure — durable domain knowledge only

learnings/ is for durable knowledge: how a system works, what the rules are, what we've learned about a domain. If it reads like "what we're doing about X right now," it belongs under projects/, not here.

learnings/
├── fin/
│   ├── connector-patterns.md
│   └── replacement-discount-rules.md
├── architecture/                    # system architecture writeups
│   ├── ai-gateway.md
│   └── pause-save-flow.md
├── data/
│   └── snowflake-segment-pipeline.md
└── datadog/
    └── observability.md

Rules:

• Topic-grouped sub-folders. Filenames drop the redundant prefix once they're inside a folder (fin-connector-patterns.md → fin/connector-patterns.md).
• Create a new top-level topic folder when a body of durable knowledge clearly clusters around a non-existing topic. Don't create speculative folders.
• Same ~250-line cap as projects. Split a fat learning by sub-topic.
• Boundary check when writing: if you're tempted to add an item that's a current TODO, an active blocker, or a "next week we'll..." note — that's project state, route it to projects/.

People

Each person gets their own file at 00 Knowledge Base/people/<lowercase-kebab-case>.md. Compact references for who owns what, what they've said, and when.

---

Step 1 — Launch data collection agents (parallel)

Use the Agent tool to launch these three sub-agents in parallel (all in a single message). Each agent writes its output to disk — you do not need their results in context.

Meeting Curator Agent

Prompt: Read the Meeting Curator agent definition at `02 Meetings/MEETING_CURATOR_AGENT.md` and follow its Processing Workflow (Steps 0-8) exactly.

This is an unattended automated run — do not ask questions or wait for confirmation. Make reasonable judgment calls and proceed.

Today's date is {{DATE}}.
Working directory: 00 Work Notes/Butternut/

Source: `02 Meetings/00 raw/` (any .md files other than README.md).

If there are no files to process, report that and stop.
If there are files, process them fully: determine destinations, load context, synthesise fingerprints, assign themes, update people files, file the notes, update Wiki.md, and report back.

Slack Digest Agent

Prompt: Read the Slack Digest Agent definition at `03 Slack/SLACK_AGENT.md` and follow its Sweep Workflow (Steps 0-5) exactly.

This is an unattended automated run — do not ask questions or wait for confirmation. Make reasonable judgment calls and proceed.

Today's date is {{DATE}}.
Working directory: 00 Work Notes/Butternut/

Config: `03 Slack/slack_config.md`
Output: `03 Slack/YYYY/MonthName/DD-MM-YY.md`

Sweep all configured channels and auto-discover DMs for today's messages. Extract decisions, action items, context shifts, and notable exchanges. Write the digest.

If no channels or DMs had activity today, report that and stop.

GitHub Digest Agent

Prompt: Read the GitHub Digest Agent definition at `04 Github/GITHUB_AGENT.md` and follow its Sweep Workflow (Steps 0-4) exactly.

This is an unattended automated run — do not ask questions or wait for confirmation. Make reasonable judgment calls and proceed.

Today's date is {{DATE}}.
Working directory: 00 Work Notes/Butternut/

Config: `04 Github/github_config.md`
Output: `04 Github/YYYY/MonthName/DD-MM-YY.md`

Query all configured repos for PR activity from tracked authors — PRs opened or merged today, and any new comments posted today on open PRs by tracked authors. Write the digest.

If no tracked authors had PR activity today, report that and stop.

Wait for all three agents to complete before proceeding.

---

Step 1.5 — Refresh QMD index and embeddings

After the collection agents write today's new files, refresh QMD so downstream retrieval (Steps 2–3) sees current data.

Run from repo root:

# Use the same QMD binary/index that Codex MCP reads (`index` by default)
# Re-index: picks up newly created/changed markdown files
/opt/homebrew/bin/qmd --index index update

# Generate vectors for any newly indexed content (incremental by default)
/opt/homebrew/bin/qmd --index index embed

# Confirm index health and document counts
/opt/homebrew/bin/qmd --index index status

If this step fails, continue using direct file reads for deterministic sources and report the failure in the Final Report.

---

Step 2 — Compile Daily Note

Once all data collection agents have finished, synthesise a Daily Note that describes how the day went, organised by topic — not by source.

Output path: 00 Knowledge Base/daily notes/YYYY/MM/DD-MM-YY.md

Create the daily notes/ directory (and year/month subdirectories) if they don't exist.

Sources to read

Read all available sources for today's date ({{DATE}}):

1. Scratchpad — 01 Scratchpads/YYYY/MonthName/DD-MM-YY.md
2. Meeting notes — any files in 02 Meetings/YYYY/MonthName/notes/ with today's date prefix
3. Slack digest — 03 Slack/YYYY/MonthName/DD-MM-YY.md
4. GitHub digest — 04 Github/YYYY/MonthName/DD-MM-YY.md

For any additional cross-day/context lookups while drafting the daily note, use QMD MCP (query → get/multi_get) before ad hoc grep scans.

How to structure it

Identify the topics and themes that appeared across the day's sources. Group related information together under topic headings, regardless of which source it came from. If a topic appears in multiple sources (e.g. Intercom discussed in both a meeting and Slack), merge them into a single section.

Within each topic section, link back to the original sources so Adrian can drill into detail:

• Meeting notes: [[YYYY-MM-DD Meeting Title]]
• Slack digest: [[DD-MM-YY Slack|Slack digest]]
• GitHub digest: [[DD-MM-YY GitHub|GitHub digest]]
• Scratchpad: [[DD-MM-YY|Scratchpad]]

Write in a concise narrative style — not a copy-paste of each source, but a coherent account of what happened and what matters. Include key decisions, action items, and context shifts.

Format

---
date: {{DATE}}
sources: [list of sources that had content today]
---

# Daily Note — {{DATE}}

## <Topic 1>

<Narrative covering what happened with this topic today, drawing from all relevant sources. Link to original sources inline.>

## <Topic 2>

...

## Action Items

- <Action item> — owner (source: [[link]])
- ...

If only one source exists for the day and it covers a single topic, the note can be short — don't pad it out. If no sources exist at all, skip this step entirely and note it in the Final Report.

---

Step 3 — Knowledge Base Synthesis

Do this yourself — do NOT delegate to a sub-agent. You need the full picture in context.

Step 3.0 — Determine scope

Process today ({{DATE}}). If today has no scratchpad and no other sources, check for any unprocessed days since Last synthesized in 00 Knowledge Base/Wiki.md and process them in chronological order so that TODOs marked complete on later days are correctly resolved.

Step 3.1 — Load context

Before processing any content:

1. 00 Knowledge Base/Wiki.md
2. All 00 Knowledge Base/projects/*/_index.md files
3. Skim filenames in each project's sub-folders (read individual workstream files only when a project is touched)
4. All files in 00 Knowledge Base/people/
5. Skim filenames under 00 Knowledge Base/learnings/**/ (read individual files only when relevant content is found)
6. 02 Meetings/YYYY/Wiki.md — for open loops and recurring threads

For broader cross-day or topical lookups, use QMD MCP (query then get/multi_get) as the default retrieval path.

Step 3.2 — Process each day chronologically

For each day in scope, read the scratchpad, any meeting notes (notes/), the Slack digest (03 Slack/), and the GitHub digest (04 Github/). Then route content:

Projects

For each piece of content that relates to a known project:

• Find the right file. If the project is split into workstreams (Fin, anything else with sub-files), write to the specific workstream file — not the _index.md. Use _index.md only for program-level overview, current focus, cross-cutting decisions/milestones, and links.
• Update the workstream's TODOs / Decisions / Milestones with date and source backlink.
• Record decisions: **YYYY-MM-DD** — what was decided ([[source-date]]).
• Record milestones (PR merged = milestone, demo given = milestone, decision implemented = milestone).
• Update Current Focus in the project's _index.md if today's work was project-defining. Always end with *(as of YYYY-MM-DD)*.
• Add new links (PRs, Jira tickets, Notion docs, Intercom conversations) in the appropriate file.

If content relates to a project that doesn't have a folder yet, create projects/<slug>/_index.md using the template in the appendix.

TODOs

• Extract any TODO items, action items, or "need to do" statements
• Add them to the relevant project file as - [ ] item ([[source-date]])
• If notes indicate completion (e.g. "done", "submitted", "merged", "finished"), mark - [x] item ([[source-date]]) with a completion note
• Infer completion where reasonable — e.g. if a TODO says "submit tracking PR" and a later entry says "tracking PR merged", mark it done

People

• When someone says something notable, makes a decision, gives direction, or is assigned an action — update their file in people/. Use lowercase kebab-case filenames.
• Create a new file when someone first appears with notable content. Don't create files for passing mentions.
• Record what they said, when, and link to the source.
• Track role changes, responsibility shifts, ownership changes.

Learnings

• Domain knowledge (business rules, process descriptions, how systems work)
• Systemic patterns (not individual bugs — patterns that reveal something about the system)
• Process insights (how things actually work vs. how they're supposed to)

Route to the appropriate learnings/<topic>/ sub-folder. If the topic doesn't have a sub-folder yet but seems durable enough to warrant one, create the sub-folder.

Boundary check before writing: if what you're about to add is current TODO state, an active blocker, or a "next week we'll..." note — that's project state. Route it to projects/, not learnings/.

Content that doesn't fit

Some scratchpad content won't fit neatly — bare links, saved code snippets, draft messages, one-liner thoughts. Skip these. They remain searchable in the raw scratchpads via QMD.

Step 3.3 — Update Wiki.md

Wiki.md is a dashboard, not a log. Keep it lean — duplication of daily notes belongs in daily notes/, not here.

1. Update Where we are: a rolling 2-week TL;DR. Two short paragraphs:

   • Focus — what's dominated work in the last 2 weeks, with key PR numbers, decisions, and direction. Reads like a state-of-the-world summary.
   • People — who's active, who's blocking, who joined/left, who's reviewing what, who's OOO.

   Rewrite from scratch each run based on the last 14 daily notes — don't append. Keep brief (~200-250 words combined).

2. Update Active Projects: current focus per project, any new projects added.

3. Update Open TODOs: pull the most important open TODOs across all projects (~10-15 max, not exhaustive). Use wikilinks of the form [[<project>/_index|<project>]] or — when known — the specific workstream file [[<workstream-slug>]].

4. Update Recent Days: prepend today as - [[DD-MM-YY|Month DD]] — <one-line summary>. Derive the summary from today's daily note (key topics from headers, or the lead paragraph). Cap at 14 entries — drop the oldest if the cap is exceeded. The Wiki's job here is navigation, not retelling — the daily note holds the detail.

5. Add any new learnings pages to the Learnings section, grouped by sub-folder.

6. Update Last synthesized to {{DATE}}.

---

Step 4 — Commit 1: Additive sync

Stage and commit everything additive produced so far:

• Meeting notes filed by the Meeting Curator (02 Meetings/)
• Slack digest (03 Slack/), GitHub digest (04 Github/)
• Daily note (Step 2 — 00 Knowledge Base/daily notes/)
• Knowledge Base updates from synthesis (Step 3) — projects/, people/, learnings/, Wiki.md

Use git add with specific paths — do not use git add -A or git add . to avoid accidentally staging unrelated files.

Commit message: Daily sync (additive) — {{DATE}}

Do NOT push to a remote. The commit stays local.

If the commit fails, note the error in the Final Report and skip Steps 5 and 6 entirely. Don't run cleanup with uncommitted additive changes — that mixes the diffs and defeats the two-commit review pattern.

---

Step 5 — Cleanup

Now run destructive maintenance. This is what keeps projects/ lean over time. Each action below operates only on projects/ — do not touch learnings/, people/, daily notes/, or anything outside projects/.

Track every action for the Final Report so Adrian can scan the cleanup commit's diff against a known list.

5a. Promote oversize _index.md to multi-file

For each projects/*/_index.md:

• Count lines. If >250 OR if the file contains 3+ ### workstream sections, split:
  1. Identify each ### workstream section.
  2. Create a sibling file projects/<project>/<workstream-slug>.md (or under a sub-folder if it's part of an obvious cluster of 3+) containing that section's content.
  3. In _index.md, replace each split section with one line: - **[[<workstream-slug>|Title]]** — one-line summary.
  4. Distribute any program-wide "Key Decisions" or "Milestones" block: workstream-scoped entries move to the relevant workstream file; program-level entries stay in _index.md.

5b. Split oversize workstream files

For each non-_index.md file under a project folder:

• If >250 lines, split by sub-topic OR rotate older content into <file>.history.md alongside.

5c. Delete completed TODOs older than 30 days

For each file under projects/ (excluding archive/):

• Find every - [x] checked TODO line.
• Determine the line's age from the latest date in the line (source backlink ([[DD-MM-YY]]) or completion note like — done 2026-04-15). If no date is parsable, fall back to git blame -L <line>,<line> <file> to read the commit date of the line.
• Delete lines older than 30 days. Git log preserves them.

Keep files focused on what's still in motion. The completed history lives in git, not in the file.

5d. Delete open TODOs older than 60 days with no activity

For each file under projects/ (excluding archive/):

• Find every - [ ] open TODO line.
• Determine the line's age from the source backlink in parentheses (e.g. ([[DD-MM-YY]])); if no parsable backlink, fall back to git blame -L <line>,<line> <file> for the commit date of the line.
• "No activity" means the line text itself hasn't changed since it was created — git log -L <line>,<line>:<file> shows only the original commit. (If the line has been edited, that's activity — leave it alone, it counts as fresh.)
• Delete lines older than 60 days with no activity. Git log preserves them.

Prolonged silence on an open TODO means it isn't important enough to act on; surfacing it again is busywork. If it really mattered, git revert HEAD brings it back.

5e. Archive closed workstreams

(After 5c and 5d have cleared dead TODOs.) For each workstream file: if all TODOs are checked, no activity in 30+ days, and no open question — move to <project>/archive/YYYY/<workstream-slug>.md. Add frontmatter closed: YYYY-MM-DD using the latest activity date. Update wikilinks in the project's _index.md to point at the new archive location.

5f. Refresh stale Current Focus stamps

For each projects/*/_index.md with a ## Current Focus section ending in *(as of YYYY-MM-DD)*:

• If the as-of date is >14 days old:
  • If the project has newer activity (later TODO/decision/milestone dates inside any of its files, or commits to the project folder since the as-of date): rewrite Current Focus to reflect the recent activity and stamp *(as of {{DATE}})*.
  • If no newer activity: replace the date stamp with *(no recent activity since YYYY-MM-DD)*. Leave the body of the focus alone — don't delete signal that may still be accurate.

5g. Drop orphan empty sections

After 5c–5f, scan project files for empty section headers (e.g. ## TODOs or ## Decisions followed by nothing before the next header) and remove them, plus any resulting consecutive blank lines.

Reporting

Track every cleanup action for the Final Report:

• 5a: which _index.md files were split, and which new files were created
• 5b: which workstream files were split or rotated
• 5c: how many completed TODOs were deleted, broken down by file
• 5d: how many open TODOs were deleted, broken down by file
• 5e: which workstreams were archived
• 5f: which _index.md files had focus refreshed (rewritten vs. marked dormant)
• 5g: which orphan sections were dropped

If a sub-step did nothing: report "No changes" for that sub-step.

---

Step 6 — Commit 2: Cleanup

Stage and commit all the destructive changes from Step 5:

• File splits, archives, deletions, header drops
• Wikilink rewrites in _index.md after splits/archives
• Current Focus refreshes

Use git add with specific paths — same rules as Step 4.

Commit message: Daily sync (cleanup) — {{DATE}}

Do NOT push.

If Step 5 produced no changes, skip the commit entirely — don't create empty commits. Report "no cleanup needed" in the Final Report.

If anything looks wrong on review, Adrian can git revert HEAD to undo just the cleanup commit; the additive sync (Step 4) is unaffected.

---

Step 7 — Final Report

After all steps, give a combined summary in two parts that mirror the two commits.

Sync (commit 1 — additive):

• Meetings processed: count and names (or "none in raw")
• Slack digest: channels/DMs swept, key highlights (or "no activity")
• GitHub digest: repos swept, PRs merged/opened by tracked authors, new comments on open PRs (or "no activity")
• Daily note: path and which sources it included (or "no sources for today")
• Scratchpad days processed: which dates
• Project pages updated/created: list (use <project>/_index or <project>/<workstream> form)
• TODOs added/completed: highlights
• Themes updated: list
• Learnings extracted: list
• QMD maintenance: whether Step 1.5 update/embed succeeded, and any issues

Cleanup (commit 2 — destructive):

• Files split (5a): which _index.md files were promoted to multi-file
• Workstream files split (5b): which workstream files were split or rotated
• Completed TODOs deleted (5c): count, broken down by project
• Open TODOs deleted (5d): count, broken down by project — list each TODO's text so the diff is easy to scan
• Workstreams archived (5e): which workstream files moved to archive/
• Focus refreshed (5f): which _index.md files had Current Focus rewritten or marked dormant
• Orphan sections dropped (5g): which files

Commit status: whether Commit 1 and Commit 2 both succeeded; if either failed, the error.

Judgment calls: anything worth flagging

---

Templates

Project _index.md (single-file project — most projects)

# Project Name

## Overview

What this is and why it matters. 2-3 sentences.

## Current Focus

What's actively being worked on right now. Updated each synthesis run. Always ends with `*(as of YYYY-MM-DD)*`.

## TODOs

- [ ] Open item ([[source-date]])
- [x] Completed item ([[source-date]]) — completion note

## Decisions

- **YYYY-MM-DD** — Decision description ([[source-date]])

## Milestones

- **YYYY-MM-DD** — Milestone description

## Links

PRs, Jira tickets, Notion docs, repos, dashboards.

Project _index.md (multi-file program — after promotion)

# Program Name

## Overview

What this program is. 2-3 sentences.

## Current Focus

What's actively dominating attention. `*(as of YYYY-MM-DD)*`.

## Workstreams

- **[[workstream-slug-1|Title]]** — one-line summary
- **[[workstream-slug-2|Title]]** — one-line summary

## Related projects

- **[[other-project/_index|Other Project]]** — how it relates to this program (if applicable)

## Program-level decisions

Cross-cutting decisions that don't belong to a single workstream.

- **YYYY-MM-DD** — Decision ([[source-date]])

## Program-level milestones

- **YYYY-MM-DD** — Milestone

## Links

Program-wide PRs, docs, dashboards.

Workstream file

# Workstream Title

[1-2 sentence description of what this workstream covers.]

## TODOs

- [ ] Open item ([[source-date]])
- [x] Completed item ([[source-date]]) — completion note

## Decisions

- **YYYY-MM-DD** — Decision ([[source-date]])

## Milestones

- **YYYY-MM-DD** — Milestone

## Links

- [PR #X](url)

Archived workstream

---
closed: YYYY-MM-DD
---

# Workstream Title

Closed workstream. [Brief summary of what it was and why it closed.]

## TODOs

- [x] All previously-open items, now completed ([[source-date]])

## Decisions

- **YYYY-MM-DD** — ...

## Links

...

Person file

# Person Name

**Role:** Their role / relationship to Adrian
**Owns:** What they're responsible for

## Notable

- **YYYY-MM-DD** — What they said or decided, with context ([[source]])

## Open items

- Item description

Learning file

# Learning Title

## Summary

2-3 sentence overview of what this knowledge covers.

## Details

The actual knowledge, organised logically. Use sub-headings for sub-topics. Each fact or rule should have a source backlink: `([[source-date]])` or `([[Meeting Name]])`.

## Sources

- [[source-1]] — what it contributed
- [[source-2]] — what it contributed

---

Guardrails

• Never modify scratchpads, meeting transcripts, Slack digests, or GitHub digests. They are the raw record.
• Use Obsidian wikilinks for all internal links. Project links use [[<project>/_index|<project>]]; workstream links use [[<workstream-slug>]].
• Backlink to sources. Every fact, decision, TODO, and milestone should trace back to the scratchpad date or meeting name it came from.
• Don't duplicate the Meetings Wiki. Reference recurring threads and open loops from the Meetings Wiki rather than reproducing them.
• Be conservative with project creation. Only create a project folder when something has meaningful ongoing work. A one-off mention doesn't need its own page.
• Infer TODO completion carefully. Only mark a TODO as done when there's clear evidence. "Working on X" does not mean X is done.
• Date everything. Decisions, milestones, notable statements, and TODO creation/completion should all have dates.
• Respect the structural conventions. Default new projects to single-file _index.md. Don't create sub-folders or archive folders speculatively — they appear when promoted by the Step 5 rules.
• Keep cleanup scoped to projects/. Step 5 actions never touch learnings/, people/, daily notes/, or anything outside projects/. Learnings are durable knowledge and stay static; people/meeting open items are reviewed by you, not by the sync.
• Two-commit discipline. Commit 1 (additive) must succeed before Step 5 runs. If Commit 1 fails, skip Steps 5+6 entirely so the next run can retry from a clean state.
• Process every line of the scratchpad. Content that doesn't fit into projects/people/learnings gets skipped (it stays searchable in the raw scratchpads), but every line should be consciously considered, not skimmed.