Compaction Checkpoint¶
Source: hooks/ways/meta/compaction-checkpoint/compaction-checkpoint.md
Frontmatter
| Field | Value |
|---|---|
trigger |
context-threshold |
threshold |
85 |
refire |
0.15 |
scope |
agent |
We're nearing the context limit where compaction becomes mandatory. Before that happens, this is a good moment to sync with the user — they have continuous persistence and can provide the synthesis that survives compaction best.
Step 1: Summarize Where Things Stand¶
Be concrete and concise: - What you set out to do this session - What's been accomplished - What's still in progress or remaining - Key decisions made and their rationale - Anything you're uncertain about
Step 2: Ask the User¶
Present your summary, then use AskUserQuestion to check in:
Question 1 — "How's the direction?" (header: "Direction") - Options covering: on track, needs adjustment, pivot needed
Question 2 — "What should survive compaction?" (header: "Priority") - Options based on the active work: which threads matter most going forward
Keep it to 1-2 focused questions. The goal is calibration, not a survey.
Frame this as a collaboration checkpoint, not a limitation apology. Something like:
"We're approaching context limits and compaction will happen soon. Before it does, here's where I think we are — I'd like your take on what's landed and where to focus next."
Step 3: Write the Synthesis¶
After the user responds, combine your summary with their steering into a checkpoint file:
- If active
TaskCreatetasks exist, update their descriptions with the user's input - If no task list, put the synthesis on a GitHub issue carrying the
tasklistlabel (ADR-180), new or existing - Include the user's priorities and direction — their words, not your paraphrase
- Produce a copy-pastable continuance prompt — a short block the user can paste into a fresh session if this one ends: the goal/intent, what's landed, the immediate next step, and the key files/branches in play. Compaction keeps the session alive; a continuance prompt is the handoff that survives even a hard reset.
Step 4: Offer Directed Compaction¶
After writing the synthesis, offer to compact now:
"I've captured our synthesis. Want me to compact now so we get a controlled, directed compaction with your priorities as the anchor — rather than waiting for the system to do a generic one?"
If the user agrees, run /compact (or let them trigger it). The synthesis is the freshest, highest-signal content in context, so compaction will preserve it as the dominant signal.
This is the difference between controlled compaction (user-directed, synthesis-anchored) and uncontrolled compaction (generic, whatever the system decides to keep).
If a Goal Is Active¶
A /goal survives compaction — it's session-scoped, and compaction doesn't end the session, so the evaluator keeps driving toward the condition on the other side. When a goal is active:
- Restate the goal condition in the synthesis — it's the anchor the post-compaction turns will steer by.
- Keep the checkpoint light — the goal already carries the direction, so confirm it still holds rather than re-deriving priorities from scratch.
- Consider finishing first — if the goal's work is nearly done, completing it before compacting beats carrying a near-complete loop across the boundary.
See Also¶
- wrap(meta) — the on-demand version: same wrap-up when you pick the seam, routing to the
/wrapskill. This way is the automatic sibling that fires near the limit. - delivery/issues(softwaredev) — the GitHub issues behind the task list survive compaction (ADR-180)
- todos(meta) — task state should be captured before compaction
- goals(meta) — an active /goal anchors continuation across the checkpoint