code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

Perform a thorough, constructive code review on the current changes or specified files: the task/scope the user described when invoking this skill (if none given, ask or infer from context)

1. If no files specified, run `git diff` (and `git diff --staged`) to see current changes.
2. Review the changes against the checklist below.
3. Report findings with severity levels.
4. Give an overall assessment: APPROVE or REQUEST_CHANGES.

Focus on actionable feedback. Don't nitpick formatting if a formatter is configured.

## Review Checklist

### Security (quick pass only — a full audit is `/security-review`)
- [ ] No hardcoded secrets or API keys
- [ ] Obvious injection risks (unparameterized SQL, shelled-out user input)
- [ ] Missing input validation on external inputs

### Code Quality
- [ ] Functions are focused (single responsibility)
- [ ] No code duplication
- [ ] Clear naming conventions
- [ ] Proper error handling (no swallowed errors)
- [ ] No unused imports or dead code

### Performance
- [ ] No N+1 query patterns
- [ ] Appropriate use of indexes (if DB changes)
- [ ] No memory leaks (event listeners, subscriptions)
- [ ] Efficient data structures

### Maintainability
- [ ] Code is self-documenting
- [ ] Complex logic has comments explaining "why"
- [ ] Consistent patterns with rest of codebase

## Output Format
For each finding:
```
**[SEVERITY]** file:line - Description
Suggestion: How to fix
```
Severities (canonical): CRITICAL, WARNING, INFO. Minor nitpicks fold into INFO.

End with a summary: total findings by severity, overall assessment, and APPROVE / REQUEST_CHANGES.

From Hbin77/codex-kit, MIT.

More from Hbin77/codex-kit