context-compression

Tokenless Context Compression

When working in this project, do not feed noisy raw outputs or large files directly into context.

Tokenless is mandatory for large or noisy context:

• If a file is large, first use tokenless read --agent --data-dir <dir> <file>.
• If a Bash command is noisy, first use tokenless run --agent --data-dir <dir> -- <command>.
• If a Tokenless hook blocks or caps a tool call, do not bypass it with another full-output command.
• If you need exact evidence after a packet, expand the artifact before editing.
• If Tokenless reports a pending large-file gate, the next action must be the exact NEXT REQUIRED COMMAND.

The hook automatically caps high-noise Bash commands and large low-risk Read outputs through Tokenless.

Keep tool inputs small:

• Tokenless saves context by replacing large tool outputs with compact packets. Do not recreate the same token cost by sending huge generated tool inputs.
• Prefer tokenless read, tokenless expand, and small bounded Edit/MultiEdit calls over large patch scripts.
• Do not create large heredocs, cat > file <<EOF, giant node -e / python - commands, or temporary apply/fix/rewrite scripts unless the user explicitly asks.
• If you feel tempted to write a big script to patch a large file, stop and use Tokenless to expand the exact lines, then edit only that small region.

For manual local development in this repository, use ./plugins/claude-code/bin/tokenless or the packaged tokenless alias:

./plugins/claude-code/bin/tokenless run --agent --data-dir /tmp/tokenless-dev -- npm test

High-noise commands include:

• npm test, pnpm test, yarn test
• pytest
• npm/pnpm/yarn build, lint, typecheck, install
• go test, cargo test, mvn test/verify/package, gradle build/test
• git diff, git log
• rg, grep -R
• find, tree, ls -R
• docker logs/build, kubectl logs/describe, Vercel/Netlify CLI logs

When you see a TOKENLESS-PACKET block:

1. Treat it as a compressed evidence packet.
2. Use the key failures, relevant files, line numbers, and raw artifact pointer.
3. Do not ask for the full raw output unless needed.
4. If needed, use the full raw artifact command shown in the Raw artifact: line.

When you see a TOKENLESS-READ-PACKET block:

1. Treat it as a compact local summary of a large file.
2. Read Action boundary before running any other command. It defines what tool commands are valid for this artifact.
3. If it contains Action brief and Editable snippets, treat those snippets as the first-pass edit surface, not as a table of contents to explore.
4. For broad visual/style tasks, do one minimal native Read to register editor state if you plan to edit, then make 6-10 bounded Edit calls from the snippets before doing more exploration.
5. Use only the artifact lookup commands shown in Action boundary when a needed old_string is not present in the snippets.
6. Do not expand every listed region by default.
7. Do not use repeated grep, rg, sed, or small Read calls to re-map the same file after a packet has already identified the edit targets.
8. Do not add unrelated files, scripts, or JS/HTML interactions for a CSS-only request unless the user explicitly asks.

Tool boundaries:

• tokenless read creates a whole-file packet only.
• tokenless read is not a range, selector, or line lookup tool.
• Do not invent tokenless read --range, tokenless read --selector, tokenless read --lines, or similar flags.
• tokenless expand is the artifact lookup tool for a specific selector/text or line range.
• tokenless show / raw artifact access is not for normal editing.

Large CSS visual-edit protocol:

1. After a TOKENLESS-READ-PACKET, do not perform a second full-file read.
2. Identify the smallest useful edit set from Editable snippets: tokens/variables, background layer, shared cards, buttons, one optional hero/visual area, one optional timeline/footer area.
3. After the registration Read, make 6-10 bounded Edit calls when the snippets are sufficient.
4. If exact old_string is missing, use at most two tokenless expand lookups before the first edit.
5. Do not wait for File must be read first; proactively do one minimal native Read only to register editor state, then immediately edit. If the error still appears, do not remap the file.
6. After the first successful edit, continue editing only if the user request still clearly needs it; otherwise stop with a concise summary.
7. Do not open the page or run visual validation unless the user explicitly asks for validation.
8. Do not make “extra premium” changes outside the asked surface, such as mouse-tracking JS, custom scrollbars in HTML, or new runtime scripts, unless requested.
9. Final answer should be 3-5 concise bullets only; do not write a long change diary.