weekly-review

---
name: weekly-review
description: >
  Run the weekly review and roll the sprint. Trigger on "run my weekly review", "weekly review", "weekly retro", "roll the sprint", "what happened this week", "plan next week", "Friday review", "Monday planning", "weekly planning", "sprint review", or any reference to reviewing the past week or planning the next one. Also fires on user-vocabulary equivalents: "my schedule", "my schedule is stale", "this week's plan", "what am I working on this week", "show me this week", "what's on for this week" - the weekly commitments file is the operator's schedule. Also fires on Fridays when the user opens a session in the Founder OS root.
why: "Keeps the sprint honest by forcing a decision on stalled items instead of letting them roll week to week - the pattern block names avoidance directly."
enhance: "Fill brain/log.md throughout the week with real events - the retro reads from this directly, so more entries means a sharper pattern read and a more honest retro."
allowed-tools: ["Read", "Write", "Edit", "Bash", "Glob"]
mcp_requirements: []
---

# Weekly Review - Sprint Roll and Retro

Runs on: local-writes - creates or edits files in your OS folder; needs an agent with write access.

Two modes: retro (look back) and planning (look forward). Usually both in one session.

## Step 0: Identity gate

Before producing output, run: `python scripts/check-identity-ready.py`

If exit code is 1, read the output line and surface it to the user verbatim. Do not run the retro or planning blocks. Stop.

## Step 1: Read Current State

Read these files silently:
- `cadence/weekly-commitments.md` - the current sprint
- `context/priorities.md` - broader goals
- `brain/log.md` - what actually happened this week
- `brain/flags.md` - any stalls or friction
- `cadence/daily-anchors.md` - what the daily work looked like

## Brain context (default)

Before producing output, read `brain/.snapshot.md`. If it is missing, or its `date:` line is more than 3 days old, run `python scripts/brain-snapshot.py --write` first and read the fresh one - a stale snapshot read as current presents last week's flags and must-dos as today's, which is worse than no memory at all. If Python is unavailable, proceed without it and say so.

If the snapshot is missing, or its `date:` line is more than 3 days old, run:

    python scripts/brain-snapshot.py --write

Then read it. If the snapshot script is also missing (older install), proceed using only the profile files. Do not block.

The snapshot tells you what flags are open, what the user is working on this week, and what the latest staleness state is. Apply this context to your output where it is relevant. Do not surface every snapshot field in every output - use judgment. For the weekly review, open flags that have stayed open across multiple weeks are themselves the retro finding, and staleness in the cadence files is the headline of the planning block.

## Step 2: Retro

Build a retro from the data:

```
WEEK OF [date range] - RETRO

WHAT GOT DONE
- [Item]: [outcome]
- [Item]: [outcome]

WHAT SLIPPED
- [Item]: [why it didn't happen]
- [Item]: [why]

PATTERN
[One sentence. What does the pattern of done vs. slipped tell you?
Example: "Delivery work gets done. Sales work doesn't. Building is comfortable. Selling is not."]

COMMITMENTS CHECK
| Commitment | To | Status | Change? |
|------------|-----|--------|---------|
```

Present this to the user. Ask: "Anything to add or correct before I roll the sprint?"

## Step 3: Flag Check

Check for items that have rolled 2+ weeks without progress. These need a decision:
- **Kill it** - it's not actually important, remove it
- **Escalate** - move it to Must Do with a specific deliverable
- **Redefine** - the task is too vague, break it into something concrete

Present rolled items and ask which treatment each gets.

## Step 3.4: Identity review (only if `context/entities/` exists)

Run `python scripts/entity_check.py`. It is read-only and it reports three things:

- **Overdue identity reviews.** An entity whose `reviewed:` date is 60+ days old that has real dated touches since. You kept working with them while the written read of them was never confirmed. Each takes one of three outcomes: **confirmed** (re-stamp `reviewed:` with today), **corrected** (edit `profile.md`, append the correction to `log.md`, re-stamp), or **archived** (`status: archived`; it stops being surfaced and stays readable). An entity that simply went quiet is not surfaced, because dormancy is not debt.
- **Promotion candidates.** A single file that outgrew itself. Propose the folder shape (`profile.md` / `log.md` / `sources/`) and let the operator approve. Never promote unasked.
- **Shape drift.** A folder missing `profile.md` or `log.md`, or an entity with no `reviewed:` date.

Convention and thresholds: `rules/entity-folders.md`. Nothing due means say nothing - a quiet report is not a finding.

## Step 3.5: Grade the team (only if `roles/employees.yaml` exists)

The weekly retro is where the digital-employee record gets read, or it never gets read at all. Run `python scripts/employee_verdict.py render` and read `brain/employees.md`:

- Any row showing REVIEW DUE: tell the operator plainly and point at `/founder-os:employee-review <id>`. Do not run the review inside the retro.
- Any seat that ran this week with no verdict recorded: ask for the one-line verdict now ("ok, needs work, or failed - and why"), and say it goes into the verdict record (`brain/employee-verdicts.jsonl`), so the answer is the yes for that file. Record it the way the morning loop does, with their line in a quoted block (`skills/morning-loop/SKILL.md` Step 3). One line per seat, never a form.
- Nothing ran and nothing is due: say nothing. A quiet chart is not a finding.

## Step 4: Plan Next Week

Ask: "What are the MUST DOs for next week? Max 3. What must be done by Friday no matter what?"

Then ask for SHOULD DOs and COULD DOs.

Build the new sprint:

```
WEEK OF [date range]

MUST DO (non-negotiable - max 3)
1. [Task]
2. [Task]
3. [Task]

SHOULD DO (important but can shift)
1. [Task]
2. [Task]

COULD DO (if time opens up)
1. [Task]

WAITING ON
- [Item]: [who/what]
```

## Step 4.5: Queue Rolloff and Stuck-Item Review

Before writing the new sprint, read `cadence/queue.md` if it exists.

1. **DONE rolloff.** For every entry in the DONE section with a date older than 7 days,
   note it for removal. Step 5 appends its one-line summary to `brain/log.md` (use the
   `#acted` channel) and removes it from `cadence/queue.md`, on the yes. Keep entries from
   the last 7 days in DONE.

2. **Stuck ACTIVE items.** For every entry in the ACTIVE section with a date older than
   14 days, surface it inline:
   "This item has been ACTIVE for N days - is it actually moving, or does it need to
   go back to BACKLOG?"
   Wait for the user's answer before proceeding. Move to BACKLOG if they say park or
   no longer moving.

If `cadence/queue.md` does not exist, skip this step silently.

## Step 5: Update Files

Before writing, name every file this roll will change and wait for one yes. A yes to
"roll the sprint" covers only what you named. Name `cadence/weekly-commitments.md` (the
retro and the new sprint), `context/priorities.md` (the This Week section), and only where
the steps above found something: `brain/flags.md` (the flags resolved, named),
`cadence/queue.md` (the DONE entries rolled off and the items moved), and each
`context/entities/<name>/profile.md` an identity review re-stamps or corrects. Ask:
`Write these? (yes / no / pick which)`. Write only what the yes covers. The `brain/log.md`
entries are automatic.

1. Write the retro into `cadence/weekly-commitments.md` (above the new sprint)
2. Update `context/priorities.md` This Week section
3. Update `brain/log.md` with a `#acted` entry noting the sprint roll
4. If any flags were resolved, update `brain/flags.md`
5. Apply any queue changes from Step 4.5 to `cadence/queue.md`
6. With version history on, save the rolled week as one version: "Weekly review: roll sprint to Week of [date]". Without it, the files above are already on disk and there is nothing more to do.

## Marketing / Sales / Delivery Balance Check

Skip this check if `core/identity.md` has `role: operator` or `role: team_of_one`, or if prose indicates they are not the business owner (phrases like "I report to", "I'm not the founder", "ops manager", "operations manager", "team member"). Check the `role:` field first; fall back to the phrase scan only if the field is absent. The check is for business owners who own both the delivery and the sales function. Applying it to an ops-not-founder user would incorrectly flag their work as "too much delivery."

If the founder has no paying clients yet, run this check:
- Look at the retro: categorize completed work as Marketing (content, brand), Sales (outreach, pipeline, meetings with prospects), or Delivery (building, internal systems, client work)
- Target ratio with no revenue: roughly 20% Marketing / 50% Sales / 30% Delivery
- If Delivery is dominating and Sales is under 40%, flag it: "You're building when you should be selling."

## Rules

- Be honest about what slipped. Don't soften it.
- Name the pattern. Founders often can't see their own avoidance patterns.
- Keep the sprint tight. Three Must Dos is plenty. More than that is a wish list.
- If something has rolled 3+ weeks, recommend killing it unless the user defends it.

<!-- private-tag: not applicable: writes structured sprint summary to brain/log.md; not user-provided speech content -->