Pick up where you left off — sessions, logs, and Claude in parallel

What you’ll know by the end of this check

• The three resume paths Claude Code ships with — which one to reach for when
• Why Claude Code out of the box only solves half the problem — and what you have to build on top
• How one session becomes 3-5 parallel sessions without collisions (the git worktree trick)
• A starter kit you can install in 30 seconds to skip the boilerplate

The shortest possible answer

Every Claude session is its own brain. Close the terminal and that brain is gone.

Claude Code’s built-in flags let you reopen a conversation, but they don’t preserve the handoff — the short briefing that tells future-you (or future-Claude) what was decided, what’s in flight, and what to do first. That handoff is an artifact you build yourself.

Once you have the artifact, one session becomes N sessions. That’s where the leverage is.

Part 1 — What Claude Code ships with

No setup required. Everything in this section works in a fresh install.

Three ways to reopen a conversation

You can also run /rename <name> inside a running session to set its display name retroactively. Stock Claude Code builtin — no plugin needed.

Related flags worth knowing:

• --fork-session — when resuming, create a new session ID instead of continuing the original. Good for branching a conversation into two directions.
• --from-pr <n> — resume a session tied to a specific PR.

Run claude --help to see the whole list. These flags are the full extent of what Claude Code solves for you out of the box.

Worktrees for parallel work

This is stock git, not Claude — but it’s the bit that makes parallel Claude sessions actually safe.

# from your project root
git worktree add .worktrees/update-ha -b feat/update-ha main
git worktree add .worktrees/write-doc -b docs/write-doc main

One checkout, multiple working directories, each on its own branch. Two Claude sessions in the same folder trying to commit = race condition. Two Claude sessions in two worktrees = zero conflict.

git worktree list shows what you’ve got open. git worktree remove <path> cleans up. Nothing Claude-specific about this — just the right shape for operating multiple sessions.

What the built-ins don’t solve

Reopen ≠ re-orient. When you run claude --resume, you get the message history back, but there’s no structured “here’s what was decided” block at the top. The session walks back into the room wearing the exact same mental state it had when you left — which is often lost in the middle of a messy in-progress thought.

That’s what the pattern in Part 2 fixes.

Part 2 — The pattern you build on top

This section describes the artifact (session log) and the skill that writes it. Neither ships with Claude Code. You either build them yourself or install the starter kit in Part 3.

The artifact: a session log

A markdown file you write at the end of a work session. Conventional location is log/ at the project root, but anywhere stable works — what matters is that it’s in version control and easy to find.

Filename pattern: <date>-<short-slug>.md. E.g. 2026-04-19-oauth-refactor.md.

The shape that’s worth the discipline:

---
title: "Session: oauth refactor"
date: 2026-04-19
branch: feat/oauth-refactor
resume: "claude --resume oauth-refactor"
---

## What happened
Two to three sentences. State at the end.

## Files changed
- path/to/file.ts — one-line what-changed
- ...

## Improvement suggestions
- What was slow?
- What got repeated that could be automated?
- What worked and should be kept?

## Next Session Prompt

> Copy-paste this to start your next Claude Code session:

\`\`\`
Hey Claude — resuming from <session-name>.

Read these first:
1. log/2026-04-19-oauth-refactor.md
2. src/auth/oauth-client.ts

State at end: per-client OAuth done, tests green, PR not opened.
Next up: open the PR, then migrate the fourth call site.
\`\`\`

The Next Session Prompt is the whole ball game. Three days later you open a fresh terminal, paste it, and future-Claude re-orients in seconds instead of re-exploring from cold.

The skill: /log-session

/log-session is a custom slash command that writes the log file for you at the end of a session — so you don’t have to hand-type the frontmatter every time. It’s not built into Claude Code; you add it to ~/.claude/commands/log-session.md and Claude picks it up on next session start.

Writing your own is ~80 lines of markdown describing the steps. Or skip the boilerplate with Part 3.

The compounding loop

Every log’s Improvement suggestions section quietly compounds your workflow over time. “This was slow because I had to retype X” → next week you build a skill that does X. Logs don’t have to be fancy. They have to be written.

Part 3 — The starter kit

A public GitHub repo with generic versions of these skills. Install in 30 seconds:

git clone https://github.com/scottd3v/crackedpm-skills ~/dev/crackedpm-skills
mkdir -p ~/.claude/commands
cp -i ~/dev/crackedpm-skills/commands/*.md ~/.claude/commands/

Open Claude Code, type /, and /log-session shows up in the picker. No vault assumptions, no knowledge-base tooling — just the skill.

The repo is at github.com/scottd3v/crackedpm-skills. Fork it if you want to customize, symlink it if you want git pull to roll updates in.

Parallel sessions: when one brain isn’t enough

Once the log pattern is in place, one session becomes N sessions. Say you’ve got four workstreams:

• A PR to review
• A spike to run
• A doc to write
• A long build to babysit

You don’t want them in one session. Context bleed makes decisions worse; a single /clear wipes everything. You want four terminals. Four Claude sessions. One project.

The worktree trick from Part 1 is the structural fix. The coordination layer is what turns four Claudes from a mob into a team.

Three pieces of the coordination layer

None of this is Claude-specific. It’s the same pattern a small team uses — except your “team” is 3-5 parallel Claude sessions you’re driving yourself.

The staleness failure mode

Logs decay. A log written in October and never opened since lives in a different architectural reality than today. When you resume from a stale log, the first thing Claude does is re-explore, notice drift, and often propose “cleanup” you didn’t ask for.

Prevention: don’t resume from logs older than two weeks. If the work matters two weeks later, open a fresh session with a one-paragraph brief and let Claude re-scan from scratch. Old logs are a record, not a time machine.

Try this right now (10 minutes)

1. Install the starter kit from Part 3 (30 seconds).
2. In any project, run a short Claude session — ask for one small thing, let Claude do it.
3. Before closing, run /rename today-experiment to name the session.
4. Run /log-session to write the log. Look at what it produced in log/.
5. Close the terminal.
6. Open a fresh terminal in the same project. Try all three resume paths:
   • claude --continue → drops you back in the most recent conversation.
   • claude --resume today-experiment → finds it in the picker.
   • claude (fresh), then paste the Next Session Prompt from the log file.

Each one puts you back in the same headspace by a different route. You’ll pick the right one by feel after a few days — but the third one is the most durable. It survives branch switches, laptop reboots, and weeks of elapsed time.

The canonical version

• claude --help — every flag, including --continue, --resume, --name, --fork-session, --from-pr.
• git worktree --help — the worktree reference. git worktree list + git worktree remove <path> are the two commands you’ll actually use.
• github.com/scottd3v/crackedpm-skills — the starter kit referenced in Part 3.
• Your project’s CLAUDE.md — where you tune the log location, naming, and commit behavior to taste.