Catch me up

Returning after time away, the problem is never a lack of information. It is 400 unread messages, 60 commits and 12 meetings, with no signal about which 5% changed anything.

This skill produces a brief that respects the reader's time: what changed, what needs them, what they can skip.

Inputs you need

Establish both before starting, and ask if either is missing:

1. Window — from when to when. "Last two weeks", "since Oct 3".
2. Scope — which project, repo, team or space. Without this you will produce noise.

Procedure

1. Decisions first, activity last

Open with what was decided, not what was done. Activity is cheap; decisions are what the reader must align to.

With a Wisprnote MCP server connected:

• list_meetings across the window to see the shape of what happened
• get_meeting_knowledge on each to pull decisions without reading whole transcripts
• list_action_items filtered to the reader's name — this becomes the "needs you" section

Otherwise: merged PRs with substantive descriptions, closed issues labelled decision or RFC, ADRs added under docs/, changelog entries.

2. Find direction changes

These matter more than anything else and are the easiest to miss. Look for:

• A decision that reverses an earlier one
• Work abandoned mid-flight — branches gone stale, issues closed as won't-fix
• Scope changes — things added to or cut from a release
• Ownership changes — someone left, someone took over

A reversal the reader doesn't know about will have them confidently doing the wrong thing within an hour of returning. Lead with these.

3. Find what is blocked on them

Anything where the reader is named as owner, reviewer, or approver, and the thing is still open. This is the only section that generates immediate action, so it must be accurate. Prefer under-reporting to a false "you're blocking X".

4. Write the brief

Keep it to one screen. If it runs longer, you have included activity instead of change.

# Catch-up: <scope>, <window>

## Changed direction  (read this first)
- <what changed, and what it means for work in flight>

## Decisions
- <decision> — <date>, <who> · <where it was decided>

## Blocked on you
- <item> — <who is waiting, since when>

## Worth knowing
- <2-5 items that don't need action but change your model of the project>

## Safe to skip
- <categories of noise, summarised in one line — not enumerated>

5. Offer depth, don't deliver it unasked

End by naming the two or three threads where a deeper read would pay off, and let the reader pick. Do not pre-emptively expand all of them.

Guardrails

• Never invent a decision. If the record is ambiguous, say "discussed, no decision recorded" — that is a real and useful state.
• Attribute carefully. Getting "who decided" wrong is worse than omitting it.
• "Safe to skip" is a summary, not a list. Enumerating noise recreates the problem.
• If the window contains nothing significant, say so in one line. A short honest brief is a good outcome, not a failed one.