Commands that audit your code for issues you didn’t write on purpose. Run these before shipping, and occasionally as a health check on existing code.
/code-review — comprehensive auditStarter kit: YES
Scope: personal
File: ../starter-kit/.claude/commands/code-review.md
A 5-phase review that finds AND fixes issues (not just reports them):
Key behavior: Unlike a human code review, /code-review is told to fix issues directly, not document them. It’s a cleanup pass, not a checklist generator.
When to run:
/implement but before /commitWhen NOT to run:
Output format:
| Category | Found | Fixed | Remaining |
|----------------|-------|-------|-----------|
| Security | 3 | 3 | 0 |
| Performance | 2 | 1 | 1 |
| Code Quality | 7 | 7 | 0 |
| Test Coverage | 4 | 2 | 2 |
The “Remaining” column is your followup list. If everything is zero, you’re done.
/security-audit — security-only deep diveStarter kit: YES Scope: personal
A narrower variant of /code-review that runs only the Security phase but goes deeper:
npm audit, pip-audit, etc.)Run before deploys. Run after adding authentication. Run when a CVE comes out for a dependency you use.
Not in the starter kit because for most projects, /code-review’s Phase 1 is enough. Add /security-audit when you have a security-sensitive project (auth, payments, health data).
/secrets-scan — gitleaks-style secret detectionStarter kit: YES Scope: personal
Scans the repo — not just the working tree — for hardcoded secrets. Looks at:
.env-like files that shouldn’t be trackedDistinct from /security-audit because it’s history-aware. A secret you committed 50 commits ago and later removed is still in the history and still a leak — /secrets-scan catches that.
When to run:
Recovery path if it finds something:
git-filter-repo --replace-text.gitleaks.toml — that’s how leaks survive cleanups/audit — organizational/governance auditStarter kit: YES Scope: personal
Generates a structured audit document for a topic, with the standard sections: Executive Summary, Findings, Recommendations, Action Items. Used as the deliverable form of an audit — not the investigation, but the report after the investigation.
When to use:
Distinct from /code-review which fixes issues directly. /audit only documents.
/implement # write the code
/code-review # clean up what you just wrote
/test # confirm everything green
/commit # land the change
Four commands, one fluid motion. Do this every time you finish a feature and you’ll never ship broken code by accident.
/code-review calls in Phase 4/commit and /shipprinciples/secrets-never-committed.md — the underlying secrets rule