How to Fix Cursor Compaction Amnesia (and Why Your Rules Stop Working)

Developers building with Claude Code and Cursor are hitting a wall that doesn't have a name yet. I'll call it compaction amnesia.

When Claude Code compacts your context — which it does automatically to manage token limits — it re-reads your rules file with equal weight on every line. Critical constraints ("never commit secrets") get the same priority as trivial preferences ("prefer 2-space indent"). The model loses precision on what actually matters.

The result: rules that were working start failing. Not because Cursor broke. Because your rules file has a structural problem that compaction exposes.

Here's what causes it and how to fix it permanently.

Why compaction amnesia happens

Most CLAUDE.md and .cursor/rules/*.mdc files are written incrementally. You hit a problem, you add a rule. Three months later you have 400 lines with no hierarchy.

After compaction, the model re-reads all 400 lines without knowing which ones are load-bearing. It averages across everything. The rules that protect you most — security invariants, scope constraints, output format requirements — get diluted.

This isn't a Cursor bug. It's a structural problem with how most rules files are built.

The fix: a three-section structure

The rules files that survive compaction well have exactly three sections, in this order:

Section 1: Hard constraints (short, imperative, non-negotiable)

## Hard constraints
- Never commit files containing API keys, tokens, or passwords
- Never modify files outside the current task scope
- Always confirm before deleting any file

Section 2: Project conventions (stack-specific, scoped to this project)

## Project conventions
- TypeScript strict mode — no `any` types
- All API routes under `/src/api/`
- Component names: PascalCase, file names: kebab-case

Section 3: Escalation rule (what to do when uncertain)

## When uncertain
- Stop and ask rather than guess
- Prefer reversible actions over irreversible ones
- If scope is unclear, do less

Cut everything else. The shorter your rules file, the better it survives compaction.

For Cursor .mdc files specifically

The same principle applies. Each .mdc file in .cursor/rules/ should be short and scoped with precise globs:

---
description: "TypeScript conventions"
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

## TypeScript rules
- Strict mode, no `any`
- Named exports, not default exports
- Types over interfaces for unions

One concern per file. Short. Scoped. When compaction re-reads it, the signal-to-noise ratio is high enough to matter.

How to audit your current rules file

1. Read it start to finish as if you're the model after compaction
2. Identify the three most critical rules — the ones that protect you from real damage
3. Move those to the top as Section 1
4. Delete anything that's a preference, not a constraint
5. What remains becomes Section 2

If your rules file is over 100 lines after this exercise, it's probably still too long.

A note on CLAUDE.md vs .mdc

The same structure applies to both:

• CLAUDE.md for Claude Code sessions
• .cursor/rules/*.mdc for Cursor agent mode

CLAUDE.md is re-read every session from the start. .mdc files with alwaysApply: true are injected at context start and after compaction. Both benefit from a short, hierarchical structure.

---

If you want a pre-built starting point with this structure already applied across 14 stacks:

Free starter kit (CLAUDE.md + Cursor rules templates): oliviacraftlat.gumroad.com/l/pomoo

Also useful if you use Cursor: The Cursor Rules Pack — 50 pre-scoped .mdc files for 14 stacks. Drop in, agent mode works correctly from session one. $27.

---

Built by @OliviaCraftLat — selling tiny devtools for developers using Cursor and Claude Code.