I put the Claude Code tools I reuse across projects into one public toolshed: project-specific generators, everyday workflow commands, anti-slop checks, search visibility, rule packs, and prompts. Some tools install as they are. Others generate a version for your codebase, because copying mine would miss the point.
What's on the shelf
The Claude Code side currently has eight standalone skill pages, six installable plugins, five rule packs, and a growing prompt shelf.
| On the shelf | What it is |
|---|---|
| Project tooling generators | Three skills that write or improve a review skill, a rules set, and a self-learning loop fitted to your project |
| Everyday loop | fix, commit, and ship commands that run the day-to-day cycle, portable as they are |
| Anti-slop scanners | Three of them, catching the tells that make prose, code, or UI read as machine-written |
| Search visibility | Two skills: one turns a Search Console export into a ranked action plan, while the other checks whether AI assistants can reach, understand, and cite your site |
| Role lenses | Six senior-review viewpoints that argue from a specific role instead of agreeing with everything |
| Public-release safety | Checks an artifact for secrets before it ships, and had to be de-leaked itself first |
| Rule packs | Downloadable .claude/rules/ sets: a generic baseline plus PHP, Python, React, and Flutter |
| Prompts | Copyable starting points from the articles, plus a-make-prompt for turning a rough request into a finished prompt |
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 collection keeps changing as I find another repeated job worth packaging or a weak spot in something I already shared.
The naming system behind it
The list keeps growing, so I needed a naming system.
Anything I use across every project gets an a- prefix: a-review-optimizer, a-sanitize-public, and so on. Two reasons, both boring. 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 skill here is im-code-review. Overkill for a single repo? Probably. But the setup grows fast: a backend, a frontend, an app, each with its own review skill. A parent-level agent can see them all. That's when the prefixes 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
I share the generator, not my finished setup. 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 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 and the role lenses, ship as they are, because they never knew anything about my projects to begin with.
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, you no longer need to strip my project out of the result. 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.
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. Rules without a path scope load when the session starts. Path-scoped rules load when Claude reads a matching file, so a PHP rule does not need to sit in the context while you edit CSS. 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.
Rule packs are downloads, not plugins, because they need to live in your repository. The plugin installer copies a plugin into Claude Code's cache; it does not merge a rules pack into your project's .claude/rules/. Take the generic pack, add your language pack, drop the files into .claude/rules/, adjust the path globs to your layout. If you'd rather not hand-tune anything, that's exactly what the rules generator is for.
How to actually use this
There are two ways to install the tools covered here.
Plugins install through Claude Code's plugin system. Add the marketplace once and install what you need:
/plugin marketplace add imisic/claude-marketplace
/plugin install dev-workflow-forge@imisicSwap the plugin name for whichever one you want. If the install summary says the plugin is already active, continue. If it says Run /reload-plugins to activate., run that command.
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.
Plugin pages show the exact install command and a file-by-file view. Rule-pack pages pair the file view with a download button, so you can read everything before you grab it.
The scanner that caught itself
The leak scanner found its first real problem in its own files.
Before anything leaves my machine, it runs through a leak scanner 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.
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. The public scanner catches the general leaks. My private list stays local.
Take what's useful
It's all on the toolshed, free, no sign-up, take what's useful and leave the rest. If you improve one of these, send me your version. That trade is how these get good.
This started as one weekend of packaging. Now it is six plugins, eight reusable skills, and a separate prompt shelf. There will still be rough edges, so if something breaks in your setup, send me the case.
Sources
- Discover and install prebuilt plugins through marketplaces, Anthropic. Documents marketplace installation, activation summaries, and when
/reload-pluginsis required. - Plugins reference, Anthropic. Supports the claim that marketplace plugins are copied into Claude Code's local plugin cache.
- How Claude remembers your project, Anthropic. Supports
.claude/rules/, unconditional rules, path-scoped rules, and their trigger behaviour.
Get Personalized Help
Copy this prompt to ChatGPT, Claude, or your favorite AI assistant. Fill in your details and get guidance tailored to your specific situation.
I'm using https://ivanmisic.net/blog/ai-tools/claude-code-plugins to choose the smallest useful addition from Ivan's toolshed for one project. My context: - Project and stack: [LANGUAGES, FRAMEWORKS, AND REPOSITORY SHAPE] - Repeated problem: [WHAT KEEPS GOING WRONG OR TAKING TOO LONG] - Current agent setup: [RULES, REVIEW SKILL, FIX OR COMMIT COMMANDS, OR NONE] - Outcome and maintenance appetite: [ONE-OFF HELP OR A TOOL I WILL RE-RUN] Use the article's distinction between portable plugins, project-specific generators, and repository rule packs. Ask for any missing fact that would change the choice. Recommend one of three outcomes: install nothing, use one portable tool or rule pack, or run one generator against my project. Name the single best starting point, explain why it fits, and say what I should not add yet. Give me: 1. the files, permissions, and existing project guidance to inspect before changing anything; 2. the current install or download path from the tool's own page; 3. the project-specific setup or adaptation required; 4. one small test that proves it helps the repeated problem; 5. a re-run cadence only if the chosen generator can drift behind the codebase. Do not copy Ivan's project-specific review or rules setup into my repository. Check the current toolshed or source repository and official Anthropic plugin or rules documentation before giving commands. Link what you verify and state what remains unknown.