verify

To verify a security finding against the current codebase HEAD, the Skill reads a finding_id from context.json, fetches reproduction steps from the scrutineer API, and re-runs them exactly as described. It outputs a structured report classifying whether the issue still occurs or was fixed.

Re-running a security audit reproduction involves fetching the original six-step validation prose for a finding and executing only those exact steps against the repository HEAD. This determines if the dangerous behavior described in the finding still occurs in the current codebase state.

Yes, you can check if a vulnerability finding has been fixed by re-running its validated reproduction against the repository HEAD. The verification process compares the current codebase state against the original finding's location and CWE to output a status confirming if the risk is ongoing or resolved.

You reproduce a security finding by fetching its title, severity, location, and six-step reproduction prose from the scrutineer API using a finding_id. The verification follows only the exact steps described in the validation field to determine if the dangerous behavior still occurs.

A key limitation is that verification strictly follows the exact steps described in the finding's validation field and only those steps. If the codebase has changed significantly since the finding was created, the re-run may classify the result as could not be reproduced rather than confirming a fix.

Yes, a context.json file containing the finding_id is required to classify whether a security issue still occurs. The Skill reads this identifier to fetch the necessary finding metadata, CWE, and reproduction steps from the scrutineer API before executing the validation against the repository HEAD.