Menu
Scan recent Claude Code sessions and classify unfinished work for resuming
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | restore-sessions |
| description | Scan recent Claude Code sessions and classify unfinished work for resuming |
| disable-model-invocation | true |
Find and classify Claude Code sessions from a project's session directory. Produces a comprehensive table of sessions with completion status, so the user can quickly identify unfinished work.
claude --resume <id>)Claude Code stores sessions as .jsonl files in:
~/.claude/projects/<project-path-with-dashes>/*.jsonl
Subagent sessions live in subdirectories (<session-id>/subagents/) — these are excluded (they belong to their parent session).
Determine the correct project path from the current working directory. The path encoding replaces / with - and strips the leading slash. Example: /home/max/repos/code/yapit → -home-max-repos-code-yapit.
uv run python <skill-dir>/scripts/scan_sessions.py <sessions_dir> --days <N> --exclude <current_session_id>
IMPORTANT: Always pass --exclude with the current session's ID. The user is invoking this skill from the current session, so any text they pasted as search context will appear in the current session's jsonl — matching it is useless and confusing. To get the current session ID, use the most recently modified .jsonl file in the sessions directory: ls -t <sessions_dir>/*.jsonl | head -1 and extract the stem. The current (active) session is always the most recently written file.
Arguments:
--days N — only sessions modified within the last N days--sessions N — only the N most recent sessions (by modification time)--exclude ID — exclude a session by ID (repeatable). Always exclude the current session.Both filters can be combined. If the user specifies "last 100 sessions or last 10 days, whichever is greater," run with --days 10 first, then check if the count is under 100 — if so, run again with --sessions 100.
The script outputs a JSON array of session objects (newest first), each containing:
session_id, modified, size_kbuser_msgs_total, user_msgs_substantive — total vs. non-meta/non-system user messagessignals.commit, signals.transcribe, signals.handoff — boolean completion indicatorsinterrupted — whether the last user message was a request interruptionfirst_user — first substantive user message (cleaned of command tags)last_user — last substantive user messagelast_assistant — last assistant message with >20 charsFor each session, assign one of these statuses:
DONE — Clear completion signal AND last messages confirm it:
/mx:todos, /mx:recap, or other info-only commands that completedJUNK — Not worth showing:
/test, /context, /clear, /model, /rename commandsUNFINISHED — Everything else. This is the default — be inclusive. When in doubt, mark as unfinished. Specifically:
interrupted: true (crash/abort mid-work)Key judgment calls:
signals.commit: true but still be UNFINISHED if work continued after the commit. Check last_assistant — does it reference the commit as final, or is there subsequent work?/mx:transcript ARE done (the transcript captures the state for later).Output a single table containing ALL non-junk sessions (both DONE and UNFINISHED), sorted newest-first.
| # | Session ID | Topic | Date | Status | Notes |
|---|-----------|-------|------|--------|-------|
Column guidelines:
claude --resume <id>)first_user. Strip command prefixes (mx:task, /mx:task, etc.)modified, just date + time (e.g., "Feb 6 01:55")Present the FULL table first, then optionally add a brief summary section highlighting the most urgent items (sessions from the last 1-3 days that are clearly unfinished).
The user may ask to:
claude --resume <session_id>.jsonl file's last ~10 messagesWork a feature's ticket DAG in parallel — one orchestrator fans independent frontier tickets out to parallel worker agents and integrates them on the feature branch until the feature ships. Use when a ticketed feature has independent frontier tickets, the user says "dispatch" or wants tickets worked in parallel, or when another skill routes parallel frontier work here.
Which mx skill or flow fits the current situation — a router over the mx workflow.
Run commands in tmux whenever they run long or need eyes on them — anything expected to take more than ~30–60s (training runs, ML experiments, builds, servers), anything worth observing mid-run (progress logs, monitoring output), and anything interactive (sudo prompts, REPLs, wizards), locally or on a remote host. Always reach for this instead of a fire-and-forget Bash call in those cases — the human can attach and step in at any time.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published per the tracker conventions — ticket files with blocked-by edges, or native blocking links on a real tracker.
Review and update Claude Code's auto-approved command allowlist based on Bash commands that triggered permission prompts in recent sessions.
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.