a claude code skill

Your assistant forgets
it did this before.

Every session it repeats the same fix, the same lookup, the same multi-step procedure by hand, because nothing remembers doing it. toolsmith reads its own transcripts, finds what keeps repeating, and hands you a short, cited list of tools worth building.

install

❯curl -fsSL https://raw.githubusercontent.com/jah2488/toolsmith/main/install.sh | bash

Piping a script into a shell deserves a look first. Read it here.

you approve, always cites the exact line three tools, worst first

mine.py --current

❯python3 mine.py --current RECALL read CODEOWNERS 4x afa0473f:118, :204, :311, :402 FRAGILE flaky API call, retried 3x 943798b5:236 CHAIN status → stash → rebase → pop, 3x afa0473f:520 REPEAT gh pr view, 6x this session 943798b5:88 3 candidates ranked. go read the lines.

how it finds the repetition

It reads the transcripts, not a guess.

Ask an assistant what it did an hour ago and you get its best guess. In a long session, most of the detail is already gone.

toolsmith skips the guessing. It reads the real session transcripts and returns four signals, each pointing at the exact session and line it came from, so you can check any of them yourself in ten seconds.

It counts shapes, not intent, so nothing here is a verdict. Every result comes with a way to check it, not just a claim.

Run it on the current session, the last week, or a different project: --current, --days 7, --project <path>.

four signals

What repeats, and what it usually means.

Each signal is a different shape of wasted effort. Only one of them earns a tool on frequency alone.

RECALL

Same file, read again and again.

Your assistant re-checked a fact it should have only needed to look up once.

FRAGILE

A command that errored, then got retried.

Something tripped it up once already, and will trip it up again without a fix.

CHAIN

The same ordered steps, run more than once.

A routine done by hand repeatedly, where any step in the middle can quietly break it.

REPEAT

A command shape that keeps coming up.

Only earns a tool if the command is easy to get wrong without one.

toolsmith won't build for a one-off, something an existing tool already covers, a step that needs judgment in the middle, or a generality nobody asked for. It says so and moves on. A rejected candidate with a reason is a good outcome.

rank by cost

The worst offender surfaces first.

Not every repeat deserves a tool. This is the order they're judged in, most expensive first.

A fact you already paid to re-check

Something got stated from memory or a doc, then had to be re-derived from source anyway. The fix is a script that always prints the real answer, so nobody has to trust a memory again.

the biggest win, by a distance

A command that already broke once

The fix is a wrapper with a preflight check and the correct invocation built in, so it can't fail the same way twice.

A routine done by hand more than once

Three or more steps repeated. The fix is one command that checks each step before moving to the next, so nothing gets left half done.

Everything else

Worth a tool only when the command takes arguments people get wrong, or nobody would remember the exact incantation without it.

propose, then build

At most three. Worst first. You pick.

Nothing gets built until you choose one. Every candidate reports in the same fixed shape, so comparing them costs nothing.

proposal

check-codeowners print the owning team for a path, from source evidence 3x across 2 sessions, afa0473f:118, 943798b5:236 today CODEOWNERS gets read by hand and misquoted from memory next time guarantee the answer always comes from the file, never a stale recollection cost one script, no new dependencies, ~20 lines

Once you pick one, it gets built small: a fix for one repo goes in bin/<verb>, something useful everywhere becomes a skill, and analysis that isn't really a tool goes in .agents/docs/ instead. Every tool it builds is deterministic, prints its own evidence, is safe to run twice, and fails loudly when something's actually wrong.

prove it before claiming it

A gate you've never watched fail is not a gate.

Before you see a proposal, toolsmith runs the tool once against the real case that motivated it and pastes the output. Then it removes the condition and checks that the tool goes quiet or fails on its own.

If it can't produce that failing run, it calls the tool unverified instead of claiming it works.

Every tool ships with what it does in one sentence, when to reach for it, what a failure means, and how to check its answer by hand yourself. So whoever picks it up next doesn't need this session to understand it.