code-review
26
总安装量
2
周安装量
#14437
全站排名
安装命令
npx skills add https://github.com/s-hiraoku/synapse-a2a --skill code-review
Agent 安装分布
amp
2
opencode
2
kimi-cli
2
codex
2
claude-code
2
Skill 文档
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-auditskill 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)