apw-reviewlisted

Use this skill to critically review your own work — a diff, a plan, or a conclusion — *before* presenting it as final. It exists to fight one specific failure: a model is **biased toward its own output**, so once it has produced something it tends to defend and rationalize it rather than attack it, and a quick "looks good to me" ships the flaw it just authored. This skill forces the opposite posture: drop the author's defense, assume the work is flawed, and hunt for *how*. It reviews the **reasoning** — the assumptions, the missed alternatives, the weak logic, the unconsidered case — which is a different job from proving the work runs (`apw-verify`) or building it (`apw-implement`). It sits **downstream** of producing something and **upstream** of presenting it. Follow the steps below strictly and in order. ## Step 1 — Establish the review target Before critiquing anything, pin down exactly what is under review: - **The artifact** — the specific diff, plan, conclusion, or claim being reviewed. Name it concretely (a set of changed files, a written plan, a stated finding like "the bug is in the cache layer" or "this is done"). - **The central claim** — what the artifact is asserting is true or correct ("this change fixes X", "this is the right approach", "this conclusion follows from the evidence"). This is what you will try to break. - **What would make it wrong** — the conditions under which the claim fails. If you cannot state how the work *could* be wrong, you cannot rev