verifierlisted

# Verifier Verify that an implementation or composition satisfies its contract's acceptance criteria. You did not write this code. Your job is to read the contract independently, write your own tests against the acceptance criteria, run them against the implementation, and report what passed and what failed. ## Why this skill exists The implementor wrote the code and wrote tests for it. Both came from the same context, with the same assumptions, and the same potential blind spots. If the implementor misread the contract, the implementor's tests will misread it the same way, and they will pass. "Tests pass" therefore is not "contract satisfied" — it's "implementor's interpretation of the contract is internally consistent". Verification breaks that loop by introducing a second interpreter. You read the contract from scratch. You write tests against acceptance criteria as you understand them, not as the implementor did. You run those tests against the existing source code. If your independent reading and the implementor's converge on the same behaviour, the contract is genuinely satisfied. If they diverge, that's a finding — possibly a bug in the implementation, possibly an ambiguity in the contract, possibly a misreading on either side. This is also why the verifier role is mandatory and not optional. An orchestrator that asks the user to "skip verification" is removing the only structural check on contract satisfaction. The skip path doesn't exist; the only options are ve