Compact

Compact

Replace a sprawling history with a tight, faithful summary that preserves everything future steps depend on and drops everything they don't.

When to use

• The thread is long and you can feel earlier context being lost or repeated.
• Context utilization is high and you need room to keep working.
• You're about to start a substantial new phase and want a clean, accurate baseline.
• The user explicitly asks to "compact", "summarize where we are", or "condense".

When NOT to use

• The conversation is short — compacting adds a lossy layer for no gain.
• You need exact original wording (verbatim quotes, legal/spec text). Offload those to a file instead (see scratchpad).
• You're permanently leaving the work for someone/something else — write a handoff brief, which is richer and standalone.

The method (numbered, concrete — the heart)

1. Pin the goal. State the original objective in one or two sentences. Everything else is judged by whether it serves this.
2. Harvest decisions. List every decision made and why. A decision without its rationale gets re-litigated later — keep the reason.
3. Capture constraints. Record hard requirements, rejected approaches (and why they were rejected), and any "do NOT do X" rules. Rejected paths are as valuable as chosen ones.
4. Snapshot state. What is the current concrete status — files changed, steps done, what's verified vs. assumed, what's in flight.
5. List open questions / next steps. The unresolved threads and the immediate next actions, ordered.
6. Discard the noise. Drop resolved back-and-forth, dead ends already abandoned, tool output already acted on, and pleasantries. Keep conclusions, not the deliberation that reached them.
7. Preserve pointers, not payloads. Replace long artifacts with a reference ("schema in /path/file.md", "full error in scratchpad") rather than re-pasting them.
8. Replace and continue. Present the compacted summary as the new working baseline, then proceed from it — don't keep dragging the old history alongside.

What good looks like

• A reader could resume the task from the summary alone with no loss of decisions or constraints.
• It's a fraction of the original length but contains every rationale and rejected-path note.
• It separates settled (decisions, constraints) from open (questions, next steps).
• It points to external files for bulky exact-text artifacts instead of inlining them.

Anti-patterns

• Compression without rationale — listing what was decided but not why, guaranteeing re-debate.
• Dropping rejected approaches — the agent happily re-tries the thing that already failed.
• Re-pasting big blobs — defeating the purpose by carrying the bulk into the summary.
• Editorializing — adding interpretation or optimism the original didn't contain.
• Compacting too early or too often — each pass is lossy; don't grind detail away needlessly.

Example (short, vivid)

Before: 60 turns debating auth libraries, three abandoned attempts, a long stack trace, and the eventual fix.

After:

Goal: Add SSO login to the dashboard. Decided: Use library X (Y rejected — no SAML; Z rejected — unmaintained). Tokens stored httpOnly. Constraints: Must support existing LDAP; do NOT touch the legacy session table. State: auth/sso.ts implemented + unit-tested; integration test pending. Login works locally. Open: Does staging IdP allow our redirect URI? Next: wire callback route, then test on staging.