Research & Context

/catchup

Use when returning to work after any break — auto-detects depth. Short break (hours): reads only uncommitted changes. Long break (48h+) or context overflow: reads all branch changes vs main. Covers catchup, context recovery, refresh, rebuild understanding. NOT for: mid-task exploration (use Read/Grep directly).

$ golems-cli skills install catchup

Good

90% best pass rate

10 assertions

3 evals

Updated 2 weeks ago

Auto-detects break length and adjusts depth. Short break = uncommitted changes only. Long break = full branch diff vs main.

When to Use

Returning after ANY break (hours or days)
Context window overflow — need to rebuild understanding
Before committing — review what's staged
Reviewing what's been done on a feature branch

Auto-Detect Mode

Check both signals to pick the right mode:

# 1. Check uncommitted changes
git status --short
 
# 2. Check branch commit count
git log --oneline main...HEAD 2>/dev/null | wc -l

Uncommitted changes?	Branch commits?	Mode
Yes	Few (0-3)	Quick — read uncommitted only
No	Many (4+)	Full — read all branch changes
Yes	Many (4+)	Full — read everything
No	None	Nothing to catch up on

User can override: /catchup quick or /catchup full

Quick Mode (short break, uncommitted changes)

Step 1: Get Status

git status --short

Status codes:

M — Modified (staged)
M — Modified (unstaged)
MM — Modified (both)
A — Added (staged)
?? — Untracked

Step 2: Read Modified Files

Read only files with M status. Skip untracked (??) unless relevant.

Step 3: Quick Summary

Files currently being edited
What changes are in progress
Ready to continue or need clarification

Full SKILL.md source — includes LLM directives, anti-patterns, and technical instructions stripped from the Overview tab.

Auto-detects break length and adjusts depth. Short break = uncommitted changes only. Long break = full branch diff vs main.

When to Use

Returning after ANY break (hours or days)
Context window overflow — need to rebuild understanding
Before committing — review what's staged
Reviewing what's been done on a feature branch

Auto-Detect Mode

Check both signals to pick the right mode:

# 1. Check uncommitted changes
git status --short
 
# 2. Check branch commit count
git log --oneline main...HEAD 2>/dev/null | wc -l

Uncommitted changes?	Branch commits?	Mode
Yes	Few (0-3)	Quick — read uncommitted only
No	Many (4+)	Full — read all branch changes
Yes	Many (4+)	Full — read everything
No	None	Nothing to catch up on

User can override: /catchup quick or /catchup full

Quick Mode (short break, uncommitted changes)

Step 1: Get Status

git status --short

Status codes:

M — Modified (staged)
M — Modified (unstaged)
MM — Modified (both)
A — Added (staged)
?? — Untracked

Step 2: Read Modified Files

Read only files with M status. Skip untracked (??) unless relevant.

Step 3: Quick Summary

Files currently being edited
What changes are in progress
Ready to continue or need clarification

Full Mode (long break, full branch context)

Step 1: Get Changed Files

git diff --name-only main...HEAD

Step 2: Read All Changed Files

Read in dependency order:

Schema/database files (schema.ts, convex/, prisma/)
Config files (package.json, tsconfig.json, .env.example)
Server/API files (actions/, api/, server/)
Components/UI files (components/, app/)
Tests (tests/, *.test.ts)

Step 3: Full Summary

What feature/fix is being worked on
Current state of implementation
What appears to be left to do

Tips

If full mode shows 50+ files, start with quick mode first
Check git log main...HEAD --oneline for commit history context
Look for TODO/FIXME comments to understand remaining work
Combine with git diff to see actual line changes

Good

Best Pass Rate

90%

Opus 4.6

Assertions

3 models tested

Avg Cost / Run

$0.1821

across models

Fastest (p50)

3.7s

Haiku 4.5

Behavior Evals

Phase 2 baseline — skill quality on Claude

Behavior Baseline

Opus 4.6

90%9/10

●

Sonnet 4.6

90%9/10

●

Haiku 4.5

60%6/10

◓

Assertion	Opus 4.6	Sonnet 4.6	Haiku 4.5	Consensus
auto-detects-mode				2/3
reads-relevant-files				3/3
provides-summary				3/3
uses-full-mode				2/3
reads-in-dependency-order				2/3
checks-commit-history				3/3
identifies-remaining-work				2/3
uses-quick-mode				2/3
reads-only-modified				3/3
brief-summary				2/3

Token Usage

Opus 4.6

10,745

Sonnet 4.6

11,306

Haiku 4.5

6,144

Input tokensOutput tokens

Cost per Run

Opus 4.6

$0.4308

Sonnet 4.6

$0.1109

Haiku 4.5

$0.0047

Model	Input Tokens	Output Tokens	Cost / Run	Cost / 1K Runs
Opus 4.6	6,252	4,493	$0.4308	$430.80
Sonnet 4.6	4,894	6,412	$0.1109	$110.90
Haiku 4.5	3,023	3,121	$0.0047	$4.70

Response Time (p50)

Haiku 4.5

3.7s

Opus 4.6

4.6s

Sonnet 4.6

5.3s

Response Time (p95)

Haiku 4.5

5.8s

Opus 4.6

8.8s

Sonnet 4.6

10.2s

Model	p50	p95	Overhead
Opus 4.6	4.6s	8.8s	+91%
Sonnet 4.6	5.3s	10.2s	+91%
Haiku 4.5	3.7s	5.8s	+57%

Last evaluated: 2026-03-12 · Data is generated from skill assertions (real cross-model benchmarks coming soon)