Overview
In long sessions, the context window is limited and decays. This skill guides when to compress, what to keep, what to discard, and how to externalize durable state.
Core principles:Compress at logical boundaries, not at arbitrary moments.
Lightweight Context Engineering Guard
At the start of a major phase, at handoff, and before compression, execute with a short piece of text:
objective:
plan_5_steps_or_less:
context_audit:
- keep:
- externalize:
- discard:
- stale_or_conflicting:
next_boundary:
Plan at most 5 steps. If it cannot be expressed in 5 steps, first converge the current tranche; do not expand scope.
Compression decision table
| Current phase | Next phase | Compress? | Reason |
|---|---|---|---|
| Research/exploration | Planning | Yes | Exploration details do not need to be carried into planning |
| Planning | Implementation | Yes | Keep the plan, discard the planning process |
| Implementation step N | Implementation step N+1 | No | Compressing mid-implementation loses context |
| Implementation complete | Verification | Optional | If context is near the limit |
| Verification | Commit | No | Verification results need to be carried into the commit |
| Task A complete | Task B starts | Yes | Compress between different tasks |
Context Audit
Before compression, classification is required:
- keep: goals, constraints, current branch, modified files, key decisions, latest verification results, next steps
- externalize: raw logs, large diffs, broad search results, full CI output, long JSON
- discard: full stack traces of resolved errors, exploration process, repeated details of failed hypotheses
- stale_or_conflicting: old plans, old head SHA, expired CI, memories that conflict with current files
For externalization, prefer repo artifacts, checkpoints, issue/PR descriptions, run logs, or a user-specified scratchpad. Do not treat raw session logs as the current source of truth.
Post-compression retention checklist
Must keep:
- Current task goals and constraints
- Current plan of no more than 5 steps
- Architecture decisions already made and their rationale
- List of files already modified
- Unfinished steps
- Discovered issues and TODOs
- VibeGuard constraints (always keep)
- fresh verification evidence
- review gate decision when landing is next
Can discard:
- Full quotations of file contents (keeping the path is enough)
- Intermediate results from the search process
- Full stack traces of resolved errors
- Exploratory code reading records
How to use
When you feel the context is about to run out:
- Determine which phase you are currently in
- Check the compression decision table to confirm whether compression is appropriate
- Perform a context audit to decide keep / externalize / discard / stale_or_conflicting
- If appropriate, organize the summary according to the retention checklist
- Perform compression
Anti-patterns
- Compressing midway through implementation → losing critical context, leading to duplicated work
- Discarding constraints during compression → subsequent steps violate the rules
- Not compressing until overflow → passive truncation is more dangerous than proactive compression
- Treating old summaries as remote truth → need to re-fetch, check files, or query APIs