verifying-acceptance-criteria

Provide the acceptance criteria source and implementation evidence such as code changes, screenshots, API responses, or a running URL. Each criterion is normalized to a stable ID, assigned a verdict of Met, Partial, Not Met, or Untestable, and backed by cited evidence.

A verification matrix is a table mapping each atomic criterion ID to its status, supporting evidence, and follow-up notes. It ends with counts per status and a sign-off view grouping criteria into Ready, Needs follow-up, and Needs clarification.

Vague or ambiguous criteria are marked Untestable rather than being silently interpreted. The Skill flags them for upstream clarification instead of inventing expected behavior, keeping ambiguity visible in the readiness summary.

No. Partial is an explicit, valid status used when only some of a criterion is implemented. Treating a near-miss as complete is listed as a common failure mode, and partial items are grouped under Needs follow-up.

Three inputs are required: the acceptance criteria or equivalent source of truth, implementation evidence such as code, UI, API behavior, logs, or test results, and the environment or build under review. If either side is missing, verification pauses until it is provided.