Review tooling gets passed around like a library, and it is not one. A review skill tuned to a PHP MVC app has nothing useful to say about a Rust CLI. It flags patterns your project settled three years ago, misses the mistakes you actually make, and after a week of false positives you stop reading its output.
a-review-optimizer reads the codebase in front of it and writes the review skill for that codebase.
What it produces is a *-review skill with parallel agents whose scopes do not overlap, so two of them are not both reporting the same finding in different words. A deterministic preflight script that runs your real linters and type checker first, so the model spends its attention on the things a tool cannot check. Output shaped so a fix pass can act on it directly. And extra modes where the project earns them, like a tech-debt score or a full-codebase sweep.
What it writes is an overlay, not a fork. The generated skill carries your project's context and reads a shared engine for the parts true of every codebase: how scope is resolved, how a finding is verified before it reaches you, what the report looks like. Those improve underneath it without you regenerating anything. A forked engine means a fix reaches whichever copy someone remembered to update, which is how a review skill quietly falls behind the one it was copied from.
It can also check its own work. Plant a set of known defects on a scratch branch, run the review over them, and score what it caught and what it invented, so "the review got better" is a number rather than an impression.
It edits rather than replaces. If you already have a review skill, it keeps what works and changes only what a concrete gap, a real false positive, or an actual scope collision justifies. A generator that overwrites your tuning every time you run it is a generator you run once. This one is meant to be run again in six months, when the codebase has moved.
That is also why it asks about your false positives. A check that keeps firing on something you decided on purpose is not a finding, it is noise, and the fix is to teach the skill the decision.
Ships in the dev-workflow-forge plugin, alongside a-rules-optimizer, a-self-learner and the shared review engine the generated skill reads. Run this one first on a new project: the other two are more useful once a review skill exists to cross-reference.
/plugin marketplace add imisic/claude-marketplace
/plugin install dev-workflow-forge@imisicThen the command is /a-review-optimizer.
Everything mine on this shelf comes from my own working setup, shared for learning. Test it and adapt it to your project before relying on it; you run it at your own risk.