review-securitylisted
Install: claude install-skill mayankmankhand/llm-peer-review
# Security Review
Be thorough but concise. Read the change like an attacker, not like an author.
**Use this when:** Reviewing a code change for application-level security flaws - the kind a diff can actually reveal. Runs automatically inside `/review` whenever code changes, and can be called directly as `/review-security`.
**Don't use this when:** Auditing dependency versions or CVEs (use `/review-deps`), doing a deep whole-repo security pass (use `/security-audit`), or reviewing non-security code quality (use `/review-code`).
**How it differs from `/review-code`:** same code, attacker's eyes. `/review-code` asks "is this written well?"; this skill asks "what can a malicious user make this do?" That adversarial lens surfaces a class of bug a correctness review walks straight past.
## Critical Rules
<rules>
1. **THE REVIEW PHASE REPORTS ONLY** - Reviewing never edits files; findings with exploit receipts are its product. After the report, the same run continues into the auto loop (rule 2), which is what applies fixes
2. **Audit, then auto-fix, with pages** - Security findings are audited before the report per M2 in `.claude/skills/shared/hitl-loop.md`, so the report shows survivors only plus an Audited out log for the kills. They do not then wait for a human "fix it": after the report, survivors are auto-fixed and re-verified, and each finding exits as page, digest, or log per `.claude/skills/shared/hitl-loop.md` (pages only per M1; saying "report only" keeps a run repor