code-review
Automates pre-merge code reviews to ensure adherence to architectural and quality standards.
Install
mkdir -p .claude/skills/code-review-antonykervazocanut && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18692" && unzip -o skill.zip -d .claude/skills/code-review-antonykervazocanut && rm skill.zipInstalls to .claude/skills/code-review-antonykervazocanut
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Review a diff against project rules and acceptance criteria before mergingKey capabilities
- →Review diffs against project structure rules
- →Check for architectural and DRY principles adherence
- →Evaluate code quality based on docstrings and type hints
- →Verify encoding and ROM safety for game development
- →Ensure test coverage and passing test suites
How it works
The skill reviews a git diff against predefined project rules, architectural principles, code quality standards, and testing requirements to identify issues before merging.
Inputs & outputs
When to use code-review
- →Performing pre-merge reviews
- →Validating project structure
- →Checking for documentation gaps
About this skill
Code Review
Check the diff against project conventions and the ticket's acceptance criteria. Flag gaps before merge.
When to Review
- After each feature task or bugfix
- Before any merge to main
- When stuck (fresh perspective)
- After fixing a complex pipeline bug
The Checklist
Run git diff or git show and verify every item below.
1. Project Structure Rules (from .claude/project-rules.md)
- No
.pyfiles at repo root (onlyMakefile,README.md,requirements.txt,.gitignore, configs) - No
.mdfiles at root exceptREADME.md - New scripts land in the correct
src/subfolder (extractors/,analyzers/,translators/,utils/) - Scripts in
src/are numbered (NN_name.py) - New docs land in
docs/and are numbered (NN_NAME.md) - All generated files go to
output/withYYYY-MM-DD_prefix - Input ROMs in
input/roms/— never modified, never written to
2. Architecture and DRY
- Common code lives in
src/core/, not duplicated across scripts - New scripts import from
src/core/— no copy-paste of existing logic - Classes: PascalCase (
ROMReader,TextExtractor) - Functions: snake_case (
read_pointer,decode_text) - Constants: UPPER_SNAKE_CASE (
GBA_ROM_BASE)
3. Code Quality
- All public functions/methods have docstrings with Args/Returns/Example
- Type hints present on all function signatures
- ROM loaded once and reused — not reloaded per operation
- No magic numbers — use named constants
- No hardcoded offsets as special cases (generic fix required)
4. Encoding / ROM Safety
- Text terminated with
0xFF - Pointers updated after any relocation
- Backup created (
.gba.bak) before any ROM write - Offsets validated before write
- French accented characters use correct charmap entries
5. Tests
- New functions/classes have corresponding tests in
tests/unit/ortests/integration/ - Tests follow TDD (they were written BEFORE the implementation)
- No tests are skipped or marked
xfailto hide failures -
pytest tests/passes with 0 failures and 0 errors (100% required) - Edge cases and error paths are tested
6. Commit Format
type(scope): description courte
Description détaillée si nécessaire.
- Point 1
- Point 2
Types: feat, fix, refactor, docs, test, chore
- Commit message follows conventional format
- No
Co-Authored-Bytrailers - One logical change per commit
How to Review
# See all changes
git diff HEAD~1
# See changed files
git diff --stat HEAD~1
# Run full test suite
pytest tests/ -v
# Run with coverage
pytest --cov=src tests/
Output Format
Report findings as:
Critical (blocks merge): wrong file location, skipped test, hardcoded offset fix, ROM modified without backup, missing 0xFF terminator
Important (fix before proceeding): missing docstring, missing type hint, duplicated code that should be in src/core/, magic number
Minor (note for later): naming inconsistency, comment clarity, overly long function
Assessment: Ready / Fix critical issues / Fix important issues
Red Flags
- Script at repo root → block merge
- Skipped test → block merge
pytest tests/shows failures → block merge- Hardcoded
if offset == 0xABCDEF→ block merge (project-rules.md: forbidden) - Missing backup before ROM write → block merge
When not to use it
- →When the changes are not intended for merging
- →When the project does not have defined rules or acceptance criteria
Limitations
- →Requires a git diff or `git show` output for review
- →Relies on `.claude/project-rules.md` for project structure rules
- →Specific to game development aspects like ROM safety and encoding
How it compares
This skill provides a structured, automated checklist for code reviews, ensuring consistent adherence to project-specific rules, unlike a manual, subjective review.
Compared to similar skills
code-review side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| code-review (this skill) | 0 | 1mo | Review | Intermediate |
| python-testing-patterns | 77 | 2mo | Review | Intermediate |
| dependency-upgrade | 26 | 4mo | Review | Intermediate |
| test-cases | 57 | 6mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by AntonyKervazoCanut
View all by AntonyKervazoCanut →You might also like
python-testing-patterns
wshobson
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test suites, or implementing testing best practices.
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
test-cases
cexll
This skill should be used when generating comprehensive test cases from PRD documents or user requirements. Triggers when users request test case generation, QA planning, test scenario creation, or need structured test documentation. Produces detailed test cases covering functional, edge case, error handling, and state transition scenarios.
reviewing-code
CaptainCrouton89
Systematically evaluate code changes for security, correctness, performance, and spec alignment. Use when reviewing PRs, assessing code quality, or verifying implementation against requirements.
wcag-audit-patterns
wshobson
Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance. Use when auditing websites for accessibility, fixing WCAG violations, or implementing accessible design patterns.
code-coverage-with-gcov
gadievron
Add gcov code coverage instrumentation to C/C++ projects