weekly-review

name	weekly-review
description	Weekly patterns review - aggregate progress, insights, and alignment

Weekly Review - Patterns Over Time

You are facilitating the user's weekly review. This is a higher-altitude review that connects daily progress into weekly patterns and ensures alignment with priorities.

Philosophy

The weekly review creates the crucial link between tactical execution (daily/session level) and strategic direction (monthly/quarterly goals). It's where you catch value drift, spot emerging patterns, and realign effort with priorities. Vault structural maintenance is handled by $weekly-hygiene — this command focuses on reflexion and planning.

Instructions

0. Resolve Vault Path

   "$VAULT_PATH/.claude/scripts/resolve-vault.sh"
   "$VAULT_PATH/.claude/scripts/check-archive-layout.sh" --enforce "$VAULT_PATH"
   

   If error, abort. Read ~/.codex/skills/_shared-rules.md and apply its rules throughout this skill. All code below uses {VAULT} as a placeholder — substitute the resolved vault path.

1. Check current date and calculate review boundaries using bash date command:

   • Get current date: date +"%Y-%m-%d"
   • Get ISO week number: date +"%G-W%V" (for file naming: YYYY-Wnn.md). %G (ISO year), not %Y — they differ in the 29 Dec–3 Jan boundary window, and %Y-W%V there produces a nonexistent week key that corrupts the latest-file sort.
   • Find the previous weekly review: ls -1 "{VAULT}/06 Archive/OpenCairn/Weekly Reviews/" 2>/dev/null | rg '^[0-9]{4}-W[0-9]{2}[a-z]?\.md$' | LC_ALL=C sort -r | head -1. Both filters are load-bearing: the pattern drops any free-named file that would otherwise outrank the reviews, and LC_ALL=C is what makes the collision-guard suffix (step 5's YYYY-Wnnb.md) sort after the bare YYYY-Wnn.md — locale collation ignores the . and reverses that order, selecting the older review and re-covering days already closed out.
   • Review period starts at the day after the previous review's last covered date. Parse the end date from the ## Daily Reports section (which has explicit YYYY-MM-DD dated links) — this is more reliable than parsing the free-text title. The last covered date is the latest of: the dated links AND any "(no report for [date] …)" notes in that section — a review can end on days that produced no daily report (travel/offline days), and taking only the last dated link would make the next review re-cover them. If the review's title date range ends later still, prefer the title's end date and note the discrepancy. If no previous review exists, fall back to Monday of the current ISO week. Store as PERIOD_START.
   • Review period ends at the current date.
   • Get date range for display: e.g., "Week 11, Mar 9-11" or "Weeks 10-11, Mar 2-11" if the period spans multiple ISO weeks.
   • This command can be run on any day of the week, at any cadence (4-12 days between reviews is normal). Do not assume Sunday-to-Sunday cycles.

2. Check for Hygiene Report and gather the week's data:

   Hygiene report:

   • Look for the latest file in {VAULT}/06 Archive/OpenCairn/Hygiene Reports/, filtering to ^[0-9]{4}-W[0-9]{2}\.md$ and using LC_ALL=C sort -r. Preserve the exact returned basename. Free-named files in the directory are not hygiene reports.
   • If a report exists, parse the week number from its filename (e.g., 2026-W10.md → W10) and compare to the current ISO week (date +%G-W%V):
     • Current week: Read and incorporate — no warning
     • Previous week or older: Warn: "Latest hygiene report is from [week] — vault state may have changed. Consider re-running $weekly-hygiene before continuing. Proceeding with stale data." Continue with the review but flag staleness in the output.
   • If no reports exist, note this and suggest running $weekly-hygiene first (but continue with the review)

   Week's activity data:

   • Read daily reports from {VAULT}/06 Archive/OpenCairn/Daily Reports/ for dates from PERIOD_START to current date
   • Daily report gap detection: Compare the review period date range against files actually present in Daily Reports/. Flag any missing dates (e.g., "No daily report for Mar 18, 19, 20"). Include this in the review output under Challenges & Friction if gaps exist.
   • Read session summaries from {VAULT}/06 Archive/OpenCairn/Session Logs/ for the same date range. While reading, collect Open Loops entries and note any that are 14+ days old and still unresolved — these are the producer for the review's "Aged Open Loops" section (the hygiene report does not track open loops; they come from session logs).
   • Session count: Use rg -c "^## Session" <session-log-file> as the canonical session count per day. Daily report self-reported counts may disagree due to merge addendums creating sub-entries under existing session headers. When counts disagree, use the ^## Session header count and note the discrepancy.
   • Read the 03 Projects/ root docs to see active projects — each carries bucket: frontmatter; use ## Current Objective and ## Next Actions when present, but do not require them. Folder location is the status (root = active, Cold/ = paused, = unstarted). If the root doc count (excluding and ) exceeds the (resolve it first: over → , and state the value found. — the needle is literal. Exit 1, or a line yielding no number, means state and proceed on 5, so a failed read is never mistaken for a vault that states no cap. — report it and stop, rather than falling through to the default, which is the failure this branch exists to prevent) — flag it and ask which project moves to

3. Run the weekly review interview:

Before diving into the lenses below, ask the user once whether they want interactive mode (walk through each lens together) or auto-generate mode (compile answers from data, present once for validation). One question upfront.

• Interactive mode: use the lenses below as a sequential interview.
• Auto-generate mode: use the lenses as a completeness checklist, not as separate prompts. Compile the evidence-supported synthesis, accomplishments, project movement, time allocation, patterns and alignment findings into one proposed review. Do not invent first-person reflections, correction-log promotion decisions or forward commitments. Present one consolidated validation block containing the draft plus only unresolved decision-bearing questions — always including next week's Big Rocks, course corrections, Stop/Delegate items and any proposed correction promotion. Apply the user's corrections, then continue to step 4.

Collect - What happened:

• "What were the major accomplishments this week?"
• "Which projects moved forward? Which stalled?"
• "Time allocation: Where did the bulk of hours go?"
• If hygiene report exists, reference its scratchpad / tickler / working-memory findings here rather than re-gathering (open loops are not in the hygiene report — they come from the session-log sweep in step 2)

Reflect - What matters:

• "Key insights or learning from this week?"
• "What patterns emerged? (Good and bad)"
• "Any surprises - things that were easier or harder than expected?"
• "What did you overestimate? Underestimate?"

Align - Priorities check (reference Direction.md if loaded):

• "Looking at how you spent time vs your strategic plans - any misalignment?"
• "What got attention that shouldn't have?"
• "What didn't get attention that should have?"
• "Are you working on the right things?" (Check against career and personal strategic plans)
• "Any disciplines that slipped this week?" (Check against disciplines list)
• "Anything on the anti-goals list that crept back in?"

Plan - What's next:

• "What's the focus for next week?"
• "Any course corrections needed?"
• "Anything to stop doing or delegate?"

4. Ensure directory exists:

   • Check if {VAULT}/06 Archive/OpenCairn/Weekly Reviews/ directory exists
   • If not, create it: mkdir -p "{VAULT}/06 Archive/OpenCairn/Weekly Reviews"
   • This prevents first-run failures

5. Generate weekly review:

Resolve the output basename once. Start with REVIEW_BASENAME=YYYY-Wnn using the current ISO week from step 1. If the bare file exists, list YYYY-Wnn[a-z].md under LC_ALL=C, then choose the successor of the greatest existing suffix (b if none exists). Never fill a suffix gap: a later review must sort ahead of every earlier one. If z already exists, stop and ask the user to archive or rename records; never wrap, overwrite or reuse a suffix because each weekly review is a dated reflective record. Carry this exact basename through the output path, step 5a's reminder/backlink and the final confirmation.

Draft the complete review outside the vault, then install it at {VAULT}/06 Archive/OpenCairn/Weekly Reviews/<REVIEW_BASENAME>.md through "{VAULT}/.claude/scripts/locked-edit.sh" --replace-whole MISSING. Immediately before the call, confirm the chosen path is still absent. Exit 2 means another writer claimed the basename: re-list, recompute the successor of the greatest existing suffix, update REVIEW_BASENAME and retry; never fill a gap, append to, or replace an existing weekly review. The letter suffix only outranks the bare name under byte collation, which is why step 1's previous-review lookup pins LC_ALL=C sort -r.

⛔ Cite review items by stable identifier, not line number — see _shared-rules.md §13. A hygiene report consumed in the same pass may have already reshuffled This Week.md or a project doc, so any This Week.md Lnn carried into this durable review is stale on write. Name items (tasks, project-doc actions, Tickler lines, aged open loops) by title/heading/content.

# Weekly Review — [Date Range]

## Synthesis
**The week:** [One-line summary of what the week was about and what got done]
**Honest take:** [Candid 1-2 sentence assessment - alignment, drift, or what the user should hear]

## Session Count
[Total sessions, daily breakdown table if useful, average per day]

## Major Accomplishments
[Bullet list of significant progress, completions, milestones]

## Projects Active This Week
**Advanced:**
- [[03 Projects/Project A]] - [What moved forward]
- [[03 Projects/Project B]] - [What moved forward]

**Stalled:**
- [[03 Projects/Project C]] - [Why stalled, what's blocking]

**Completed:**
- [[03 Projects/Project D]] - [Outcome achieved]

## Time Allocation
[High-level breakdown of where hours went]
- Work/Training: X%
- Projects: Y%
- Health/Fitness: Z%
- etc.

## Key Insights & Patterns

### Wins & What's Working
[Patterns of success, effective strategies, good decisions]

### Challenges & Friction
[Recurring problems, inefficiencies, areas needing attention]

### Learning
[New skills, realisations, mental model updates]

## Alignment Check

### Schedule vs Execution
*[Populate from Schedule-vs-Execution data gathered in step 2. If the cadence gate failed, render just: "Schedule-vs-Execution reconciliation skipped — vault autocommit cadence below threshold (or no git repo)." Otherwise render the table + profile + divergence list below.]*

| Day | Scheduled | Checked | Added | Migrated |
|-----|-----------|---------|-------|----------|
| [Day DD] | N | N | N | N |

*[For a day with no usable snapshot, write `— no snapshot` in the Scheduled cell and leave the rest blank; for a located but empty day section, write `— not planned`. Never render either as `0`.]*

**Folder-attention profile ([period] total, distinct files touched):**
- [folder at scheduled-vocabulary depth] — N
- [folder] — N
- *(outside scheduled vocabulary)* — N

*[If any days flagged by the schema-drift sanity check, append:]*
⚠ Parser returned zero scheduled items for [day(s)] despite non-zero commits — This Week.md format may have drifted. Spot-check the day section.

*Blind spots:* non-vault work (packing, spoken conversations, reading PDFs) is invisible; deep-work commit sparsity (4h on one file = few commits) under-counts genuine focus.

### Priorities vs Reality
[Honest assessment: Is effort aligned with stated priorities? The Schedule vs Execution subsection above gives you the mechanical distribution — this subsection is the judgement call on whether that distribution matches what mattered.]

### Value Drift Alerts
[Any signs of drift toward low-value activities?]

### Aged Open Loops (14+ Days)
**Stale items requiring action:**
- Item from Session X (N days old) - Complete, drop, or delegate?
- Item from Session Y (N days old) - Complete, drop, or delegate?

**Recommendation:** These have lingered for 2+ weeks. Either act or explicitly drop.

### Long Poles [LP], Cornerstones [CS] & Guillotines [GT]

**Long Poles** - Need lead time, can't be rushed:
- [LP task from file X] - Status/progress this week?
- [LP task from file Y] - Status/progress this week?

**Cornerstones** - Foundational, other things depend on these:
- [CS task from file X] - Status/progress this week?
- [CS task from file Y] - Status/progress this week?

**Guillotines** - Hard deadlines; missing them forecloses the option or causes irreversible loss:
- [GT task from file X] - Deadline DD Mon YYYY (X days left) - on track? (flag 🔴 overdue / 🟠 ≤30d)
- [GT task from file Y] - Deadline DD Mon YYYY (X days left) - on track?

**Review:** Are LP items getting attention early enough? Are CS blockers being addressed? Is any GT deadline overdue or imminent? *(For a focused, date-sorted view, run `$guillotines`.)*

### Claude Corrections Log Review
**New entries this week:**
- [Date] - [Mistake summary] - Lesson: [key takeaway]

**Promote to active recall?**
- [Entry] → Add to AGENTS.md, Claude-side guidance/memory, both, or neither? (Y/N, reason)

*Corrections Log is write-only unless promoted. Review weekly to catch patterns worth internalising.*

### Vault Maintenance
*Hygiene report from: YYYY-Wnn (current week / stale — re-run recommended / not found)*

[Populated from Hygiene Report if available — see `$weekly-hygiene`]

[Summary of hygiene findings: project-doc health, tier mismatches, tickler items, broken links, etc.]

*If no hygiene report: "No hygiene report available — run `$weekly-hygiene` for vault maintenance."*

### Course Corrections Needed
[What to adjust for next week]

## What's Next

**Big Rocks (Priority 1):**
- Most important thing
- Second priority

**Active Projects:**
- Project A - [Specific next milestone]
- Project B - [Specific next milestone]

**Stop/Delegate:**
[Things to drop or hand off]

## Daily Reports
[Links to daily reports for drill-down]
- [[06 Archive/OpenCairn/Daily Reports/YYYY-MM-DD]] - Mon
- [[06 Archive/OpenCairn/Daily Reports/YYYY-MM-DD]] - Tue
- etc.

5a. ⛔ Backstop the review's deadline-bearing items with one dated reminder.

The review file is a reflective record, not a task surface — nobody re-reads it, so a course correction naming a deadline dies there, and because writing it down reads as acting on it, the next review re-derives the same correction and the item carries indefinitely.

This step deliberately does not route each item to its own dated surface. Doing so needs per-item date resolution, dedup across several files, and conditional writes — more moving parts than a prose step executes reliably, and every part that misfires does so silently. Instead it writes one Tickler line pointing back at the review. When that surfaces, $morning puts it in front of the user and the existing routers ($park Step 7, the day plan) place the individual items with full context. One indirection, one write, almost nothing to get wrong.

(a) Scan and list. Read the review's Course Corrections Needed and What's Next → Big Rocks sections for items whose text carries a deadline, cut-off, expiry, renewal, or by / before / closes <date> clause. Display them with the date each names. Trigger-contingent items are not deadline-bearing — "before the next X runs" has no date to derive; leave them out. If nothing qualifies, emit the nil checkpoint and go to step 6.

(b) Pick the reminder date. Take the earliest date found and subtract 3 days of lead time; if that lands today or earlier, use tomorrow. Resolve relative expressions with date -d and verify any weekday you write (§7).

An item whose deadline you cannot resolve still counts. If it names an event with no date in its own text ("before the conference"), do not go hunting for one and do not invent one — leave it out of the earliest-date arithmetic but keep it in the list and in N. The pointer model makes this cheap: the reminder's job is to put the user back in front of the review, and an item with a fuzzy deadline needs that more than one with a crisp date, not less.

(c) Dedup, then write one line (§5 — write-tickler.sh, never a raw edit). A review re-run in the same ISO week would otherwise add a second line.

Use <REVIEW_BASENAME> from step 5 in both the search and the wikilink. A bare YYYY-Wnn is a prefix of the suffixed sibling: as a dedup key it matches the earlier review's line and silently suppresses this review's backstop, and as a wikilink it points the reminder at the wrong review. Anchor the search with the closing ]] so the match is exact rather than prefix-wise.

# 0 → write. Non-zero → a reminder for this review already exists (a re-run of the same
# review file); skip the write and report it. Absent Tickler is fine: rg says 0,
# write-tickler.sh creates it.
rg -c -F "Weekly Reviews/<REVIEW_BASENAME>]]" "{VAULT}/01 Now/Tickler.md" 2>/dev/null || echo 0

"{VAULT}/.claude/scripts/write-tickler.sh" "{VAULT}/01 Now/Tickler.md" "YYYY-MM-DD" \
  "- [ ] Weekly review <REVIEW_BASENAME> flagged N deadline-bearing items (earliest: <short gloss>, <date>) — place them → [[06 Archive/OpenCairn/Weekly Reviews/<REVIEW_BASENAME>]]"

This step's disallowed sink is the review file itself (§18 requires each caller to name its own): a deadline-bearing correction left only in "Course Corrections Needed" or "Big Rocks" is the failure this exists to prevent. One dated pointer discharges the whole set.

⛔ CHECKPOINT — display one of:

✓ Deadline backstop: N items flagged, reminder set YYYY-MM-DD
- "[item]" — [date it names, or "no date in item — listed only"]

✓ Deadline backstop: no course correction or big rock carries a deadline

✓ Deadline backstop: N items flagged, reminder already set YYYY-MM-DD (same-week re-run)

You cannot proceed to step 6 without one of these lines. The item list is the observable — a bare count is reasoning-from-memory.

6. Populate Vault Maintenance section from hygiene report. If a hygiene report was found (from step 2), include its findings in the review output's Vault Maintenance section. If no report exists, note "No hygiene report available — run $weekly-hygiene for vault maintenance" in that section.

7. Update project docs (if needed):

   • Write mechanism (F1): apply these edits through locked-edit.sh, never a raw edit (see _shared-rules.md §5).
   • Status changes from the review go to the relevant project doc in 03 Projects/ — update its existing current-state/action content, preserving the document's structure; a pause or resume is a folder move (root ↔ Cold/), not a status line
   • New projects that emerged this week get a doc (via $start-project)

8. Generate Claude Web context summary:

   Generate a comprehensive context snapshot (~120-150 lines) for the user to import into Claude Web via Settings > Capabilities > Memory > "Import memory from other AI providers" > paste into the "Add to memory" field. This gives Claude Web up-to-date, vault-informed context that merges into its Memory.

   How Claude Web Memory works: Claude Web auto-generates a "Memory from your chats" summary nightly from chat history. Imported context merges into this same Memory blob. The nightly regeneration restructures everything into third-person prose with sections like "Work context", "Personal context", "Top of mind", "Brief history". The context file is the user's authoritative, vault-informed self-description — more accurate than what Memory derives from chat patterns alone.

   Output location:

   • Ensure directory: mkdir -p "{VAULT}/06 Archive/OpenCairn/Weekly Context"
   • Write output to {VAULT}/06 Archive/OpenCairn/Weekly Context/YYYY-Wnn.md (using the current ISO week, per step 1's %G-W%V; unlike the review file, overwriting a same-week context doc is correct — it's a regenerated current-state export, latest wins)

   Gather context for dynamic sections:

   • Read the 03 Projects/ root docs — every active project is a candidate for inclusion, not just "work." Relationships, health threads, ongoing evaluations, and personal decisions that are actively shaping behaviour belong in the context file if they'd change how Claude Web responds.
   • Read the 2-3 most recent weekly reviews from (same pattern-constrained listing as step 1, ) for trajectory and recent events. The current week's review data is already available from earlier steps.

✓ Weekly review saved to: 06 Archive/OpenCairn/Weekly Reviews/<REVIEW_BASENAME>.md
✓ Projects reviewed: N active, M completed, P stalled
✓ Deadline backstop: N items flagged, Tickler reminder set YYYY-MM-DD [OR "no resolvable deadlines"]
✓ Hygiene report: [Incorporated / Not found — run $weekly-hygiene]
✓ Claude Web context drafted: 06 Archive/OpenCairn/Weekly Context/YYYY-Wnn.md
  - Banned-vocab scrub: [N hits / clean; if hits, list location and whether quoted-citation acceptable]
  - Lineage/methodology claims: [N found; all source-verified against `Context - *.md` / none found]
  - Sections re-verified this run (>30 days stale or bootstrap): [list]
  - Verification log updated: 06 Archive/OpenCairn/Weekly Context/.verification-log.md
✓ What's next: [Top 2-3 priorities]

Weekly review complete.

⚠ BEFORE PASTING into Claude Web Memory: review the context doc end-to-end. The scrubs above are model-self-checks and have a known gloss-risk. Errors caught in past iterations: confabulated lineage attributions, stale insurance/claim status carried forward, sections describing transient state. Two-minute read by the user is the durable backstop.

Recommended: Skim the weekly review itself at the start of next week to set the week's direction.

Guidelines

• Always check current date: First step - run date command to calculate accurate week boundaries. Never assume.
• Patterns over details: Look for recurring themes, not exhaustive documentation
• Honest alignment check: This is where you catch yourself working on the wrong things
• Forward-looking: Use insights to improve next week, not just to record past week
• Connect timescales: Link weekly patterns to monthly/quarterly goals (if tracked)
• Quantify when useful: Time allocation, completed tasks, etc. - numbers reveal patterns
• Natural language: Write in the user's voice - analytical, outcome-focused, honest

Frequency

Run whenever the user requests it. Typical cadence is every 4-12 days — there is no fixed day-of-week requirement. The review period adapts to cover whatever time has elapsed since the last review.

Integration with Other Commands

• Consumes $weekly-hygiene: Reads the hygiene report for vault maintenance findings — no need to re-gather
• Synthesises daily reviews: Aggregates daily patterns into weekly insights
• Informs project planning: Identifies what needs attention, what to drop
• Feeds into monthly/quarterly reviews: (If the user implements those)
• Alignment with philosophy: Connects tactics to values (see Philosophy & Worldview context)

This creates a review rhythm that prevents value drift and ensures high-level course correction.

Goal Alignment (Optional Enhancement)

If the user starts tracking explicit goals in the vault:

• Compare weekly effort to goal progress
• Flag misalignments ("You spent 40% of time on X, but it's not in your top 3 goals")
• Suggest reallocation or goal updates