Code Review
Perform structured, actionable code reviews.
When to Use
- Reviewing a pull request or set of changes
- Evaluating code quality before merging
- Auditing a module for technical debt
- Establishing review standards or checklists
Review Dimensions
Review code across these dimensions, in priority order:
1. Correctness
- Does the code do what it claims?
- Are edge cases handled? (null, empty, overflow, concurrency)
- Are error paths tested?
- Do tests cover the changed behavior?
2. Security
- Input validation at system boundaries
- No secrets in code (API keys, passwords, tokens)
- SQL/command injection prevention
- Proper authentication and authorization checks
- See
security-audit skill for deeper analysis
3. Readability
- Clear naming (variables, functions, classes)
- Functions do one thing
- No deep nesting (max 3 levels)
- Comments explain "why", not "what"
- Consistent style with the surrounding codebase
4. Maintainability
- No unnecessary abstractions
- DRY without over-abstraction (rule of three)
- Dependencies are justified
- Breaking changes are flagged
5. Performance
- Only flag when there is a real concern (hot path, large data, N+1 queries)
- Do not micro-optimize unless the context demands it
Review Output Format
Structure feedback as:
## Review: <PR title or file>
### Must Fix
- [ ] **file.py:42** — [Correctness] Description of the issue and suggested fix
### Should Fix
- [ ] **file.py:78** — [Readability] Description and suggestion
### Consider
- [ ] **file.py:100** — [Performance] Optional improvement
### Positive
- file.py:15 — Good use of context manager for resource cleanup
Severity levels:
| Level |
Meaning |
Merge? |
| Must Fix |
Bug, security issue, or broken contract |
Block |
| Should Fix |
Significant readability/maintainability concern |
Request changes |
| Consider |
Optional improvement, style preference |
Approve with comment |
| Positive |
Good patterns worth highlighting |
- |
Guidelines
- Be specific - Point to exact lines, suggest concrete alternatives
- Explain why - "This could cause X because Y", not just "change this"
- Separate style from substance - Automate style (linters); review logic manually
- Limit scope - Review what changed, not the entire file (unless asked)
- Acknowledge good work - Include at least one positive observation
- Propose, don't impose - "Consider using X" not "You must use X" (unless it's a Must Fix)
Source: LuminairPrime/skill-tree-chopper — distributed by TomeVault.
1---2name: luminairprime-skill-tree-chopper-code-review3description: Code Review4---56# Code Review78Perform structured, actionable code reviews.910## When to Use1112- Reviewing a pull request or set of changes13- Evaluating code quality before merging14- Auditing a module for technical debt15- Establishing review standards or checklists1617## Review Dimensions1819Review code across these dimensions, in priority order:2021### 1. Correctness2223- Does the code do what it claims?24- Are edge cases handled? (null, empty, overflow, concurrency)25- Are error paths tested?26- Do tests cover the changed behavior?2728### 2. Security2930- Input validation at system boundaries31- No secrets in code (API keys, passwords, tokens)32- SQL/command injection prevention33- Proper authentication and authorization checks34- See `security-audit` skill for deeper analysis3536### 3. Readability3738- Clear naming (variables, functions, classes)39- Functions do one thing40- No deep nesting (max 3 levels)41- Comments explain "why", not "what"42- Consistent style with the surrounding codebase4344### 4. Maintainability4546- No unnecessary abstractions47- DRY without over-abstraction (rule of three)48- Dependencies are justified49- Breaking changes are flagged5051### 5. Performance5253- Only flag when there is a real concern (hot path, large data, N+1 queries)54- Do not micro-optimize unless the context demands it5556## Review Output Format5758Structure feedback as:5960```markdown61## Review: <PR title or file>6263### Must Fix6465- [ ] **file.py:42** — [Correctness] Description of the issue and suggested fix6667### Should Fix6869- [ ] **file.py:78** — [Readability] Description and suggestion7071### Consider7273- [ ] **file.py:100** — [Performance] Optional improvement7475### Positive7677- file.py:15 — Good use of context manager for resource cleanup78```7980**Severity levels:**8182| Level | Meaning | Merge? |83| ---------- | ----------------------------------------------- | -------------------- |84| Must Fix | Bug, security issue, or broken contract | Block |85| Should Fix | Significant readability/maintainability concern | Request changes |86| Consider | Optional improvement, style preference | Approve with comment |87| Positive | Good patterns worth highlighting | - |8889## Guidelines90911. **Be specific** - Point to exact lines, suggest concrete alternatives922. **Explain why** - "This could cause X because Y", not just "change this"933. **Separate style from substance** - Automate style (linters); review logic manually944. **Limit scope** - Review what changed, not the entire file (unless asked)955. **Acknowledge good work** - Include at least one positive observation966. **Propose, don't impose** - "Consider using X" not "You must use X" (unless it's a Must Fix)9798---99> Source: [LuminairPrime/skill-tree-chopper](https://github.com/LuminairPrime/skill-tree-chopper) — distributed by [TomeVault](https://tomevault.io).100<!-- tomevault:4.0:skill_md:2026-05-22 -->
tomevault-io