Weekly retro

Weekly retro

Invocation: user only. Produces a retrospective draft; never auto-publishes or auto-posts.

When to use

Weekly or biweekly. The output is for the team to read together or async. It's a mirror — not a report for stakeholders. Use /role-pgm:status-report for upward reporting.

Rules that make this useful

• Praise anchored in specific work. Never "great job everyone." Name the person, name the thing.
• Growth areas anchored in evidence. Never criticize without pointing at a specific pattern or artifact.
• Themes, not lists. A retro that's a bulleted inventory is a status report in a wig. Pull out patterns: what repeated? what surprised? what got harder or easier?
• Honesty over comfort. If the week was slow, say so. If a project is drifting, name it. A retro that hides problems is worse than no retro.
• One page or less. If it's longer, you didn't filter.

Workflow

1. Scope the window

Parse $ARGUMENTS:

• default: last 7 days (midnight-aligned, local timezone)
• 14d, 30d: longer windows
• compare: compare the current window to the prior same-length window
• or an explicit date range

2. Pull (in parallel)

• Notion: pages in project spaces updated or created in the window. Specs moved to "shipped". Decisions added. Retros from last window if they exist.
• Slack: the team's #ship and main project channels. Messages in the window with high reaction counts or deep reply threads — those are usually signal.
• GitHub (if MCP is enabled): PRs merged to main in the window, by author, with sizes. PRs still open >3 days.
• Fathom: meetings the team had in the window — specifically retros, project check-ins, or customer calls with themes.
• Calendar: what the team spent time on (meetings per person, cross-team time, focus time).
• Risk log: risks that changed state in the window (newly opened, escalated, mitigated).

If GitHub MCP isn't enabled, skip it — don't fabricate PR data.

3. Classify by person

Build a per-contributor picture. For each teammate:

• What they shipped — 1-3 concrete outcomes (not "worked on X", but "shipped X" with evidence)
• Where they focused — top 1-2 areas (project, domain, codebase section)
• Praise signal — one specific thing that stood out. Anchored in a PR, a spec, a decision they drove, a meeting they ran. No generic "great work."
• Growth signal — one specific pattern worth naming. Framed as leveling-up, not criticism. Anchored in evidence. Only include if there's genuine signal; no need to manufacture a growth area for every person every week.

Skip the per-person section if the team is solo or if there aren't enough distinct contributors to merit it.

4. Classify by theme

Pull 2-4 themes across the window. These are the patterns, not the items. Good themes:

• "Shipping slowed on Project A, accelerated on Project B — customer meetings in the window shifted priorities mid-week"
• "Three hotfixes traced back to the same auth module — worth a dedicated review"
• "Design spent most of this window unblocking eng reviews, not generating new work — is that the right allocation?"

Bad themes (too generic):

• "The team worked hard"
• "We made progress on several fronts"
• "Communication could be better"

5. Trends (if comparing)

If compare or if a prior retro exists in Notion, show deltas:

                     Last    Now     Delta
Shipped items          7       5     ↓2
Open blockers          2       4     ↑2
Risks at High          1       1     →
PRs opened            14      18     ↑29%
Cross-team meetings    6       9     ↑3

Pick 4-6 metrics that actually move the needle for this team. Don't invent metrics you can't measure. If it's the first retro, skip this section and note "first recorded — compare next week."

6. Output

# Retro — <date range>

**TL;DR** <one sentence. The honest signal of the week. Good, bad, or flat.>

## By the numbers (optional, only if meaningful)
<4-6 line summary — shipped, blocked, risks, PRs, hotspots — only what's genuinely worth tracking for this team>

## Themes
- <theme> — <1-2 lines with specific evidence>
- <theme>
- <theme>

## Per person
**<Name>** — focused on <areas>
  - Shipped: <1-3 specific outcomes>
  - Praise: <specific thing, anchored in an artifact>
  - Growth: <specific pattern if present>

<repeat per teammate>

## Top wins
- <3 specific wins, each with a link>

## Things to improve next window
- <3 specific, actionable items. Not "improve communication." "Stand up a 15-min mid-week sync for Project X until we unblock the design review queue." Anchor each in what happened this window.>

## Habits to try
- <2-3 small, realistic habits — each <5 min per day to adopt — that the team can trial next window>

## Open decisions / asks
- <anything the team needs a call on>

7. Review and (maybe) publish

Show the draft. Common edits:

• Tone down / tone up specific praise or growth notes per the user's sense of the person
• Add a theme you missed, drop one that's off
• Correct factual errors

On approval, ask where it goes. Default options:

• Notion retros page (create page at the team's retros path)
• Slack: post TL;DR + link to Notion
• Both

Never publish or post until the user explicitly approves the destination.

Don't

• Don't infer emotions or intentions. Report observations, let the reader interpret.
• Don't list every PR merged. Retro is signal, not activity log.
• Don't duplicate the status report. If the PgM also publishes a status report this week, cross-reference it — don't restate.
• Don't "rank" people or compare them side by side. Per-person is descriptive, not competitive.
• Don't include a growth area just because every person "should" have one. Only include if there's real signal.