← Back to the workbench

Developer tools

ctx

A local toolkit that gives coding agents a place to begin in an unfamiliar repository.

RustContextCLI

ctx helps a coding agent find its bearings. Give it a task, a base branch, or a test log, and it gathers likely files and useful excerpts into a small packet.

The packet can include a map of the repository, recent changes, and the failure buried in a long test log. It shows how strong the matches appear to be and includes commands for looking further. The agent still has to read the code and decide whether the lead is useful.

ctx runs as one Rust binary on the local CPU. It makes no model calls and needs no network service. It selects files through Git, excludes credential paths, removes known secret patterns, and keeps the output within the requested size. When the matches are weak or a test result cannot be read, it says so.

How it works / Explore the workflow

Finding a place to begin

ctx starts with the task and files known to Git. It gathers likely files, excerpts, and commands for looking further, leaving out credential paths. Weak matches are flagged. The agent can follow a lead or look elsewhere.

Follow the thick line down the middle column, one ctx pack request from goal to packet. Solid orange boxes are checks or guards. The dashed path on the left is the lexical baseline used in studies. Dated notes record what the evidence changed. Open full size ↗

Learnings

A useful clue changes where someone looks. A bad clue does the same thing. That makes context selection more consequential than shortening a prompt. A packet can save reading while sending the agent toward the wrong part of the code. One version of ctx did exactly that, turning suggested files into an order of investigation the agent followed too closely.

I want a context tool to make its uncertainty usable. It should show why a file looks relevant, admit when the match is weak, and leave the agent free to search elsewhere. The packet is the beginning of an investigation. Its usefulness depends on what happens after it is read.

That is also the difficult part of evaluating it. Finding files that appear in the final patch is a convenient measurement, but the agent may already know how to find them. A simple word-matching method did well on that measure. Later task runs had too few successes to establish an effect on solving the work. To learn more, we need to observe how the agent uses the clues and what changes as a result.

Explore the other projects →