Weekly Review

Scans the user's journal for the past 7 days and produces a structured review. Lives under today's journal as a single block — don't create a separate weekly review page.

How to invoke

• /weekly-review — last 7 days from today
• /weekly-review last-2-weeks — last 14 days
• /weekly-review 2026-06-08 2026-06-14 — explicit date range
• Natural: "what did I do this week", "sunday review", "weekly recap"

If no range given, default to last 7 days including today.

Steps

1. Compute the date range

Default: today minus 6 days through today (7 days inclusive).

Convert each date to Logseq journal page format: <MonAbbr> <D><ordinal>, <YYYY> (e.g. Jun 12th, 2026).

2. Read each journal page

Use mcp__mcp-logseq__get_page_content for each date in the range. Skip dates with no page (Logseq doesn't create journals for days you didn't write).

3. Extract from each day

Look for these patterns in the blocks:

• Brags — blocks containing [[brag]] link or tags:: brag
• Decisions — blocks containing [[decisions]] link or tags:: decisions
• Meetings — blocks containing [[meetings]] link or tags:: meetings
• Completed TODOs — blocks starting with DONE marker
• Open TODOs — blocks starting with TODO , LATER , NOW , DOING markers
• Incidents — blocks containing [[incidents]] link or tags:: incidents

4. Write the review block

Append to today's journal:

- ## Weekly Review — {start date} to {end date}
  - ### Wins (brags)
    - {bullet per brag with date}
  - ### Decisions made
    - {bullet per decision with date}
  - ### Meetings ({count})
    - {one line each: title + date + attendees}
  - ### Completed this week ({count})
    - {bullet per DONE TODO}
  - ### Still open ({count})
    - TODO {bullet per open TODO from past 7 days}
  - ### Incidents
    - {bullet per incident}

Skip empty sections. If there were no brags, don't add an empty "### Wins" section.

5. Add a reflection prompt at the bottom

  - ### Reflection
    - What went well: 
    - What didn't: 
    - Next week's focus: 

Leave these blank for the user to fill in. No markdown emphasis — notes don't need styling.

6. Note voice — notes, not docs

Extracted items stay in the user's own words (see Hard constraints). But anything you phrase yourself — meeting one-liners, section counts, gap notes — uses note voice: terse, personal, reader is future-you.

• State the point; no hand-holding phrases ("for the user", "in order to")
• No markdown emphasis (**bold**, *italic*)
• Bullet over 12 words? Try cutting half
• Plain language over code jargon — drop class/method names unless the line is meaningless without them; keep numeric thresholds
• Swaps: "implemented" → "added", "leveraged"/"utilized" → "used", "applies to" → "needs"

(Full version: logseq-note skill, "Notes are notes, not docs".)

Worked example

For a user reviewing Jun 12-18:

- ## Weekly Review — <start date> to <end date>
  - ### Wins (N)
    - <one-line brag>, pulled verbatim from the journal (<date>)
    - <one-line brag> (<date>)
  - ### Decisions made (N)
    - <one-line decision> (<date>)
  - ### Meetings (N)
    - <meeting type> × N
    - <one-off meeting> (<date>) — attendees
  - ### Completed this week (N)
    - <done TODO> (<date>)
  - ### Still open (N)
    - TODO <open item> (from <date>)
  - ### Reflection
    - What went well: 
    - What didn't: 
    - Next week's focus: 

Hard constraints

• Write to today's journal, not a separate page. Weekly reviews accumulate in journals — easy to find later.
• No fabrication. If the journal pages are empty, say so. Don't invent activity.
• Preserve dates. Every extracted item shows when it happened.
• Don't summarize subjectively. Surface the user's own words, not your interpretation.

Voice

No tool-call narration. No decorative tables or emoji. No long raw error-log dumps unless user asks. Standard tech acronyms OK (DB/API/MCP); never invent new abbreviations.

Abbreviate prose words (auth/config/req/res/fn/impl) — prose words only, never real code symbols or function names. Strip conjunctions; use arrows for causality (X → Y). One word when one word enough. Code symbols, function names, API names, error strings: never abbreviate.

No filler. No hedging. No "you", "your", "we". Keep sentences intact. Professional but tight.

Example

❌ "Sure! Let me help with your weekly review. I'll read your journal entries one by one using the get_page_content tool for each date."

✅ "Scanning Jun 25 – Jul 1. Found 3 brags, 2 decisions, 4 meetings. Writing review block."

Don't

• Don't write a separate "Weekly Review YYYY-MM-DD" page
• Don't include items from before the date range, even if they're related
• Don't auto-fill the reflection section — that's the user's job
• Don't tag the weekly review block with anything (it's already in the journal — discoverable by date)
• Don't include trivial items (single-word notes, half-written drafts)

Edge cases

• Empty week: tell the user "No journal entries found between X and Y. Skipping review." Don't write an empty block.
• Only one or two days of entries: still proceed, just note the gap.
• Open TODO from older than 7 days: skip it. This is a weekly review, not a TODO audit.
• Action items assigned to others (e.g. "(Bob)" when user is "Alice"): skip in "Still open" — only show the user's own.
• Old reviews accumulate. Review blocks aren't tagged, so they don't clutter hubs. But after months they add visual noise in journal pages. The user can collapse old review blocks in Logseq or occasionally archive/delete them.