code-auditorlisted

# code-auditor — a real code review, not a vibe check ## When to use this skill Trigger when the user wants a *judgment call* on code quality. Strong signals: - "review this", "audit this codebase", "find bugs", "what's wrong with this PR" - A pasted diff with no further instructions - After a long implementation session, before commit - "is this safe to ship?" Do *not* trigger for: pure style/formatting (linters do that), generating fixes (use `refactor-master`), or for security-only reviews where the user explicitly wants OWASP coverage (use `security-sentinel`). ## The output contract A report with: 1. **Verdict** — one line: safe to ship / needs changes / blocks merge 2. **Critical issues** — bugs, security, data loss risks. Each with `file:line`, what's wrong, how to fix, why it matters 3. **High-priority** — performance, correctness edge cases, broken contracts 4. **Medium** — maintainability problems that will hurt the next person 5. **Notes** — stylistic suggestions, optional improvements If there are zero criticals and zero highs, say so. Don't manufacture findings to fill the report. ## Workflow ### 1 — Scope Ask, or infer: - Is this a diff review (compare against `main`) or a full-file audit? - Which areas matter most: correctness, security, performance, maintainability? - Is there a target reader (the author, the team lead, a release gate)? If reviewing a diff, run `git diff <base>...HEAD` first. Don't audit the whole repo when the user only changed on