Skim - coding agent のための AST-aware context optimizer
AI coding agent の context 問題は、「window size が足りるか」だけではありません。大量の file を入れられても、implementation detail、log noise、重複した diff、長い test output に attention を取られると、model は重要な部分を見落とします。本当に足りないのは usable attention です。Agent が必要としているのは module boundary、function signature、failed assertion、critical error、changed scope であり、毎回 full source と full terminal output を読むことではありません。
今日紹介する dean0x/skim は、この問題に向けた Rust CLI です。「agent に code を見せる」作業を、いくつかの context optimization に分けています。tree-sitter で source structure を parse し、architecture、signature、type など目的別に残す。Test、build、lint、package manager、git output を圧縮する。さらに hook で common command を rewrite し、agent の普段の workflow の中で token consumption を減らします。GitHub page では現在およそ 26 stars、2 forks。主な言語は Rust、license は MIT。npm と crates.io では package name が rskim、current version は 2.10.0 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | dean0x/skim |
| 位置づけ | AI coding agent 向け context optimization / output compression CLI |
| Stars | 約 26 |
| Forks | 2 |
| 主な言語 | Rust |
| License | MIT |
| Package | rskim |
| Current version | 2.10.0 |
普通の cat replacement ではない
Skim の入口として一番分かりやすいのは、source file を短くする機能です。たとえば agent に TypeScript service を読ませるとします。すべての validation、loop、error wrapping が必要とは限りません。多くの task では、どの function があり、parameter は何で、return value は何か、class 同士がどう接続されるかを先に知りたい。Skim の default structure mode は function、class、type、import などを残し、function body を placeholder に折りたたみます。
これは単なる truncation ではありません。Truncation は file の後半を落とすだけで、language structure を理解しません。Skim は先に AST を parse し、目的に合わせて保持する layer を選びます。README では現在 17 languages が列挙されています。TypeScript、JavaScript、Python、Rust、Go、Java、C/C++、C#、Ruby、SQL、Kotlin、Swift、Markdown、JSON、YAML、TOML です。Code file では full、minimal、pseudo、structure、signatures、types などの mode を切り替えられます。JSON/YAML/TOML のような config file では、function signature を捏造せず structure を抽出します。
これは agent にとって実用的です。まず structure mode で architecture を見せ、実装を変更する必要が出たら該当箇所の原文に戻る。Context をただ削るのではなく、exploration phase と editing phase を分ける発想です。
Command output compression はすぐ効く
Source compression も便利ですが、私は Skim の terminal output coverage をより重視しています。AI agent はよく次の場所で context を浪費します。
cargo testやpytestが大量の passing case を出すが、本当に必要なのは failed assertion。tscやcargo buildが warning、path、stack を混ぜて出すが、agent に必要なのは error summary と location。git diffが長い unchanged context を含むが、重要なのは changed function と境界。npm install、pnpm、pip、cargo auditが progress と noise を出すが、必要なのは conflict や vulnerability。
Skim は skim cargo test、skim pytest、skim vitest、skim jest、skim go test を提供しています。Build では cargo build、cargo clippy、make、tsc。Lint/format では eslint、ruff、mypy、golangci、prettier、rustfmt、biome、black、gofmt などを扱います。設計としては、まず structured parse を試み、失敗したら regex fallback、さらに無理なら passthrough に落ちるという三段階です。
この fallback は大事です。Developer tool の output format は完全には安定しません。Structured parser だけに頼ると edge case で壊れやすく、raw output だけだと token を使いすぎます。Skim は少なくとも「できる限り圧縮し、必要なら原文を保つ」という方針を tool 側に持たせています。
skim init で context saving を default にする
README には agent workflow 向けの設計として skim init もあります。これは hook を install し、PreToolUse stage で common command を skim version に rewrite します。たとえば cat、head、tail、cargo test、vitest、git diff を対応する compressed command に置き換えます。
これは人間が毎回 skim を思い出して打つのとは違います。Agent workflow では「より良い command があるか」より、「agent が default でそれを呼ぶか」が問題になります。Command rewriting を hook layer に置くと、context optimization が agent の通常の tool call path に入ります。
もちろん、ここは慎重に扱うべきです。Command rewriting は semantics を変えたり、critical output を隠したりしてはいけません。Skim は compressed output が original output より大きくならない guardrail を説明していますが、利用者は低リスクな repository で先に観察するべきです。Failure log に十分な detail が残るか、diff が重要な context を落としていないか、test failure の原因を追えるかを確認した方がよいです。
AST-aware git diff は agent に読みやすい
skim git diff は Skim らしさがよく出ている機能です。普通の diff は line と hunk を単位にします。人間 reviewer には便利ですが、agent には不安定なことがあります。Local hunk は見えても、それがどの function に属するか、同じ file に関連する signature があるか、function boundary がどこかを見失いやすいからです。
Skim の git diff pipeline は AST を使って changed function を render し、function boundary と +/- marker を残そうとします。--mode structure では unchanged function を signature として context に追加できます。Agent が見るのは、単なる line fragment ではなく「この function がどう変わり、同じ file にどんな interface があるか」に近づきます。
Pre-commit の self-check にも向いています。Agent が code を変更したあと、確認すべき問いはだいたい三つあります。
- どの function や type を変更したのか。
- Local context が少なすぎて diff を誤読していないか。
- Review に必要な unchanged code はどの程度か。
AST-aware diff は full review や test の代替ではありません。ただ、agent の self-check input を「text fragment」ではなく「code structure」に近づけます。
Heatmap と search は history signal も見る
Skim は compression だけではありません。skim heatmap は git history から churn hotspot、blast radius、fix risk、bus factor、module health などの signal を抽出します。Sprint、recent N commits、recent days、full history などの window を指定でき、--insights で短い threshold-based finding だけを見ることもできます。
この情報は agent が変更を始める前に有用です。ある file が別 directory と頻繁に一緒に変更されていたり、fix commit density が高かったりするなら、agent は current file content だけを見るべきではありません。「ここは過去に壊れやすい場所か」「どの file が一緒に変わりがちか」を知る必要があります。
skim search は AST-aware search index を作り、--hot、--cold、--risky、--blast-radius FILE のような sort/filter を提供します。普通の full-text search は「この語がどこにあるか」を答えます。Skim はもう一段、「この file と歴史的に一緒に変わり、かつ関連しそうな場所はどこか」を見ようとしています。Large repository で context を選ぶときに効きます。
repomix、code graph、log compressor との違い
Skim を既存 tool と比べると、repomix のような repository packer そのものではなく、code graph memory server そのものでもありません。より shell に近い agent input filter と見るのが自然です。
repomix は repository を model に渡しやすい text package にする用途に強い。Code graph tool は symbol、call relationship、cross-session memory に寄ります。Skim の強みは、agent が毎日触る immediate input を広く扱う点です。File、directory、diff、test、build、lint、package manager、log、git status。唯一の context source になる必要はなく、shell に近い compression layer として差し込めます。
このため小さな team でも試しやすいです。複雑な service や database を先に導入する必要はありません。README では npx rskim、npm install -g rskim、cargo install rskim、Homebrew が案内されています。まず大きな file、失敗した test、一つの git diff に対して試せば、自分の workflow で noise が減るか判断できます。
残しておくべき疑い
Skim の README はかなり積極的で、多くの benchmark と token reduction の数字があります。Early-stage の小さな project としては、それらを universal guarantee ではなく、project author の baseline として読むのが安全です。Language、code style、test framework output format によって compression quality は変わります。
特に見たい risk は三つです。
- Semantic loss: structure mode が function body を隠すと、副作用、exception path、performance detail を見落とす可能性がある。
- Output over-trimming: test/build log compression が environment information を落とすと、debug direction が狭くなる。
- Command rewrite boundary: hook による automatic rewrite は便利だが、いつ raw output を見るかを team で決める必要がある。
つまり、Skim は default exploration layer として扱うのがよいです。Agent にまず compressed version を読ませて方向づけ、編集、debug、review の critical path では original file と raw log に戻る。この使い方が現実的です。
試すのに向いている人
Skim は次のような場面に向いています。
- AI agent に中大型 repository を頻繁に読ませ、exploration phase の token cost が重い。
- Test、build、lint、git diff output を agent が読みやすい形にしたい。
- Log 整理を毎回手作業でやるのではなく、command-line layer で圧縮したい。
- Project language が Skim の 17 supported languages に入っている。
- 補助 layer として使い、重要な場面では raw output で検証できる。
Project が小さい場合や、agent に単一 file をたまに読ませるだけなら、効果は小さいかもしれません。しかし Claude Code、Codex、Cursor、Gemini CLI などの command-line agent を頻繁に使っている team では、terminal output noise はすでに現実の cost になっています。
まとめ
dean0x/skim は注目に値する小さな Rust tool です。Agent workflow の素朴だが重要な問題を捉えています。Context window が大きくなっても、input quality は依然として重要です。Full code と full log を渡すことは、task をより理解させることと同じではありません。
Skim の価値は、context compression を engineering workflow に近い形で扱うところにあります。AST-aware source transformation、test/build/lint output compression、git diff rewriting、history heatmap、search ranking、hook integration。まだ early-stage で、検証と boundary awareness は必要です。それでも方向は良い。これからの coding agent には、より多い context だけでなく、より少ない noise、より強い structure、より明確な attention focus が必要になります。