# The Claude Code tools I'm sharing

**Author:** Ivan Misic  
**Published:** 2026-07-06  
**URL:** https://ivanmisic.net/blog/ai-tools/claude-code-tools-im-sharing

> I built a toolshed of Claude Code tools, generators, rule packs, scanners, and put it where you can grab them. Here's what's on the shelf and how to use it.

I started with Claude Code in October 2024, and since then I've been learning, building, and adapting a set of tools around it. Every project I run picks up a review command, a fix command, a set of rules that teach Claude the house style. They took real work to get right, and until this week each one lived in exactly one place: the repo it was built for.

So I did the obvious thing and pulled the reusable ones into a spot where anyone can get at them. I call it the toolshed. It's a shelf on my site with the Claude Code tools I've actually built and used, packaged so you can drop them into your own setup.

This is a tour of what's on the shelf, how I actually use the pieces, and the exact commands to get them into your own setup in a few minutes.

## What's on the shelf

The shed sorts into a few kinds. Here's the whole inventory before I get into the parts worth talking about.

| On the shelf | What it is |
|-|-|
| [Generators](/toolshed/plugins/dev-workflow-forge) | Point one at your codebase and it writes a review skill, a rules set, or a self-learning loop fitted to your project |
| [Everyday loop](/toolshed/plugins/dev-loop) | `fix`, `commit`, and `ship` commands that run the day-to-day cycle, portable as they are |
| [Anti-slop scanners](/toolshed/plugins/unslop) | Three of them, catching the tells that make prose, code, or UI read as machine-written |
| [Rule packs](/toolshed/rules/generic-rules) | Downloadable `.claude/rules/` sets: a generic baseline plus [PHP](/toolshed/rules/php-rules), [Python](/toolshed/rules/python-rules), [React](/toolshed/rules/react-ts-rules), and [Flutter](/toolshed/rules/flutter-rules) |
| [Leak scanner](/toolshed/skills/sanitize-public) | Checks an artifact for secrets before it ships, and had to be de-leaked itself first |

None of this is a product. It's the stuff I use, some of it daily, some only when the job calls for it, cleaned up enough to hand over. The anti-slop scanners are the newest addition; I'm still exploring what they catch and tightening them as I go, so treat those as a work in progress that already earns its keep.

## The naming system behind it

Part of the point of sharing this is showing how I keep a growing pile of tools usable, so here's the system.

Anything I use across every project gets an `a-` prefix: `a-review-optimizer`, `a-sanitize-public`, and so on. Two reasons, both boring and both load-bearing. The `a` puts my own tools first in any alphabetical listing, and it marks a tool as mine and portable at a glance. When a list of skills scrolls past, I know instantly which ones travel with me.

Anything tied to one project gets a short project prefix instead. For this site that's `im-`, my initials, so the review command here is `im-review`. Overkill for a single repo? Probably. But the moment a setup grows a backend, a frontend, and an app, each with its own review skill, and a parent-level agent can see all of them, the prefixes are what keep one project's `review` from colliding with another's. Complex setups get there faster than you'd think.

That habit is also what made sharing cheap: when it was time to pick what goes public, the `a-` list was the shortlist. Those tools were built portable from day one. Everything else stayed home.

## Why I share the generator, not my copy

Here's the decision that shaped everything. When I first thought about sharing my review command, I assumed the command was the thing to share. It isn't.

My review command is good because it's specific. It knows my controllers, my service layer, the exact mistakes I've made and told it to stop repeating. That specificity is the whole value, and it's also what makes it useless to you. Your project isn't mine.

So for the project-tuned tools, I share the [generator](/toolshed/plugins/dev-workflow-forge) that produces them. You point it at your repo and get your own review skill, fitted to your code, with none of mine in it. The rules generator works the same way. The portable pieces, the [everyday loop](/toolshed/plugins/dev-loop) and the [role lenses](/toolshed/plugins/role-lenses), ship as they are, because they never knew anything about my projects to begin with.

![One a-review-optimizer generator producing review skills fitted to PHP, Python, and Rust projects](/images/blog/ai-tools/review-skill-generator-outputs.png)

And this isn't a one-time setup. I've started calling the generators my godfather skills: they set up a project's tooling at the start, then keep showing up to correct it. Every few weeks on a fast-moving codebase, monthly elsewhere, I re-run them, because the code evolves and the review skill and rules drift behind it. A re-run reads the project as it is now and pulls the tooling back in line. If you take the generators, plan for that rhythm; the first run is the smallest part of the value.

The tradeoff is honest. A generator is more work to build than a file you copy, and it's only worth having if it produces something good. When it works, though, the fit problem disappears. There's nothing of mine for you to find and delete, because the output was made for your project from the start.

## What rule files buy you

Rule files are the simplest thing in the shed with the biggest payoff, so let me say plainly what they do.

A rules file is plain language in `.claude/rules/` that tells Claude how your project does things: what to always check, which patterns to follow, what never to touch. Claude reads the matching rules every time it touches a matching file, so your standards get applied on every edit instead of living in your head and being re-typed into every prompt. I use them to keep things in line: security checks that always load, style and architecture rules scoped to the file types they govern. Write them like instructions to a new team member and they work. If you've never set rule files up, I went deeper in [teaching Claude your standards with rule files](/blog/ai-tools/teaching-standards-with-rules).

One mechanical note: the [rule packs](/toolshed/rules/generic-rules) ship as downloads, not plugin installs. A Claude Code plugin can load commands and skills into your session, but it has no business writing files into your repo, so rules can't install themselves, which is the right call. Take the generic pack, add your language pack, drop the files into `.claude/rules/`, adjust the path globs to your layout. And if you'd rather not hand-tune anything, that's exactly what the rules generator is for.

## How to actually use this

If the shelf sounds abstract, here's the concrete version. Everything installs in one of two ways.

Plugins (the generators, the everyday loop, the scanners, the role lenses) install through Claude Code's plugin system. Two commands:

```
/plugin marketplace add imisic/claude-marketplace
/plugin install dev-workflow-forge@imisic
```

Swap the plugin name for whichever one you want. Claude Code copies it onto your machine and the commands show up in your session.

Rule packs skip the install entirely: download the pack from its toolshed page, copy the `.md` files into your project's `.claude/rules/`, adjust the globs, done.

Every [toolshed](/toolshed) page shows the exact install command or download button plus a file-by-file view of what's inside, so you can read everything before you grab it.

## The scanner that caught itself

One short story from the packaging, because it's the mistake worth passing on.

Before anything leaves my machine, it runs through a [leak scanner](/toolshed/skills/sanitize-public) that greps for the usual giveaways: private keys, tokens, internal hostnames, home paths, and my own list of client codenames. I pointed it at the whole batch. Then, on a whim, I pointed it at itself.

It was the worst offender in the set. To catch my private terms, it had them hardcoded. The list of client names it existed to find was sitting right there in its source, so shipping the scanner would have published the exact inventory it was built to protect. The guard at the door had the keys taped to its back.

> A tool that handles secrets isn't exempt from leaking them. It's the likeliest thing in your kit to do it, because the secrets are its whole job.

The fix was to split it. The shared version carries only generic patterns anyone would want (key shapes, token formats, private IP ranges), and my actual private terms live in a local file it reads at runtime and never ships. Full coverage for me, generic coverage for everyone, and my list stays mine.

## Take what's useful

That's the shed. Generators that build tooling around your code instead of mine, the everyday commands, the anti-slop scanners, rule packs by language, and a leak scanner that has learned some humility.

It's all on the [toolshed](/toolshed), free, no sign-up, take what's useful and leave the rest. And it goes both ways: if you take something and make it better, or you've solved the same problem differently, I want to see your version. That trade is how these get good.

Fair warning: I packaged all of this over one weekend, so there will be rough edges I haven't hit yet. If something is unclear, broken, or just wrong, tell me and I'll fix it. Questions are welcome for the same reason; half the point of sharing is finding out what doesn't survive contact with someone else's setup.

None of it needs my repo to work in yours, which was the whole point. If you've already built your own [reusable commands](/blog/ai-tools/creating-reusable-recipes), you know how good it feels when one just works. This is me putting mine where you can reach them.