StackMap
Subscribe
Explore / ripwire
redhat-et

ripwire

Red Hat's 'ripgrep of AI context': a zero-dependency C++23 CLI + MCP that hands a coding agent a ranked call graph — what to touch, blast radius, tests to run — with no index server.

1,870 111 C++ Apache-2.0updated yesterday
View on GitHubDispute this mapping →
Curator's take

Reach for this when you want code-context for an agent with the operational profile of ripgrep: one static binary, indexes a repo in well under a second on a few MB, no daemon, no embeddings, no API key — and it ships skills that tell Claude Code/Codex/Cursor/aider *when* to call it. The `--for="<change>"` mode (rank by intended change, then blast radius + tests-to-run + McCabe/Halstead quality deltas) is the differentiator over plain symbol graphs. Prefer the CLI; the MCP schema costs context every session. Not for you if you need a persistent, queryable graph across repos, natural-language-to-Cypher, or semantic search — it is deterministic and lexical/structural only.

Mapped by ShipWithAI editors · links verified

Continue your stack

What teams reach for next — and why each earns a place beside ripwire. Ranked by curator confidence.

pairs wellalternativealternativealternativealternativealternativealternativertkcode-review-graphgortexcodebase-memory-mcpcodegraph-mcptokensaverepowiseripwire
pairs wellalternativebuilt withpick a node for the why · open it from the panel
Weekly digest
README.md2 min read

ripwire — the ripgrep of AI context

CI Release Licence Standard Runtime dependencies Slides

Rip'n Fast. Fewer Tokens. Better Code.

The ripgrep of AI context. Give your coding agent a map before it reads the repo.

Point it at any repository and your agent gets a ranked, deterministic call graph — what to touch, what it breaks, which tests to run — instead of grepping around and reading whole files.

Paddle out with a map.

Fifty years of software-engineering results, and research from last month. 46 repositories and 69 papers folded — McCabe (1976) through to seven published in the last two months — each row in docs/LINEAGE.md naming the lesson taken and the file it lives in

Beside those sits a labelled survey of 237 tools that contributed nothing and says so. The two sets are disjoint by construction, so they add rather than nest — a tool that gave a lesson is never counted twice.

Both halves are load-bearing, and they are doing different jobs. The settled results are what make the quality lens trustworthy: McCabe on complexity (1976), Halstead on volume (1977), Spärck Jones on term specificity (1972), Nagappan & Ball on churn. Fifty years of replication means those are not opinions, and a tool that measures your code should be built on the ones that survived.

The recent work is what makes it current: seventeen of the folded papers are from 2026, seven published in the last two months and three in the last thirty days (dates as of 2026-09-08; every row carries its arXiv id, so the claim is checkable rather than atmospheric). Retrieval for coding agents, context-compression cost, placebo-controlled localization — that literature is months old, not decades, and several rows were folded within weeks of the paper appearing.

Neither half alone would be enough. A tool built only on the classics would not know what an agent needs; one built only on last month's preprints would have nothing underneath it. And the newest row is a result that failed when it was tested here — which is the point of writing them down. All three counts are re-derived from that document's own tables by test/readmedriftcheck.sh on every run, which fails if this page and those tables disagree, so the claim cannot quietly drift. The row-by-row ledger is docs/LINEAGE.md.

Languages: Rust · C++ · Objective-C/C++ · C · Metal · CUDA · Python · Go · Swift · TypeScript · JavaScript · Java · Ruby · PHP · Lua · Elixir · Dart · Bash · C# · JSON · TOML · YAML · Markdown — see language support and limits.

No API key. No embeddings. No index server. No daemon.

One process, no server — indexes this repository in 0.25 s using 6.6 MB, against 46.8 s and 391 MB for the graph-database MCP server it was measured against; warm queries answer in 197 ms to its 1,082 ms

Measured on 48 matched questions across django, webpack and this repository. Across all three, ripwire indexes in 0.25–0.45 s and 6.6–16.5 MB against that