Mid Session Context Recovery

The Problem

You're 45 minutes into a Claude Code session. The agent was sharp at the start — reading files correctly, following your architectural decisions, citing line numbers. Then something shifts. It suggests a library change you already rejected in exchange 3. It re-implements a function you deleted 20 minutes ago. It starts producing shorter, less specific responses. Its responses feel "uninformed" — like it's working from memory of a conversation it barely remembers.

This is context rot — the silent killer of long agent sessions. Unlike crashes or API errors, context rot doesn't announce itself. The agent keeps working, just progressively worse. By the time you notice, you've burned 30 minutes on work you can't trust and need to restart the session to rebuild context from scratch.

What You Get

• Four-signal rot detection — Regression Loop (about to suggest something already rejected), Instruction Drift (no longer following original constraints), Lost-in-the-Middle (working from stale file memory), Quality Degradation (responses getting shorter, less specific, less evidence-based)
• Structured checkpoint protocol — saves current state to .claude/checkpoint-[timestamp].md capturing completed tasks, in-progress work, key decisions, user directives, and current file states
• Three-step recovery workflow — Checkpoint (snapshot state), Flush (acknowledge rot to user transparently), Recalibrate (re-read files from disk, not from memory; re-read project config; resume with refreshed context)
• Rot-specific recovery strategies — each of the four rot types has a tailored recovery path (regression: re-read completed list; drift: audit last 3 modifications against directives; lost-in-the-middle: re-read ALL files in scope; quality: switch to "thorough mode" with line citations)
• Proactive 45-minute trigger — automatic checkpoint recommendation when session duration crosses the high-risk threshold, before rot becomes irreversible
• Checkpoint cleanup — intermediate checkpoints deleted at session end, only the latest kept for reference

Why This Beats Prompting It Yourself

You can manually notice when your agent "goes bad" — but by then you've already lost the context you need to recover. The skill detects rot signals before they become catastrophic: the agent self-audits before every complex task in long sessions, flagging "I'm about to suggest something we already decided against" instead of silently proceeding. It's the difference between catching a regression in 30 seconds vs. discovering it after 20 minutes of wasted work.

Example Session

Developer: "Now let's add error handling to the payment service."

Agent (detects 45-min mark, self-initiates checkpoint):

Before I add error handling, let me do a quick checkpoint — we've been 
working for about 45 minutes. I've saved our current state to 
`.claude/checkpoint-2026-09-21-1045.md`:

Completed: Stripe checkout flow, webhook handler, subscription model
In progress: Payment service refactor (services/payment.ts)
Decisions: Idempotency keys for all Stripe calls, payment status in subscriptions table
Your directives: No try-catch for Stripe SDK errors (let them propagate), 
                 use Zod for webhook validation

Let me re-read `services/payment.ts` to recalibrate before I add error handling.
[re-reads file]
Recalibrated. I see a PaymentService class with createCheckoutSession 
and handleWebhook methods. Should I add error handling for 
createCheckoutSession, handleWebhook, or both?

Without the skill: agent starts adding error handling without re-reading the file, uses try-catch around Stripe SDK calls (violating the user's directive from exchange 12), and the developer discovers the violation 15 minutes later in code review.

Use Cases

• Long debugging sessions — prevent drift when spending 30+ minutes tracing a complex bug across multiple files
• Multi-file refactoring — maintain architectural consistency when changes span many files over an hour
• Pair programming with agents — keep the agent's context aligned with the developer's decisions during extended sessions
• Automated pipeline recovery — checkpoint before risky refactors so partial progress is recoverable
• Session handoff preparation — checkpoint state before ending a session so the next session can resume with full context

Known Limitations

Context recovery works within a single session — it cannot restore context from a previous session (that requires CLAUDE.md or AGENTS.md). The skill detects degradation signals but cannot fix fundamental model capability limitations. If the model itself produces low-quality output (not context-related), checkpointing won't help.