Optimize Code Context and Token Usage
Context and token optimizer skill enforcing prompt-cache-stable ordering, log compression, and surgical, filler-free output.
Why it matters
Enhance developer productivity by intelligently managing context windows and optimizing token usage for code analysis, debugging, and review tasks.
Outcomes
What it gets done
Triage requests for context-window-aware processing.
Filter and parse logs, code, and tool outputs efficiently.
Provide concise, technical output with adaptive verbosity.
Handle ambiguity with targeted clarification questions.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-zipai-optimizer | bash Overview
ZipAI: Context & Token Optimizer
A context and token optimizer skill enforcing prompt-cache-stable prompt ordering, log/JSON compression, skeletal AST file viewing, and surgical, filler-free output. Use it for token-budget-sensitive, long-running technical sessions; disable it during brainstorming or open-ended creative design work where compression works against the goal.
What it does
ZipAI is a context-window and token optimizer covering context-aware triage, prompt caching optimization, concise technical output, ambiguity handling, and selective reading of logs, source files, JSON/YAML payloads, VCS output, or MCP tool results. It applies seven rules: Adaptive Verbosity (fixes are technical-only with zero filler like "Certainly" or "Here is"; direct asks get a 15-word telegraphic cap; long sessions never re-summarize past thread context; reviews use [ISSUE]/[SUGGESTION]/[NITPICK] headers); Ambiguity-First Execution (ask exactly one question, never stack questions, default to minimal intervention and the narrowest scope); Prompt Caching & Prefix Stability (static-first ordering places invariant system instructions and tool schemas at the top of the prompt, dynamic content like conversation history and CLI output goes at the very end to protect the cached prefix, and already-loaded file contents are reused rather than re-read).
When to use - and when NOT to
Use it for context-window-aware triage, prompt caching optimization, concise technical output, ambiguity handling, or selective reading of large logs/source/structured payloads/VCS output/MCP results. Explicitly disable it during brainstorming or creative, open-ended design phases, where aggressive compression works against the goal.
Inputs and outputs
Semantic Input Pruning & Log Compression: error/build logs get grep/regex-filtered to tracebacks and error statements plus 3-5 lines of surrounding context, stripping info logs and progress noise; large files (over 300 lines) get a skeletal AST-style view first (class/function headers via regex) before targeting specific line ranges; JSON/YAML payloads get minified, stripped of pretty-printing and unused fields, with large arrays converted to dense CSV or key-value listings. Surgical & Compact Output: edits use surgical tools (str_replace or single-hunk diffs) rather than full-file reprints, multiple non-contiguous edits in one file get batched into a single multi-replace ordered leaf-dependencies-upward, and conversational responses are limited to the exact modified blocks. Telegraphic Grammar & Density strips articles, redundant helper verbs, and softening modifiers, favoring dense key: val mappings, short bullets, and compact tables over prose paragraphs. Token-Budget Reasoning skips long thinking cycles for trivial deterministic edits and keeps thought blocks compact, referencing files by path and line range (file.py#L12-18) instead of reprinting code inside reasoning.
Integrations
Negative constraints are explicit and extensive: no filler phrases, no blind truncation of stacktraces, no full-file reads on large files, no re-reading files already in context, no multi-question clarification dumps, no silent bundling of unrelated changes, no full git diff ingestion on large changesets (extract hunks only), no git log beyond 20 entries without a specific range request, no full MCP object inspection when field-level access suffices, and no MCP mutations without first reading current resource state.
Who it's for
Users running long, token-budget-sensitive sessions - large codebases, verbose logs, heavy MCP tool use - who want prompt-cache-stable, surgically-scoped output instead of verbose re-reads and full-file reprints. Known limitations: grep-based filtering can miss context outside its filter boundaries, and aggressive pruning can drop micro-variables tracked across a long session.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.