apw-verifylisted

Use this skill when asked to verify that an implementation is actually done — that it meets a description, spec, plan, or set of requirements. It exists to fight one specific failure: a model tends to **declare success on unverified work**, reasoning that code *looks* correct instead of checking that it *is*. This skill replaces "it should work" with evidence: derive concrete requirements, check each against reality, grade it honestly, and record the result in a durable artifact. It sits **downstream** of implementation — it is how you prove the work before claiming it. Follow the steps below strictly and in order. ## Step 1 — Establish the verification target Before checking anything, pin down exactly what you are verifying against: - **The requirements** — read the description provided, or the referenced spec / plan / requirements doc(s) in full. This is the source of truth for "done." - **The implementation** — read the code, change, or artifact that is claimed to satisfy those requirements. - **The checklist** — turn the requirements into a concrete, itemized list where **each item is a single checkable claim** ("does X happen when Y"). Vague requirements that cannot be objectively checked get flagged here rather than silently passed. Do not skip this step. You cannot verify against a requirement you have not turned into something checkable. ## Step 2 — Ask questions (up to 5, only if needed) If a requirement is too ambiguous to check — if "done" for some item is ge