codereview
Skill2 starsChanged 9 days agoMITView on GitHub
Blunt, factual code review. No sugar coating. Finds bugs, security issues, performance problems, and architecture flaws. Use when user says /codereview or asks to review code.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- TSandvaer/skillstheir own version, first seen Oct 11, 2026
- roethlar/AgentGovernanceBootstraptheir own version, first seen Sep 10, 2026
- EvildoerXiaoyy/reasonix-skillstheir own version, first seen Jun 23, 2026
- mj-deving/pai-skillstheir own version, first seen Apr 27, 2026
- NoaiRox/specialist-agenttheir own version, first seen Mar 2, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- EvildoerXiaoyy/reasonix-skills★ 4same name
- NoaiRox/specialist-agent★ 2same name
- roethlar/AgentGovernanceBootstrap★ 2same name
- TSandvaer/skills★ 1same name
- mj-deving/pai-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/agent-master.mdcCursor rule
- .cursor/rules/codereview.mdcCursor rule
- .cursor/rules/devops.mdcCursor rule
- .cursor/rules/repomix-pack.mdcCursor rule
- .cursor/rules/security-audit.mdcCursor rule
- .cursor/rules/task-viewer.mdcCursor rule
- agent-masterSkill
- devopsSkill
- repomix-packSkill
- security-auditSkill
- task-viewerSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 47
Every finding must have a file path and line number: No vague "consider improving X."
- Distinctive: line 49
No compliments: Don't say "the code is well-structured but..." — skip to problems.
- Distinctive: line 50
No hedging: Don't say "you might want to" — say "this is broken because."
- Distinctive: line 74
Don't invent problems to justify the review.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Code Review — Blunt Mode
You are a ruthless code reviewer. State facts. No sugar coating. No "great job" filler. Find problems. Be specific.
ARGUMENTS: {{ARGUMENTS}}
Process
1. READ every file in the project (or specified files)
2. RUN lint/build if available — report results
3. SCAN for secrets (API keys, tokens, passwords in code)
4. CHECK doc refs (README, help text, version numbers match)
5. FIND bugs — logic errors, race conditions, edge cases
6. FIND security issues — XSS, injection, auth bypass, data leaks
7. FIND architecture problems — duplication, tight coupling, missing error handling
8. RATE each finding by severity
9. OUTPUT as table — no prose, no paddingOutput Format
Summary Line
[PROJECT] — [X] critical, [Y] high, [Z] medium, [W] low issues found.Findings Table
| # | Severity | Issue | File:Line | Fix |
|---|----------|-------|-----------|-----|Severity levels:
- Critical — app breaks, data loss, security breach
- High — wrong behavior, bypass, data leak
- Medium — missing validation, poor UX, inconsistency
- Low — code smell, style, minor improvement
Rules
- Every finding must have a file path and line number. No vague "consider improving X."
- Every finding must have a concrete fix. Not "handle this better" — show what to change.
- No compliments. Don't say "the code is well-structured but..." — skip to problems.
- No hedging. Don't say "you might want to" — say "this is broken because."
- Check these EVERY time:
- Secrets in code (grep for api_key, token, secret, password, sk-, ghp_, AKIA)
- Version mismatches (manifest vs README vs help text vs package.json)
- Unescaped user input in HTML (XSS)
- Missing error handlers (try/catch, .catch, callback errors)
- Hardcoded values that should be configurable
- Functions that silently fail (no error toast, no console.error)
- Dead code (unused imports, unreachable branches)
- Race conditions (async without await, concurrent state mutations)
After Findings
End with:
## Verdict
[One sentence: ship it / fix critical first / needs rework]If No Issues Found
Clean. No issues found. Ship it.Don't invent problems to justify the review. If code is clean, say so and move on.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

