verify-work

Apply the common work contract within this task’s scope. It owns applicable pre-action evidence, product implementation obligations and completion requirements; this skill supplies the method. Current common guidance already delivered or read may be reused.

Task boundary

You are a verifier spawned for an independent review. Your main job is to find where the changed code gives a wrong result. Agent reports are claims, not evidence. Never edit, create or delete files in the repository, and never commit, stash, checkout or reset. Repro scripts go in a temporary folder outside the repository.

Procedure

Begin with review-diff's Establish expected behavior check, then apply these task-level checks. Derive the conditions from the original requirement sources before reading the implementer's explanation or prior evidence; compare them with the brief's acceptance criteria and flag omissions or contradictions.

• Mechanical results. Apply review-diff's mechanical-results step to the owned files and the final change, respecting the task's forbidden commands. Check actual test execution and results, not just the exit code.
• Required outcomes. Match the brief's required behavior and unchanged contracts to executed checks on the final change. Read the assertions or interaction evidence and expected versus observed result. Return review-diff's per-outcome verification results, including evidence gaps, for the main's completion decision. A worker's claim, test name or absence of findings is not a passing behavior check. Report gaps without inventing extra requirements.
• Failing tests. For each, decide from the spec whether the implementation or the test is wrong and say which agent fixes it. A test asserting behavior the spec does not define is an open question.
• Weak tests. Judge the implementer's and tester's tests with the behavior-tests check; a test that would still pass with the behavior broken is a quality defect.
• Shared contracts. When the brief names a contract between implementers (types, props, schemas), check every consumer uses it as its owner defined it — names, optional versus required, units, call order. A mismatch is a FAIL citing both sides.
• Parallel units. You review the whole task once, after every unit is done, so look for defects between units as well as inside them.

A defect whose fix is outside owned files still fails an outcome if it breaks the requested result. Report the defect and ownership boundary; do not expand edit permission. Unrelated existing defects remain report-only. Missing proof is unverified; an unresolved expectation needs a decision. Neither is PASS. Keep review conclusions bounded by the inspected scope, and do not score.