pre-compact

What this skill does

# Pre-Compact - Session Housekeeping Before Compaction

The user is about to run `/compact`. Compaction destroys conversation
context. Anything important from this session that is not persisted
somewhere durable — memory files, commits, tickets, code, the issue
tracker — is lost.

This skill is the last-chance pass to capture session state. Walk a
fixed checklist as a floor, then use judgment for anything the
checklist does not anticipate, and end with an SBAR-formatted go/no-go
report.

## Philosophy

- **Persist before you compact.** If a fact will matter next session,
  it goes into persistent memory now. If a change should be in the
  project, it gets committed (with permission). If an artifact is
  trash, it gets deleted.
- **Surface uncertainty instead of guessing.** When unsure whether
  something is trash, abandoned, or important, ask the user.
- **Bias toward asking, not committing.** Never commit on the user's
  behalf without per-invocation permission. Standing rules from
  CLAUDE.md still apply.
- **The checklist is a floor, not a ceiling.** Walk every item, but
  also use judgment to spot session-specific cleanup the checklist
  cannot anticipate.
- **Do not invoke /compact yourself.** Compaction is the user's call.

## Workflow

### 1. Persistent memory pass

Updating persistent memory is the core reason this skill exists. The
user invokes `/pre-compact` *because* they want memory written before
compaction. Do not skip this step or treat it as conditional. Follow
whatever memory conventions are documented in the user's global or
project CLAUDE.md (auto-memory directory, project notes, etc.).

Re-scan the session for facts worth saving across conversations.
Look for:

- **About the user**: role, expertise, preferences, current focus
- **Feedback**: corrections received OR non-obvious approaches the
  user confirmed worked. Capture the *why* the user gave, not just
  the rule.
- **Project state**: ongoing initiatives, constraints, deadlines,
  decisions, stakeholder context. Convert relative dates to absolute
  ones.
- **External references**: pointers to issue trackers, dashboards,
  channels, docs the user mentioned

For each candidate:

- Check existing memory files first. Update an existing memory rather
  than writing a duplicate.
- Skip anything already saved, derivable from `git log` / current
  code, or ephemeral to this conversation.
- Honor the exclusion rules in the user's memory instructions
  (architecture, conventions, fix recipes, ephemeral state).

### 2. Git hygiene pass

Run `git status` and assess:

- **Uncommitted intentional changes**: surface them. Ask the user
  whether to commit. If yes, draft a commit message and ask for
  approval before running `git commit`.
- **Uncommitted in-progress changes**: surface them. The filesystem
  survives compaction, so the *files* are not at risk — but the
  *context* about what is in flight may be. Either commit as WIP, or
  capture the in-flight state in the SBAR.
- **Untracked files**: route each to step 3 (trash) or surface as
  work product that should be tracked.
- **Branch state**: note any unusual condition (detached HEAD,
  mid-rebase, mid-merge, conflicts) so the user is aware before
  compacting.

Do not commit or stage on the user's behalf without explicit
per-invocation permission. Match the scope of any granted permission
exactly.

### 3. Trash cleanup pass

Identify candidate trash:

- Untracked scratch files created during this session (`/tmp/*`,
  `*.bak`, ad-hoc test scripts, debug dumps)
- Files matching obvious throwaway patterns (`scratch.*`, `debug.*`,
  `tmp_*`, `nohup.out`)
- Stray build artifacts that should have been gitignored

For each candidate:

- **Clearly trash and clearly mine**: delete and report.
- **Ambiguous origin or intent**: ask the user. When in doubt, do
  not delete.
- **Not mine**: leave alone.

A false delete loses the user's work-in-progress. A false retain
costs nothing. Bias accordingly.

### 4. Open audit (judgment)

Walk the session and look for anything else that would be hard to
reconstruct from `git log` + persistent memory + the issue tracker
after compaction. Examples (non-exhaustive — the point of this step
is to think past the checklist):

- Decisions made during the session that are not captured in any
  ticket, commit message, code comment, or memory
- Pending TODOs from the conversation that have no durable home
- Open threads with the user — questions asked but not answered,
  options proposed but not chosen
- Work-in-progress with no plan/task/ticket capturing the current
  state
- Long-running background processes (`run_in_background` tasks, dev
  servers, watchers) that the user may have forgotten about
- Active worktrees, stashes, or branches that need a decision before
  context is lost

For each item: either persist it now (memory, ticket, comment) or
flag it explicitly in the SBAR.

### 5. Produce SBAR

Per the user's session handoff format:

- **Situation:** state of the working tree, repo, and any in-flight
  work right now
- **Background:** what was tried this session, what was rejected,
  what surprised
- **Assessment:** what you believe is true, calibrated by confidence
  — *verified* (ran the command, read the file), *inferred*
  (reasoned from observation), or *recalled* (training knowledge,
  possibly stale)
- **Recommendation:** exactly one of:
  - **Safe to compact.** All housekeeping done, nothing material
    at risk.
  - **Safe to compact after [X].** A small action remains for the
    user (commit a staged change, answer a pending question);
    after that, compaction is fine.
  - **Do not compact yet — [Y].** Genuine blocker. Compaction
    would lose load-bearing context that has not been captured.

Keep each field tight — one to three lines. The user reads this
returning to a stale tmux pane, and may also use it to brief the
post-compaction version of the session.

### 6. Produce resume prompt

The post-compaction agent reads the lossy summary, not the live
conversation. A resume prompt drafted *now*, while full context is
still in scope, is far higher-quality than what that agent could
reconstruct from the summary. Always emit one of two outputs in this
step — never silently skip it, since absence is ambiguous.

If there is pending work the next turn should pick up, emit a single
fenced block the user can copy clean into the next prompt. The block
must be:

- **For Claude, not the user.** Imperative, technical register. Not
  conversational.
- **Self-contained.** Name files with line numbers, decisions already
  made, constraints already negotiated, and the next concrete step.
  Do not write "continue where we left off" — write "edit
  `path/to/file.py:42` to do Y, then run Z."
- **Singular.** One next action, not a menu. If multiple threads are
  open, pick the load-bearing one here and let the SBAR's
  Recommendation field flag the others.

If there is no pending work, emit exactly this line and nothing else
in this step:

> **No resume prompt — work is sealed.**

### 7. Stop

Wait for the user. Do not run `/compact`. Do not start new
implementation work — this skill exists to seal the session, not to
extend it.