Copy a review skill from one project into the next and you have not reused it, you have forked it. Both copies carry the same engine underneath: how scope gets resolved, how a finding is checked before it reaches you, what the report looks like. Improve one and the other keeps running exactly as it was, a version behind and quiet about it.

a-review-core is that engine, kept in one place. A review skill built by a-review-optimizer opens by reading it, then adds only what is true for its own project: the dimensions worth reviewing, the false positives already ruled acceptable, the preflight script, the thresholds.

You never run this one. It has no command and it will not fire on its own. It is read at runtime by the skill you generated, which is the entire point: the mechanics stop being a copy you own and start being something you get fixes from.

What lives in here is the part that does not vary by codebase. Scope resolution, and what counts as in scope for a diff. The preflight protocol, so deterministic checks run first and a model spends its attention on what a tool cannot answer. Dispatch across parallel agents with non-overlapping briefs. The verify step that decides whether a finding is confirmed, plausible or refuted before you ever see it. The finding contract, the report shape, and how findings get captured so a later pass can learn from them.

What does not live in here is anything about your project. That is the overlay's job, and the split is what lets the engine improve underneath a skill somebody tuned six months ago.

Ships in the dev-workflow-forge plugin, alongside a-review-optimizer, which writes the overlay that reads this.

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.