compaction
Skill2 starsChanged 3 months agoMITView on GitHub
Phase 7 of ACF. Compacts the context snapshot and progress file using techniques inspired by Kimi CLI's compaction system (head+tail preservation, priority-based compression, XML-tagged output, first-person handoff). Use when ACF detects the context snapshot is growing too large, when the user asks to "compact context", "compress the snapshot", or "save tokens", or when the progress file exceeds a token budget threshold.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- frnkgns/Overgeared-Skillstheir own version, first seen Nov 8, 2026
- CorvusWing/CorvusWingtheir own version, first seen Oct 25, 2026
- MaDxCRaZY/antigravity-skillstheir own version, first seen Oct 20, 2026
- StarRocks/starrocks-debug-skillstheir own version, first seen May 26, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- StarRocks/starrocks-debug-skills★ 77same name
- frnkgns/Overgeared-Skills★ 7same name
- MaDxCRaZY/antigravity-skills★ 4same name
- CorvusWing/CorvusWing★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- context-loadSkill
- stack-auditSkill
- issue-craftSkill
- pr-contextSkill
- frontend-previewSkill
- label-metadataSkill
- cavemanSkill
- graph-scopeSkill
- acfSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Before passing context to a model with a small context window
- Very specific: line 55
If the head or tail exceeds its token budget, it is truncated to the budget with a [...
- Very specific: line 241
ghnot authenticated: not applicable to compaction. - Distinctive: line 242
GitHub API rate limits: not applicable to compaction.
- Very specific: line 243
Progress file doesn't exist: if .slim/acf/<slug>.md is missing, report "Progress file not found — nothing to compact.
- Distinctive: line 246
Commands fail: if the progress file cannot be read (permissions, encoding), report the error and skip compaction.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Compaction
Reduces the context snapshot and progress file to a fraction of their original size while preserving the information that matters for issue-craft and pr-context. Inspired by Kimi CLI's open-source compaction system (MoonshotAI/kimi-cli), with head+tail preservation adapted from Kimi Code PR #1313.
When to Trigger
- The progress file (
.slim/acf/<slug>.md) exceeds ~2000 tokens (~8000 chars) - The context snapshot has more than 5 sections with more than 5 bullets each
- The user explicitly asks to compact or compress context
- Before passing context to a model with a small context window
- Between phases when the snapshot has accumulated stack-audit findings
Kimi's Compaction Techniques (adapted for ACF)
ACF borrows five key techniques from Kimi's compaction system:
1. Head+Tail Preservation
Kimi Code's PR #1313 splits the conversation into three regions:
- Head: the oldest messages (the original task statement), kept verbatim
- Tail: the most recent messages, kept verbatim
- Middle: everything else, summarized into a compact block
An elision marker ([... N tokens compacted ...]) is inserted between the
head and tail so the agent can see how much was compressed.
ACF adapts this with SDLC-specific bounds:
- Head (max 500 tokens): the original user request — the first message of the session — is preserved verbatim. This ensures the original task statement never vanishes in long sessions.
- Tail (max 1000 tokens): the most recent phase output (e.g., the last stack-audit findings or the current issue draft) is preserved verbatim.
- Middle: everything between head and tail is compacted using the priority-based compression below.
- Elision marker:
[... ~N tokens compacted ...]is inserted between the head and tail sections.
If the head or tail exceeds its token budget, it is truncated to the budget
with a [... truncated ...] marker. If the entire session fits within
head + tail budgets, no compaction is needed.
2. Priority-Based Compression
Kimi's compact.md prompt defines compression priorities in order:
- Current Task State (what is being worked on RIGHT NOW)
- Errors and Solutions (all encountered errors and their resolutions)
- Code Evolution (final working versions only, remove intermediate attempts)
- System Context (project structure, dependencies, environment setup)
- Design Decisions (architectural choices and their rationale)
- TODO Items (unfinished tasks and known issues)
ACF applies the same priorities to the SDLC context:
- Current issue/PR draft — preserve verbatim
- Stack-audit findings — preserve orphan PRs, close gaps, escaped issues
- Test commands and CI checks — preserve exact command strings
- Architecture facts — compress to one-line summaries
- Conventions — compress to label names only
- Completed phases — compress to one-line outcomes
3. XML-Tagged Output Structure
Kimi's compaction output uses XML-like tags for structured retrieval:
<current_focus>, <environment>, <completed_tasks>, <active_issues>,
<code_state>, <important_context>.
ACF uses the same pattern for the compacted snapshot:
<current_focus>
[The issue or PR currently being crafted — 1-2 lines]
</current_focus>
<stack>
- Open PRs: [count] | Orphan: [count] | Stale issues: [count]
- Close gaps: [list PR#→Issue# or "none"]
- Escaped issues: [list or "none"]
- Library opportunities: [list or "none"]
</stack>
<tests>
- [exact test command 1] ([N] tests)
- [exact test command 2] ([N] tests)
- Coverage: [command or "none"]
</tests>
<ci>
- [check name 1] (from [workflow file])
- [check name 2] (from [workflow file])
</ci>
<architecture>
- Stack: [one line]
- Key dirs: [paths only]
- Architecture doc: [path or "none"]
</architecture>
<conventions>
- Labels: [type + priority + area required]
- Commit: [conventional commits]
- Branch: [prefix rules]
</conventions>
<completed_phases>
- context-load: [done — snapshot built]
- stack-audit: [done — N findings]
- issue-craft: [in progress — draft at /tmp/issue-body.md]
</completed_phases>4. First-Person Handoff
Kimi-Code's compaction rework writes the summary as the agent's own continuing notes (first-person), not a third-party report. The summary:
- Preserves exact commands, paths, and outcomes
- States the precise next action
- Flags claimed-but-unverified work rather than trusting it
ACF applies this to the progress file. After compaction, the progress file reads as the agent's own working notes, structured as head + elision + tail + compacted summary:
## Compacted Handoff
### Original Request (preserved)
[user's original request, verbatim — max 500 tokens]
[... ~N tokens compacted ...]
### Current State (preserved)
[most recent phase output, verbatim — max 1000 tokens]
### Compacted Summary
I was working on [issue/PR title]. The context snapshot is compacted.
What I know:
- Stack has [N] orphan PRs, [M] stale issues
- Test command: [exact command] — [N] tests pass
- CI check: [check name] must pass
What I need to do next:
- [precise next action, e.g., "run gh issue create with the draft at /tmp/issue-body.md"]
What I have NOT verified yet:
- [anything claimed but not confirmed, e.g., "CI check names are guessed — verify against .github/workflows/"]Compaction Rules
- MUST KEEP: exact test commands, CI check names, issue/PR numbers, label names, orphan PR numbers, close-gap pairs
- MERGE: similar findings into single lines (e.g., "3 stale issues" not listing all three)
- REMOVE: full file contents (replace with paths), verbose architecture descriptions (replace with one-line summaries), intermediate drafts
- CONDENSE: long command lists into counts + the most critical command
- PRESERVE HEAD: the original user request (first message) is preserved verbatim, up to 500 tokens
- PRESERVE TAIL: the current phase's output is preserved verbatim, up to 1000 tokens — never compacted
- ELIDE MIDDLE: insert
[... ~N tokens compacted ...]between head and tail to mark compacted content - FIRST-PERSON: the handoff note is written as the agent's own notes
Auto-Trigger Threshold
Following Kimi's should_auto_compact logic:
trigger_compaction = (
token_count >= max_context_size * trigger_ratio # default 0.85
or token_count + reserved_context_size >= max_context_size
)For ACF, the defaults are:
max_context_size: 8000 tokens (configurable per project)trigger_ratio: 0.75 (compact earlier than Kimi's 0.85, since ACF context is already compressed)reserved_context_size: 2000 tokens (space for the next phase's output)
Manual Trigger
The user can trigger compaction at any time with a custom instruction:
"compact context — keep the stack-audit findings"
"compress the snapshot — prioritize test commands"The custom instruction is appended to the compaction prompt, telling the
model what to prioritize (same as Kimi's /compact keep db discussions).
Token Estimation
Following Kimi's heuristic: tokens ≈ chars // 4 (approx. 4 chars per token
for English). For Spanish content, use chars // 3.5 (Spanish has more
characters per token due to accents and longer words).
Output
The compacted snapshot replaces the full snapshot in the progress file. The original full snapshot is NOT kept — compaction is lossy by design. If the full snapshot is needed, re-run context-load.
Relationship to Caveman Mode
Compaction is the standard compression mode. Caveman (phase 8) is the
extreme compression mode for when even the compacted snapshot is too large.
See skills/08-caveman/SKILL.md.
Sources
- MoonshotAI/kimi-cli — compaction.py
- MoonshotAI/kimi-cli — compact.md prompt
- MoonshotAI/kimi-code — first-person handoff rework (PR #1214)
- MoonshotAI/kimi-code — head+tail preservation (PR #1313)
- Kimi Code CLI Docs — Context compression
Error Handling
ghCLI not installed: compaction operates on the progress file, not GitHub. It does not requiregh. Proceed normally.ghnot authenticated: not applicable to compaction. Proceed normally.- GitHub API rate limits: not applicable to compaction. Proceed normally.
- Progress file doesn't exist: if
.slim/acf/<slug>.mdis missing, report "Progress file not found — nothing to compact. Run context-load first." Do not create an empty compacted file. - Commands fail: if the progress file cannot be read (permissions, encoding), report the error and skip compaction. Do not destroy the original file. If compaction produces invalid output, restore from the pre-compaction state (the agent should keep a copy before overwriting).
Example
Before (full snapshot, ~2000 tokens)
## Context Snapshot
### Architecture
- Stack: Luau, Knit, Lune build tool
- Key dirs: src/server/, src/client/, src/shared/, scripts/, docs/
- Architecture doc: docs/ARCHITECTURE.md
### Challenge
- Current branch: fix/flashlight-fireserver
- Open issues: 7 (from stack-audit)
- Open PRs: 2 (from stack-audit)
### Templates
- Issue templates: bug-report.yml (auto-labels: bug, area:backend), feature-request.yml
- PR template: .github/PULL_REQUEST_TEMPLATE.md (required: Summary, Closes, AC)
### Tests
- Test commands: lune run scripts/test_core.luau
- Test count: 26 tests across 3 suites
- Coverage tool: none
### CI Checks
- Check names: test (lune), lint (selene), type-check (luau-analyze)
- Required checks: test (lune), type-check (luau-analyze)
### Conventions
- API: OnClientEvent/OnServerEvent for RemoteEvents (NOT .Event)
- Lifecycle: all :Connect() stored + disconnected in KnitDestroy
- Constants: no magic numbers — all in Constants.luau as UPPER_SNAKE_CASE
- Testing: mock Players:GetPlayerByUserId → nil for no-op replication
- Rollout: 3-stage (Hidden → Integrated → Cleanup) for new features
- Commit format: conventional commits
- Branch naming: fix/, feature/, docs/
## Stack-Audit Findings
- Orphan PRs: PR #42 "feat: add leaderboard UI"
- Stale Issues: Issue #17 "fix: flashlight :Fire()"
- Close Gaps: PR #38 merged but issue #29 still open
- Escaped Issues: Issue #51 closed, no merged PR
- Library Opportunities: Roact could simplify issue #17After (compacted, ~800 tokens)
## Compacted Handoff
### Original Request (preserved)
Fix the flashlight tool to use :FireServer() instead of :Fire().
[... ~1200 tokens compacted ...]
### Current State (preserved)
Issue #17 draft at /tmp/issue-body.md — ready to create.
### Compacted Summary
I was working on fix: flashlight uses :FireServer() instead of :Fire().
What I know:
- Stack has 1 orphan PR (#42), 1 stale issue (#17), 1 close gap (PR#38→Issue#29)
- Test command: lune run scripts/test_core.luau — 26 tests pass
- CI checks: test (lune), type-check (luau-analyze) must pass
- Conventions: OnServerEvent for RemoteEvents, --!strict, conventional commits
What I need to do next:
- Run gh issue create with the draft at /tmp/issue-body.md
What I have NOT verified yet:
- CI check names are from context-load — verify against .github/workflows/Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

