Less noise, better context: RTK and code-review-graph

A coding agent can only work with the context it receives. Give it a wall of terminal output and it may miss the one line that matters. Give it a diff without the surrounding code and it may miss what the change affects.

I use two tools that help with different sides of that problem: RTK for command output and code-review-graph for codebase relationships. Neither decides whether a change is good. They help me and the agent find the information worth checking.

RTK trims what the terminal sends back

RTK sits between a development command and the agent reading its output. It filters, groups, or shortens results from commands such as git status, git diff, search, and test runners. A passing test suite can become a short count; failures remain visible. A long diff can be condensed so the changed files are easier to spot.

rtk git diff

This does not rewrite the prompt I give the agent. It reduces one source of input: command output added to the agent’s context. That distinction matters when talking about token savings. A shorter tool response does not mean the entire conversation, or the bill, shrinks by the same percentage. Prompts, history, and generated answers still take space.

The tradeoff is that a compact view can omit a detail I need. When a failure is unclear or a summary looks odd, I read the full output. Compression is useful for finding my way around; it is not a reason to stop looking closely.

code-review-graph keeps a map I can reuse

A diff tells me which lines changed. It does not automatically tell me which functions call them, which modules depend on them, or where the relevant tests live.

code-review-graph parses a repository into a local graph of code relationships. It stores that graph and updates it as files change. The next review can query the existing map instead of starting from a fresh scan of the entire codebase. Think of it as a reusable index, not a cache of review decisions.

For example, its CLI can show a compact view of the likely impact of changes against a base branch:

code-review-graph detect-changes --brief --base main

The graph can point a reviewer toward callers, dependents, and tests worth reading. That is especially helpful when a change crosses several files. The map can also be incomplete or imprecise, so its suggestions still need to be checked against the actual code and relevant tests.

Different jobs, one review loop

Here is one way to use them together when reviewing a change:

1. Start with the task and the diff. Check what the change was supposed to do, then use RTK to get a compact first look at the working tree and diff.
2. Follow the connections. If the change touches code used elsewhere, use code-review-graph to find nearby callers, dependencies, and tests that may matter.
3. Read the source. Open the relevant files, including the full diff or raw command output when the compact view leaves a question unanswered.
4. Verify the behavior. Run checks and try the important user flow. A graph can suggest where to look; it cannot prove the result works.

The point is not to feed the agent as little as possible. It is to give it less noise and better bearings. RTK makes command results easier to consume. code-review-graph makes code relationships easier to revisit. The final decision still depends on understanding the task and checking the change.

---

Sources: RTK documentation and code-review-graph documentation. The workflow example is illustrative; it does not claim a measured token saving or a specific setup across Claude, Codex, and Cursor.