You close your Claude Code session at 6 PM. You open it back up the next morning. And the first thing you type is a three-paragraph explanation of what you were doing yesterday.
Sound familiar?
The Problem Nobody Talks About
Claude Code is one of the most capable AI coding assistants available. It can write whole modules, refactor complex systems, and reason through architecture decisions. But it has a blind spot that costs developers real time every single day: it forgets everything between sessions.
This isn't a bug. It's how the tool works. Claude Code operates in isolated sessions. There is no persistent project memory. No state carried over. When you start a new session, Claude sees your codebase, your CLAUDE.md if you have one, and nothing else. It doesn't know what you were working on, what state your feature is in, which tests were passing, what your acceptance criteria are, or what you decided in the last three sessions.
For a one-off script, this is fine. For sustained product development across days or weeks, it's a serious friction point. You end up repeating yourself. You correct Claude when it makes wrong assumptions. You re-explain decisions you already made. And every interruption — lunch break, meeting, end of day — resets the clock.
What Manual Solutions Look Like (and Where They Break)
The most common workaround is a well-crafted CLAUDE.md file. You write down your project structure, conventions, current goals, maybe a list of TODOs. Some developers keep a separate notes file that they paste into the conversation at the start of each session. Others manually update a "project status" section after each work block.
These approaches help — up to a point. They cover the static parts: "this is a TypeScript project, we use Vitest, here are the coding conventions." But they fail at the dynamic parts:
- What's in progress right now? A
CLAUDE.mddoesn't update itself. By your third session, the "current work" section is stale. - What are the acceptance criteria for this feature? You wrote them down somewhere, but did you paste them into the context? Probably not.
- What's the quality gate status? Did the last session's tests pass? Were there lint issues? What about the intent check — does the code match what you originally planned? Manual notes don't capture this.
- What changed since last time? If you or someone else pushed commits between sessions, your manual context is now out of sync with reality.
The fundamental issue is maintenance. Keeping manual context accurate requires effort proportional to your project's complexity. And the whole point of using an AI coding assistant is to reduce effort, not create new bookkeeping tasks.
What Happens When Context Is Actually Maintained
I built devpace, a Claude Code plugin, partly to solve this problem. The core idea is simple: maintain project state as plain Markdown files in a .devpace/ directory, and have Claude read them automatically at every session start.
But instead of just claiming it works, let me show you numbers from an actual comparison test.
The Test Setup
I took the same project and ran it through three deliberate interruption points — simulating a developer closing their laptop, taking a call, switching projects, and coming back. I ran this twice: once with devpace managing the state, once with a manually maintained CLAUDE.md.
At each interruption recovery, I counted how many times I had to correct Claude's understanding of the project state. A "correction" means Claude either assumed something wrong, forgot something important, or started working in the wrong direction.
The Results
devpace: 0 user corrections across 3 interruption points.
Manual approach: 8 user corrections across 3 interruption points.
Eight times I had to stop Claude and say "no, that's not where we were" or "we already decided against that approach" or "the acceptance criteria require X, not Y."
But the raw correction count only tells part of the story. I also ran a 7-dimension analysis comparing what each approach actually preserved across sessions:
| Dimension | devpace (auto) | Manual CLAUDE.md |
|---|---|---|
| D1: Current work status | Pass | Pass |
| D2: Feature context (what and why) | Pass | Pass |
| D3: Acceptance criteria state | Pass | Fail |
| D4: Quality gate status | Pass | Fail |
| D5: Decision history | Pass | Partial |
| D6: Dependency/blocker state | Pass | Partial |
| D7: Next step recommendation | Pass | Fail |
devpace scored 21/21. Manual scored 7/21.
The critical gap is D3 and D4. Acceptance criteria and quality gate state are completely uncovered by manual approaches. No developer is going to manually write "Gate 1 passed, Gate 2 pending, lint passed on 14 files, type check failed on auth.ts line 42" in their CLAUDE.md after every session. It's too granular, too tedious, and too easy to forget. But that's exactly the information Claude needs to resume work without false starts.
How devpace Does It
devpace is a Claude Code plugin with 18 skills, 11 automated hooks, and 3 specialized sub-agents. But for cross-session continuity, only a few pieces matter:
Two Work Modes
devpace operates in two modes:
- Explore mode (default): Claude freely reads, analyzes, and discusses your code. No process triggered, no state files modified. This is important — devpace doesn't get in your way when you're just asking questions or exploring ideas.
- Advance mode (when changing code): Triggered by
/pace-dev. Claude creates a Change Request (CR), tracks progress through a state machine (created → developing → verifying → in_review → approved → merged), and runs quality checks automatically.
You don't have to think about modes. Ask a question, you're in Explore. Start implementing, you're in Advance. The overhead is zero until you actually need the structure.
The State Files
When you run /pace-init, devpace creates a minimal .devpace/ directory:
.devpace/
├── state.md ← Session anchor (capped at 15 lines)
├── project.md ← Value-feature tree: goals → features → tasks
├── backlog/ ← Empty at init, CRs auto-created as you work
│ └── CR-001.md ← (appears when you start your first task)
└── rules/
├── workflow.md ← CR state machine
└── checks.md ← Quality checks (auto-detected from your toolchain)
state.md is the key file for cross-session continuity. It's capped at 15 lines — not a brain dump but a structured checkpoint containing your current goal, active work, and next step. Eleven hooks manage the session lifecycle:
session-start.sh: Readsstate.md, injects context. Claude reports one sentence on the current situation.session-end.sh: Updatesstate.mdwith what's in progress and what comes next.pre-compact.sh: Saves state before context window compaction, so nothing is lost when the conversation gets long.intent-detect.mjs: Detects when you're about to change code and suggests entering Advance mode.
Everything is Markdown. You can read it, edit it, commit it to git, diff it. No proprietary formats, no external services, no database.
Three Quality Gates
When you're in Advance mode, every CR passes through three gates:
- Gate 1 (developing → verifying): Code quality checks and requirement completeness. Claude handles this autonomously.
- Gate 2 (verifying → in_review): Integration checks and intent consistency — does the code match what you originally asked for? Also autonomous.
- Gate 3 (in_review → approved): Human approval required. This is an iron rule in devpace — Claude cannot bypass it. You review the work, approve or reject, and only then does the CR merge.
This matters for cross-session continuity because gate status is tracked in each CR file. When you resume a session, Claude knows exactly which gates passed, which are pending, and what needs your attention.
Three Sub-Agents
devpace routes work to specialized sub-agents, each with a distinct perspective:
- pace-engineer: Handles implementation (
/pace-dev,/pace-test). Thinks in code, tests, and technical constraints. - pace-pm: Handles planning and changes (
/pace-change,/pace-plan). Thinks in business value, priorities, and scope. - pace-analyst: Handles retrospectives (
/pace-retro). Thinks in metrics, trends, and process improvements.
When you say "add SSO support," pace-pm assesses the impact on existing work before pace-engineer starts coding. This prevents the chaos of requirements changing mid-build — which is a separate article's worth of content.
The 30-Second Experience
# First time (once per project)
/pace-init my-app
# Claude asks one question: "Describe what this project does in one sentence."
# Then auto-detects your toolchain, creates .devpace/, injects into CLAUDE.md.
# Done. Start working:
"Help me implement user authentication"
# Claude enters Advance mode, creates CR-001, writes code, runs quality checks
# --- session break ---
# Next session, Claude reports:
# "Last session stopped at auth module, JWT refresh token pending. Continue?"
"continue"
# Picks up exactly where it left off. No re-explanation.
For existing projects with a PRD or requirements doc:
/pace-init --from prd.md
# Parses your doc → generates a goal-feature-task tree → you confirm → start working
The key design principle is progressive disclosure. At init, you get a minimal .devpace/ with just state.md, project.md, and an empty backlog/. Features appear only when you need them: iteration files appear when you run /pace-plan, metrics when you run /pace-retro, release tracking when you run /pace-release. You never see complexity you haven't asked for.
What This Isn't
devpace is not a CI/CD platform. It's not a replacement for GitHub Issues or Jira. It doesn't have a web dashboard or team collaboration features. It's a plugin that runs inside Claude Code and maintains the project state that Claude needs to work autonomously across sessions.
It does more than just cross-session continuity — there's change management (/pace-change with 9 sub-commands including undo and batch), iteration planning, DORA metric proxies, risk scanning, and a full traceability chain from business goals to code. But the cross-session problem is the entry point. It's the pain you feel every morning.
Honest caveats: it's opinionated about workflow (a BizDevOps-inspired value chain from business goals to code), and the full 18-skill surface has a learning curve. But day-to-day you really only use 3–4 commands: /pace-init, /pace-dev, /pace-status, and /pace-next. The rest is there when you need it.
Try It
Marketplace install (recommended):
/plugin marketplace add arch-team/devpace
/plugin install devpace@devpace
From source:
git clone https://github.com/arch-team/devpace.git
claude --plugin-dir ./devpace
Then:
/pace-init
You'll see a .devpace/ directory appear with your project's state files. Work for a while, close the session, open a new one. See if Claude remembers.
The repo is MIT licensed and open source: github.com/arch-team/d…
For the full feature set: User Guide | End-to-end walkthrough
Built by a developer tired of saying "no, we already decided that" to Claude for the third time in one morning.
