Review
Personal Claude Code skills by Santhosh Gandhi — context-manager and frugal-token-usage
npx -y skills add isanthoshgandhi/santhoshstack --skill reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Scan the current codebase or a specified file/diff for production bugs, logic errors, and risky code before it ships. Use when the user says "review", "check my code", "is this safe to ship", or "any bugs in this?". Produces a prioritised bug list with exact file:line references and optional auto-fixes.
SKILL.md
2.3 KB, as published. Nobody here has run it
Review
You are doing a focused production-readiness review. Your job is to find real bugs — not style issues, not hypothetical edge cases, not nitpicks.
Scope
If the user specifies a file or diff, review only that. Otherwise review files changed since the last commit:
git diff HEAD --name-only
Read only the files in scope. Do not speculatively read the whole repo.
What to look for (priority order)
- Logic errors — wrong conditions, off-by-one, incorrect branching
- Null / undefined access — unguarded property access, missing checks
- Data loss — writes that overwrite without backup, deletes without guard
- Auth / permission gaps — unauthenticated paths, missing ownership checks
- Race conditions — async code that assumes serial execution
- Unhandled errors — promises without catch, try/catch that swallows errors silently
- Hardcoded values — secrets, URLs, or env-specific values baked into code
Stop at 7 findings. If there are more, note "further issues likely — address these first."
Output format
For each finding:
[SEVERITY] file:line — one-line description
WHY: one sentence on why this breaks in production
FIX: exact change needed (or "see below" if multi-line)
Severity levels: CRITICAL | HIGH | MEDIUM
Only include MEDIUM if there are fewer than 3 CRITICAL/HIGH findings.
Auto-fix rule
If the user says "fix it" or "auto-fix":
- Apply fixes for CRITICAL and HIGH findings only
- One Edit call per fix — no batch rewrites
- After fixing, re-state the finding as resolved
What NOT to do
- Do not suggest refactors, naming changes, or performance improvements
- Do not flag issues that only appear in tests or dev environments
- Do not quote large code blocks in your response — use file:line references
- Do not add "looks good overall" filler — if there are no bugs, say "No production bugs found."