Quiet Power Tools

The tools in this cairn are not load-bearing for the team’s workflow. You can ship perfectly good production work without them. They earn their keep over a quarter rather than a session — token bills that quietly drop, output noise that quietly disappears, scripts that quietly get faster. None of them is dramatic. All of them compound.

This is the shortest cairn in the trail on purpose. Skim once now, and revisit when the day arrives that you find yourself piping shell output through head -100 to keep an agent from drowning, or noticing that your token spend on git status has a meaningful line item.

RTK

RTK is a token-cheap proxy for routine commands. Once installed, the Claude Code hook silently rewrites things like git status, git diff, npm run, and ls -la into rtk git status, rtk git diff, and so on. The output going back into your agent’s context is dramatically smaller — RTK strips noise that the agent does not need (color codes, repeated headers, paths the agent already knows) and keeps what changes turn over turn.

The savings are measurable. rtk gain reports cumulative token savings since install; on a typical week of agent-assisted work, the team sees 60–90% reduction on the operations RTK covers. That is not the total token spend dropping by 60–90% — it is the dev-op surface, which is a meaningful slice. Over a quarter, the difference shows up as both lower bills and longer-useful context windows.

A name-collision note, in passing: a separate tool called rtk exists in the Rust ecosystem (Rust Type Kit). If rtk gain fails with a “command not found” or unexpected output, you have the wrong binary. The fix is which rtk and a brief reordering of PATH. We mention it once because every new install hits it; we are not going to belabor it.

tokf

tokf is a per-project token filter — a more configurable, lighter-weight cousin of RTK. Where RTK is zero-config and broad, tokf gives you per-project rules for trimming output, redacting noise, and shaping what flows back to the agent. Strike does not lean on it heavily yet; we mention it because the day will come.

The signal that tokf is worth setting up is recognizable. You will know it when you find yourself piping a recipe’s output through head or grep to fit it into the agent’s context, or wishing you could redact a chatty log line that adds nothing useful. tokf is the place to put that filtering once, in a config file, instead of in every session.

When (or if) we adopt tokf in earnest, expect a follow-up cairn or an update to this one with concrete patterns. For now: it exists, it is good, it is not a day-1 install.

CLI multipliers

A handful of POSIX-tool replacements are individually small wins and collectively a meaningful upgrade. Most of the team has all of these installed; many of them auto-activate via the dm-work:cli-tools skill if you have that plugin loaded.

You do not need all seven on day one. Install fd and rg first; both are universal upgrades and pay for themselves on the first session. Add jq when you write your first gh api invocation. Add the rest as you find friction with the POSIX tool they replace.

Why these compound

Every command an agent runs sends its output back into context. That output costs tokens, occupies attention, and shrinks the room available for the actual work. A tool that produces less noise per command is, in effect, a tool that lets the agent do more work per session.

The compounding is real but invisible per command. Saving 200 tokens on git status is meaningless. Saving 200 tokens on every git status over the course of a week is a meaningful slice of the working budget. The same logic runs for rg over grep -r, bat over cat, delta over plain diffs, and so on.

The other reason to install these tools: they are also better for you, the human, when you reach for the command line directly. The token savings are the agent’s win; the friction reduction is yours. Both halves are reasons to put them on your machine.

Summary

1. RTK is the headliner. Zero-config, broad coverage, 60–90% token reduction on the dev-op surface. Run rtk gain at the end of your first week to see the number.
2. tokf is the configurable cousin. Lighter mention; not heavily used in Strike yet. Reach for it when you find yourself piping recipe output through head.
3. CLI multipliers are individually small, collectively meaningful. fd, rg, jq, yq, sd, bat, delta. Start with fd and rg; add the rest as you find friction.
4. The benefits compound, not impress. Don't expect a per-session "wow." Expect a quarter-end "where did all this extra capacity come from."

• The pitch for these tools is "compound benefits over a quarter." That is honest but unmotivating in the moment. What would a more compelling sell look like — a measurement, a demo, a specific scenario?
• The CLI-multiplier list is opinionated and incomplete. Which tool would you add as a load-bearing part of your own loop, and what does it earn its slot for?
• RTK works because it can guess what an agent does and does not need from each command's output. What command's output would benefit most from a more aggressive filter than RTK applies by default — and what would you risk losing by filtering it?

1. How We Build Here — The trail's opening cairn. The argument that "the typing is now the cheapest part of most days" is the framing under which token-efficiency tools earn their place.
2. The Workshop — The trail's tool map. RTK, tokf, and the CLI multipliers all sit in the optional layer; this cairn is the deep read on that row.
3. Claude Code as Daily Driver — The harness cairn. The token-context discussion there is what makes tools that shrink output worthwhile.
4. RTK — Source, install instructions, configuration. The headline tool of this cairn; install it on day one if you can.
5. tokf — Source, install instructions. The configurable filter; reach for it when RTK is not enough or you want per-project rules.
6. fd — Faster, friendlier find. Universal upgrade.
7. ripgrep — Faster, friendlier grep -r. Universal upgrade.