Review with evidence, not a safety stamp
You will request findings, verify a reproduction and distinguish local review from hosted review or a security scan. Outputs are illustrations.
Official sources checked September 30, 2026 describe several review products with different scope, setup and costs. A report saying “no findings” does not prove absence of bugs or permission to publish.
Start with a bounded local review
Use the verified practice diff. A normal review request can be enough without installing a plugin or starting a premium review.
Review only this practice index.html change; do not edit.
Check toggle behavior, keyboard activation, aria-expanded and preserved source text.
For each finding: file/element, evidence, reproduction steps and consequence.
Separate confirmed issues from hypotheses. State untested areas.
Do not connect GitHub, comment on a PR or launch a paid review.
Expected finding structure:
Finding: [specific issue, if supported]
Location: [actual file/element]
Evidence: [observed code or behavior]
Reproduction: [steps that can be tried]
Consequence: [what fails]
Coverage: [what was and was not checked]
Never fill placeholders with invented issues. “No supported finding in inspected scope” is more accurate than “fully secure”.
Verify one finding before fixing
Open the file and run the proposed reproduction in a local browser. Check actual pixels, focus and interaction. If the finding cannot be reproduced, ask what evidence supports it rather than deleting working code.
This reproduction did not fail as described.
Recheck the cited code and distinguish a real failure from a hypothetical risk.
Do not edit until the finding is supported.
For a verified defect, request a minimal fix and rerun affected tests. Review can itself introduce regressions if every suggestion is applied automatically.
Distinguish review routes and billing
The documented local /code-review route differs from hosted organizational Code Review and cloud ultrareview. Hosted Code Review can post GitHub findings and use organization billing; trigger comments may subscribe future pushes. Ultrareview is a premium usage-credit feature beyond any eligible introductory free runs and displays scope/cost confirmation.
This exercise enables none of those services. Before a real launch, inspect current eligibility, account, repository audience, exact scope, estimate and recurring trigger. Do not assume “review” means free or read-only externally.
Security scanning is another workflow
The official Claude Security plugin scans code, writes report artifacts and uses plan allowance; managed Enterprise scanning is a different service. A scan may be costly in tokens and does not replace deterministic scanners or human review.
Read coverage and revision stamps. Findings against an old commit can be stale. Patch suggestions are not automatically applied according to the current source; preserve that separation. Never run a scan against systems you do not own or have permission to assess.
Finish with verified coverage
Summarize supported findings, reproduced checks, fixes made and remaining gaps.
Do not call the project secure or ready to deploy unless those claims are justified.
Compare with the actual files and tests. Preserve unsupported or unrun checks as gaps rather than hiding them in confident wording.
Graded practice
Easy: evidence format
Request a local review. Success: every finding has location and support.
Intermediate: reproduction
Verify one finding. Success: distinguish confirmed behavior from speculation.
Challenging: choose a service
Compare local review, hosted PR review and scanning. Success: identify effects, costs and access before setup.
Troubleshooting
Many vague findings: narrow scope and request reproducible evidence.
No findings: inspect coverage rather than treating silence as a guarantee.
Paid prompt appears: stop until scope and spending are deliberately chosen.
Old report: compare revision and current code.
Fix touches unrelated files: stop, inspect diff and reduce the patch.