systems

Weekly Review System

Last updated: 3/29/2026

Weekly Review System

A 30-45 minute weekly operating system that produces clarity, relief, and actionable plans. Not a guilt-inducing audit.

Related systems: [[ideal-week-system]], [[active-rules]], [[work-session-system]] When: Sunday morning (per [[ideal-week-system]] template, 9:15-10:00) Duration: 30-45 minutes. Hard cap at 45 min. If consistently exceeding this, move items to a monthly review. Template: [[weekly-note]] in templates/weekly-note.md


Why This Works

Weekly reviews produce behavior change through three mechanisms:

  1. Zeigarnik relief — making a plan for uncompleted tasks reduces their cognitive burden, even before execution (Masicampo & Baumeister, 2011)
  2. Implementation intentions — translating goals into "IF X THEN Y" statements doubles follow-through (Gollwitzer, d=0.65, 94 studies)
  3. Calibration — comparing predictions to outcomes is the core mechanism of improved decision-making (Tetlock)

The Review (4 Phases)

Phase 0: Priming (5 min)

Set the stage — shift from "doing" mode to "designing" mode.

  1. Switch environment. Move to a different room, play different background music, or change your physical setup. Context shifts aid reflective thinking.
  2. Close everything. No tabs, no messages, no notifications. The review is the only thing open.
  3. Read something inspirational. Re-read a section from a favorite essay or book on life design (rotate each week — [[important-beliefs]], [[current-vision]], a Ben Kuhn post, a Goggins passage, etc.). This primes reflection, not obligation.

Phase 1: Triage (10-15 min)

Backward look — what happened?

  1. Read each daily note for the week. Don't analyze yet — just absorb.
  2. Fill in the time budget table — compare actual hours vs. [[ideal-week-system]] targets. The agent can pre-populate this from calendar data.
  3. Fill in the habit adherence table — check/uncheck from daily notes. Note data quality (missing days = tracking failure, not necessarily behavior failure).
  4. Review experiment check-ins — which experiments are on track? Which need attention?

Phase 2: Reflection (10-15 min)

What does this mean?

  1. What went well? List 3-5 wins. Celebrate them — this triggers guilt (behavior-focused, motivating) not shame (identity-focused, paralyzing). Shame predicts procrastination via rumination; guilt predicts corrective action (Bohns & Flynn, 2013).
  2. What went wrong? List 3-5 losses. For each, ask: is this a behavior problem, a system problem, or an environment problem? Behavior → adjust the if-then rule. System → modify the system. Environment → change the environment.
  3. Double-loop check: "Is the system that produced these results working, or does the system itself need changing?" (Argyris). Don't just adjust actions — question whether the framework is right.
  4. Calibration: Did my predictions from last week match reality? Where was I over/under-confident? Log in agent/state/calibration-log.md if relevant.

Phase 3: Planning (10-15 min)

What's next?

  1. Top 3 priorities for next week. Not 10. Three. The rest goes on the backlog.
  2. Implementation intentions — for each priority, write an IF-THEN rule: "IF [specific trigger], THEN I will [specific action]." These go into [[active-rules]].
  3. Pre-mortem — "Imagine it's next Sunday and this week went poorly. What happened?" Write down the top 2-3 failure modes and a countermeasure for each (Klein: 30% better risk identification).
  4. Unfinished business — carry forward the 3-5 most important undone items. Everything else gets dropped or backlogged. Essentialism: if it's not a clear yes, it's a no.
  5. Context-specific planning — if next week has unusual context (travel, events, deadlines), adjust the plan accordingly. New environments are habit installation windows.

Anti-Patterns (What Makes Reviews Fail)

  1. Too long. If it takes >45 min, the template is too complex. Simplify.
  2. Shame-focused. "I'm so undisciplined" → withdrawal and avoidance. Reframe: "I missed 3 runs. What got in the way? How do I remove that obstacle?"
  3. No implementation intentions. Vague goals ("be more productive") don't change behavior. Specific if-then rules do.
  4. Skipping the pre-mortem. Only looking backward misses predictable failures. Always imagine next week going wrong.
  5. Treating it as a task. The review is an operating system, not a checkbox. Its output is clarity and a plan, not a completed form.
  6. Not doing it. The best review is the one you actually do. A 15-minute review done consistently beats a 90-minute review done sporadically.

Restart Protocol (when you've dropped it)

You will drop this review, and the dailies that feed it. That is expected — for Matt it's a broad, stable pattern across nearly everything scheduled, not a character flaw. So the system is designed to be dropped and restarted, not kept in an unbroken streak. The metric that matters is how fast you restart after a lapse — not how long the streak was.

  1. No backfill — ever. Never reconstruct missed days or skipped reviews. Skip straight to the current period and review only that. Backfilling manufactures guilt (shame → avoidance → longer gap); the missed days are gone, and that is fine. A weekly review done on this week's data, ignoring the three weeks you skipped, is a complete review.
  2. The restart must be cheaper than the original. Restarting = reacting to the pre-assembled draft (see the auto-assemble pipeline), not authoring from a blank template. If no draft exists, the restart is one voice-capture answering a single question ("what mattered this week?") — nothing more. The first rep back is allowed to be tiny.
  3. One cheap restart, not a guilt audit. When a gap is noticed — by you, or by the coach at boot — the only response is one forward action. Never a retrospective tally of everything missed. The coach surfaces a single restart, not a list of failures.
  4. Reframe the gap inside the review. Missing days = a tracking gap, not a behavior verdict (Phase 1.3). Track "days-to-restart" as the health signal. A week skipped then restarted in two days is a healthy system; a streak kept out of fear is not.

Why: for Matt the failure mode is never the first miss — it's the gradual fade after a broken streak (user-model §2) plus the guilt that makes restarting feel worse than continuing. Removing the backfill obligation and pre-loading the restart removes both. Designed 2026-05-31.


Restart Protocol (when you've dropped it)

You will drop this review, and the dailies that feed it. That is expected — for Matt it's a broad, stable pattern across nearly everything scheduled, not a character flaw. So the system is designed to be dropped and restarted, not kept in an unbroken streak. The metric that matters is how fast you restart after a lapse — not how long the streak was.

  1. No backfill — ever. Never reconstruct missed days or skipped reviews. Skip straight to the current period and review only that. Backfilling manufactures guilt (shame → avoidance → longer gap); the missed days are gone, and that is fine. A weekly review done on this week's data, ignoring the weeks you skipped, is a complete review.
  2. The restart must be cheaper than the original. Restarting = reacting to the pre-assembled draft (see the auto-assemble pipeline), not authoring from a blank template. If no draft exists, the restart is one voice-capture answering a single question ("what mattered this week?") — nothing more. The first rep back is allowed to be tiny.
  3. One cheap restart, not a guilt audit. When a gap is noticed — by you, or by the coach at boot — the only response is one forward action. Never a retrospective tally of everything missed. The coach surfaces a single restart, not a list of failures.
  4. Reframe the gap inside the review. Missing days = a tracking gap, not a behavior verdict (Phase 1.3). Track "days-to-restart" as the health signal. A week skipped then restarted quickly is a healthy system; a streak kept out of fear is not.

Why: the failure mode is never the first miss — it's the gradual fade after a broken streak (user-model §2) plus the guilt that makes restarting feel worse than continuing. Removing the backfill obligation and pre-loading the restart removes both.


Restart Protocol (when you've dropped it)

You will drop this review, and the dailies that feed it. That is expected — it's a broad, stable pattern across nearly everything scheduled, not a character flaw. So the system is designed to be dropped and restarted, not kept in an unbroken streak. The metric that matters is how fast you restart after a lapse — not how long the streak was.

  1. No backfill — ever. Never reconstruct missed days or skipped reviews. Skip straight to the current period and review only that. Backfilling manufactures guilt (shame → avoidance → longer gap); the missed days are gone, and that is fine. A review done on current data, ignoring the gap behind it, is a complete review.
  2. The restart must be cheaper than the original. Restarting = reacting to the pre-assembled draft (see the auto-assemble pipeline), not authoring from a blank template. If no draft exists, the restart is one voice-capture answering a single question ("what mattered lately?") — nothing more. The first rep back is allowed to be tiny.
  3. One cheap restart, not a guilt audit. When a gap is noticed — by you, or by the coach at boot — the only response is one forward action. Never a retrospective tally of everything missed. The coach surfaces a single restart, not a list of failures.
  4. Reframe the gap inside the review. Missing days = a tracking gap, not a behavior verdict — note the data quality and move on. Track "days-to-restart" as the health signal. A gap that gets restarted quickly is a healthy system; a streak kept out of fear is not.

Why: the failure mode is never the first miss — it's the gradual fade after a broken streak (user-model §2) plus the guilt that makes restarting feel worse than continuing. Removing the backfill obligation and pre-loading the restart removes both.


Evidence Base

Full research at [[weekly-review-research]] (resources/weekly-review-research.md). Key sources:

  • Uhlig et al. (2023): weekly planning reduces rumination, increases cognitive flexibility (N=208, field experiment)
  • Gollwitzer: implementation intentions d=0.65 across 94 studies
  • Klein: pre-mortems increase risk identification by 30%
  • Bohns & Flynn (2013): shame → procrastination; guilt → corrective action
  • Argyris: double-loop learning (question the system, not just the actions)
  • Forte: 15-30 min tactical review; keep it short enough to never skip