catchup

分类: 开发与编程 | 上传者: tobyilee | 下载: 0 | 版本: v1.0（最新）

在新的 Claude Code 会话开始时使用此技能可以从上一个会话结束的地方继续。在 `.claude/reports/handoff/` 下找到最新的移交文档，读取它，然后根据实时代码库验证其声明（读取每个引用的文件，运行 `git status` / `git log --oneline`），然后报告结果并等待用户指令。将切换视为假设，而不是事实——之前的会话可能被混淆了。触发“赶上”、“赶上”、“继续工作”、“继续”、“从上一个会话继续”、“从交接处恢复”、“阅读交接”、“从参考交接开始”、“继续昨天的工作”、“从上次继续”、“准备新会话”、“准备继续”、“从我们上次停下的地方继续”、“赶上”。当用户通过引用之前的工作启动新会话时也会触发（“让我们继续我们昨天所做的事情”、“让我们继续”、“恢复身份验证重构”）并且项目中存在 `.claude/reports/handoff/` 目录。当用户想要开始一个全新的不相关的任务，或者当他们想要阅读特定的命名文档时（直接使用 Read），不要触发。

更新日志: Source: GitHub https://github.com/tobyilee/toby-plugins

目录结构

当前层级: tree/main/plugins/toby-essentials/skills/catchup/

📄 SKILL.md 7.2 KB

SKILL.md

---
name: catchup
description: >
  Use this skill at the START of a new Claude Code session to pick up where the previous
  session left off. Finds the most recent handoff document under
  `.claude/reports/handoff/`, reads it, then VERIFIES its claims against the live
  codebase (Read each referenced file, run `git status` / `git log --oneline`) before
  reporting findings and waiting for user instruction. Treats the handoff as a
  hypothesis, not fact — previous session may have been confused.
  Trigger on "catchup", "catch up", "이어서 작업", "이어서 해줘", "이전 세션 이어",
  "resume from handoff", "handoff 읽어", "handoff 참고해서 시작",
  "어제 작업 이어서", "지난번 이어서", "새 세션 준비", "prepare to continue",
  "pick up where we left off", "캐치업".
  Also trigger when the user starts a new session by referencing prior work ("어제 한
  작업 이어서 하자", "계속 하자", "resume the auth refactor") and an
  `.claude/reports/handoff/` directory exists in the project.
  Do NOT trigger when the user wants to start a brand-new unrelated task, or when
  they want to read a specific named document (use Read directly).
user-invocable: true
version: 0.1.0
---

# catchup

Resume a Claude Code session from the handoff document left by the previous session — but **verify before acting**. The core rule: a handoff document is a hypothesis. The previous session may have been under-caffeinated, confused, or wrong. This skill's job is to reconcile the handoff's claims with the current state of the code and git, report divergences, and then stop and wait for user instruction.

## Guiding rule

> Handoff is hypothesis, not fact.

If the handoff says "the retry path is scaffolded at `TokenService.kt:L45-L72`", do not trust that — Read the file and confirm. If the lines have shifted or the content disagrees with the claim, flag it in the report.

## Workflow

### Step 1: Locate the latest handoff

```bash
PROJECT_ROOT=$(git rev-parse --show-toplevel)
HANDOFF_DIR="${PROJECT_ROOT}/.claude/reports/handoff"

LATEST=$(ls -1t "${HANDOFF_DIR}"/handoff-*.md 2>/dev/null | head -1)
```

**If no handoff exists** (directory missing or empty): tell the user plainly:

> "No handoff document found under `.claude/reports/handoff/`. Either this is the first session, or the previous session didn't write one. Do you want to start fresh, or should I ignore catchup and wait for your instruction?"

Then stop. Do not invent context.

**If multiple handoffs exist:** the newest by mtime wins. Mention the age of the file in your report ("Handoff written 18 hours ago") — old handoffs are stale hypotheses, and the user should know.

### Step 2: Read in parallel

Read all of these in parallel (independent lookups):

- The handoff file itself (use Read tool — do NOT `cat`).
- Run `git status` to see uncommitted state.
- Run `git log --oneline -15` to see what has moved since the handoff was written.
- Run `git diff --stat` if there are uncommitted edits.
- Read `CLAUDE.md` at the project root if it exists — **but only to know what NOT to restate** in your report.

### Step 3: Verify every file reference

For each entry under "Relevant Files" in the handoff:

1. Use the Read tool to open the file at the cited line range.
2. Compare the actual content against the handoff's description.
3. Classify each reference:
   - ✅ **Confirmed** — file exists, content at cited lines matches the claim.
   - ⚠️ **Shifted** — file exists, but content has moved (line numbers differ or content changed).
   - ❌ **Missing** — file or referenced symbol no longer exists.
   - ❓ **Ambiguous** — reference is too vague to verify (flag this as a handoff-quality issue).

Do this in parallel when there are 2+ files to check.

### Step 4: Cross-check git state

Compare the handoff's claims against git:

- "Open Work" says X is "not yet implemented" — is X now in git log? (previous session may have finished it in a last commit.)
- Any commits exist after the handoff's timestamp? Those are changes the handoff doesn't know about.
- Any uncommitted edits — these are probably what the previous session was mid-writing when it ended.

### Step 5: Report to the user — then stop

Produce a verification report with this structure (use plain markdown, do NOT restate CLAUDE.md content):

```markdown
## Catchup Report

**Handoff source:** `.claude/reports/handoff/handoff-<timestamp>.md` (written {N} hours ago)
**Previous session summary:** {1–2 lines quoted from the handoff's Summary section}

### Verification of referenced files
- ✅ `src/auth/TokenService.kt:L45-L72` — matches handoff description.
- ⚠️ `src/auth/OAuthClient.kt:L10-L30` — file exists but refresh method has moved to L44-L66 since the handoff was written.
- ❌ `src/auth/BackoffUtil.kt` — file not found; handoff may be stale or this was an unfulfilled plan.

### Git movement since handoff
- {N} new commits since handoff timestamp: {list `--oneline`}
- Uncommitted changes: {file list from `git diff --stat`, or "none"}

### Open Work reconciled against current state
- {Item from handoff} — still matches / now done / divergent (explain).
- ...

### Traps to Avoid (carried forward from handoff)
- {List verbatim — these failed-approach warnings are the handoff's highest-value content.}

### What I am NOT doing
I'm treating this handoff as a hypothesis, not a work order. I've verified the above and I am now waiting for your instructions before touching anything. Tell me what you want to work on.
```

Then **stop**. Do not start implementing. Do not propose a next action unless the user asks. The whole point of the skill is to restore situational awareness, not to auto-resume work from stale notes.

## Notes

- **`/clear` followed by catchup is the canonical resume pattern.** The previous session runs `handoff` just before exiting; the new session starts, the user runs `/catchup` (or this skill auto-triggers), and the fresh context gets a compact hypothesis-style brief from the handoff plus a verification pass. Total token cost: a few thousand, vs. rebuilding the whole context from scratch.
- **If the handoff is older than a few days**, say so in the report. Stale handoffs are more hypothesis-y — the code has drifted further from the handoff's snapshot, and more references are likely to have shifted.
- **Do not merge multiple handoffs.** If the user has two recent handoffs (e.g. one from yesterday evening, one from this morning on a quick spike), catchup uses the newest only and mentions the existence of older ones. The user can ask to cross-reference explicitly.
- **Symmetry with `handoff`.** The two skills are paired: `handoff` writes the artifact `catchup` consumes. If you find yourself wanting to write something in handoff that catchup couldn't meaningfully verify, that's a smell — lean on concrete file:line references instead of abstract descriptions.

## Background

This skill operationalizes the verification side of the "Document & Clear" pattern (Tier 2 of the handoff strategy in `claude-session-context-handoff-4-layer-strategy.md`). The reference article's core insight — that handoffs must be treated as hypothesis, not fact — is enforced structurally here: the skill physically cannot skip the verification step, because reporting requires the verification output.

登录后下载/点赞/收藏 ❤ 18 | ★ 0

catchup

目录结构

SKILL.md

举报内容

提示