weekly-update

name

weekly-update

description

Weekly Wrap Up (named "Deeper Thinking" at launch, renamed by Brian on Substack 2026-08-26) — the lower-frequency companion to the Daily Brief. A live ceremony with Brian that recaps the stories since the last one, clears the promotion-candidates and staleness-candidates queues, captures his real takeaways, and drafts a dual-byline "Weekly Wrap Up" post. Use when the user runs /weekly-update, or asks for a weekly review, a Weekly Wrap Up issue, or "what's changed since last time" walkthrough.

Weekly Wrap Up ceremony

The internal skill/directory name stayed weekly-update (matches how the Daily Brief's own skill directory is skills/brief/ even though its public name is "Daily Briefing" — the mechanism's name and the product's name don't have to match). The actual publication is called Deeper Thinking — Brian's own name, chosen 2026-08-24 over a shortlist that included "Second Thoughts" and "Loose Threads." The name is doing real work: it's the literal claim of one of this ceremony's own recurring promote-candidates ("AI makes knowledge work deeper, not faster"), and it contrasts cleanly with the Daily Brief's speed.

This is me/developing-thinking.md's D5-era open ask (BUILD.md open decision #13, "a weekly 'how my thinking has changed' recap post") and Workstream E's deferred Substack question, both closed 2026-08-24: dual byline (Brian + brianmadden.ai). Substack placement: Brian is now leaning toward a dedicated Section of its own (revised 2026-08-24 from the original "fold into existing structure" call, made the same day before the first issue was even finished) — still unbuilt (manual Substack UI work, same category of gap as the rest of Workstream E), but don't assume "no Section" going forward.

Unlike brief.py/triage.py, the actual ceremony is not a script that runs unattended. Brian's own framing was explicit: he wants to read a recap, talk it through live, and give his own reactions — the value is the conversation, not just the artifact. This skill is that conversation, in the same spirit as review-thinking, and reuses that skill's mechanics for the developing-thinking.md portion rather than duplicating them.

One part of the pipeline does run unattended, added 2026-08-24, Brian's own ask: skills/weekly/gather.py assembles the prep doc deterministically (no LLM call of its own beyond re-running triage.py) and, with --send, emails it to Brian. Wired into daily-pipeline.yml to run on Fridays, after that day's Daily Brief. It does not run the interactive ceremony — steps 4 onward below still need Brian live, whenever he actually sits down with the emailed prep doc, not necessarily the same day it lands. skills/weekly/render.py is the other reusable script — Substack-paste HTML for the finished post.

Cadence

Variable, not fixed weekly — Brian's own words: "since I last did this... ideally a week, could be a few days, could be a few weeks." Driven by outputs/weekly-updates/.last_run.json (same {"last_run_utc": "..."} shape as outputs/technical-briefings/.last_run.json), read at the start of every run — by both gather.py and this ceremony. No prior run recorded → default the window to 7 days back. gather.py's automated Friday run and the live ceremony share the same clock: whichever runs last (usually gather.py, since it's unattended) sets the window the other picks up from next time.

Steps

1. Check for an existing same-batch prep doc before regenerating. gather.py's Friday run may have already written and emailed outputs/weekly-updates/YYYY/MM/YYYY-MM-DD-prep.md earlier — if a prep doc exists from since the last live ceremony ran (check its date against outputs/weekly-updates/.last_run.json... but note gather.py updates that same file, so in practice: if a prep doc's file date is after the ceremony's last run — track this separately if needed, or just ask Brian whether he's already seen a prep email), read that file instead of re-gathering from scratch. Re-run triage.py anyway if more than a day or two has passed since the prep doc was written — a stale staleness-queue snapshot defeats the point (same non-negotiable as review-thinking step 1). If no recent prep doc exists (Brian triggering this ad hoc, off the Friday cadence), gather fresh — same logic gather.py runs, described there.

2. Present the prep doc to Brian before discussing anything. If it arrived by email days ago, don't assume he remembers the details — summarize the scale (how many stories, how many queue items) and let him set the pace, same as the first live run did.

3. Walk the promotion-candidates queue, one entry at a time, in the order the file lists them. For each: show Brian the thread (what recurred, how many times, the actual notes), ask what he wants to do, apply immediately:

   • Promote — draft the addition into me/developing-thinking.md's "What's connecting" section together, in his words as much as possible, dated today. Then delete that entry from promotion-candidates.md — promoted is resolved, not still queued.
   • Reject — delete the entry from promotion-candidates.md, no addition anywhere. Rejected is also resolved.
   • Not yet — leave the entry in place, still open. Don't force a decision on something he's genuinely unsure about.
   • Consolidate — if two or more entries turn out to be the same underlying story (the pipeline's thread-matching is exact-slug-only, per BUILD.md open decision #15 — this happens), say so before asking for a decision on each separately, and propose merging them into one canon entry instead. With a real backlog (more than a handful of entries), don't grind through them one cold call at a time — group them by an honest read first (obvious near-duplicates, clean promotes, genuine judgment calls, low-interest ones) and give Brian that read before asking for decisions; he can always ask for strict one-by-one instead. Same non-negotiable either way: never batch-apply, never promote or reject without his live call on that specific entry or group.

What this doesn't do

Never edits me/developing-thinking.md, promotion-candidates.md, or a framework's status without Brian's live decision on that specific item — identical non-negotiable to review-thinking and triage.py. Never publishes to Substack itself — that stays a manual paste-and-click step, same as the Daily Brief. gather.py's automated Friday run never makes any of these decisions either — it only assembles and emails the prep doc, exactly the same read-only gathering the live ceremony's own first steps do.

Known limitations (v1)

• First real run had no prior .last_run.json — window defaulted to 7 days, which happened to line up with the 10 daily briefs that existed since launch (2026-08-11 through 2026-08-24). A genuinely variable gap (Brian's "could be a few weeks") is untested until it actually happens.
• Partial automation, added 2026-08-24. gather.py on Fridays handles the deterministic prep-and-email step. The interactive ceremony itself (steps 3 onward here) still needs a live Claude Code session — nothing schedules or reminds Brian to actually run /weekly-update after the email lands. If that gap turns out to matter in practice, a schedule-skill reminder is the natural next piece, not a change to this ceremony.
• gather.py and this ceremony share one .last_run.json, which has a real edge case: if Brian doesn't run the live ceremony before the next Friday's gather.py run, that next prep doc's window starts from the previous Friday (gather.py's own last run), not from whenever the live ceremony actually happens to catch up — meaning a skipped week could show up compressed into a later prep doc's "stories" list, or get missed if gather.py overwrites the clock before the backlog's been cleared. Not yet stress-tested; watch the first few real Fridays.
• Byline mechanics on Substack are still manual. Frontmatter records byline: [brianmadden.ai, Brian Madden], but actually setting two contributors on the Substack post (and, if Brian follows through on wanting a dedicated Section, creating that Section) is manual editor work, same category of gap Workstream E already flagged for tags/ Sections generally.