code-review-assistant
Systematic code review checklist and pre-commit quality gates for PRs. Use when: reviewing pull requests, checking code quality, before committing code. Keywords: review, PR, pull request, checklist, quality, commit, 審查, 檢查, 簽入.
Installation
Follow the repository instructions for this skill and your agent. Review the files and dependencies before adding it to your workflow.
View source ↗GuidesSkill instructions
Code Review Assistant
Language: English | 繁體中文
Version: 1.0.0 Last Updated: 2025-12-24 Applicability: Claude Code Skills
Core Standard: This skill implements Code Review Checklist. For comprehensive methodology documentation, refer to the core standard.
Purpose
This skill provides systematic checklists for code review and pre-commit verification.
Quick Reference
Comment Prefixes
| Prefix | Meaning | Action Required |
|---|---|---|
| ❗ BLOCKING | Must fix before merge | 🔴 Required |
| ⚠️ IMPORTANT | Should fix, but not blocking | 🟡 Recommended |
| 💡 SUGGESTION | Nice-to-have improvement | 🟢 Optional |
| ❓ QUESTION | Need clarification | 🔵 Discuss |
| 📝 NOTE | Informational, no action | ⚪ Informational |
Review Checklist Categories
- Functionality - Does it work?
- Design - Right architecture?
- Quality - Clean code?
- Readability - Easy to understand?
- Tests - Adequate coverage?
- Security - No vulnerabilities?
- Performance - Efficient?
- Errors - Properly handled?
- Docs - Updated?
- Dependencies - Necessary?
Pre-Commit Checklist
- Build succeeds (zero errors, zero warnings)
- All tests pass
- Code follows project standards
- No security vulnerabilities
- Documentation updated
- Branch synced with target
Detailed Guidelines
For complete standards, see:
AI-Optimized Format (Token-Efficient)
For AI assistants, use the YAML format file for reduced token usage:
- Base standard:
ai/standards/code-review.ai.yaml
Example Review Comments
❗ BLOCKING: Potential SQL injection vulnerability here.
Please use parameterized queries instead of string concatenation.
⚠️ IMPORTANT: This method is doing too much (120 lines).
Consider extracting validation logic to a separate method.
💡 SUGGESTION: Consider using a Map here instead of an array for O(1) lookup.
❓ QUESTION: Why are we using setTimeout here instead of async/await?
📝 NOTE: This is a clever solution! Nice use of reduce here.
Core Principles
- Be Respectful - Review code, not the person
- Be Thorough - Check functionality, not just syntax
- Be Timely - Review within 24 hours
- Be Clear - Explain WHY, not just WHAT
Checkin Quality Gates (YAML Compressed)
# === MANDATORY CHECKLIST ===
build:
- code_compiles: "zero errors, zero warnings"
- dependencies: "all installed, versions locked"
verify: "run build locally, exit code 0"
test:
- existing_pass: "100% pass rate (unit/integration/e2e)"
- new_code_tested: "features→tests, bugfix→regression"
- coverage: "not decreased, critical paths tested"
verify: "run all suites, review coverage report"
quality:
- standards: "naming, formatting, comments"
- no_smells: "methods≤50 lines, nesting≤3, complexity≤10, no duplication"
- security: "no hardcoded secrets, no SQLi, no XSS, no insecure deps"
verify: "run linter, static analysis, security scanner"
docs:
- api_docs: "public APIs documented"
- readme: "updated if needed"
- changelog: "user-facing changes → [Unreleased]"
workflow:
- branch_naming: "feature/, fix/, docs/, chore/"
- commit_message: "conventional commits format"
- synced: "merged/rebased with target branch"
# === NEVER COMMIT WHEN ===
blockers:
- "Build has errors"
- "Tests failing"
- "Feature incomplete (would break functionality)"
- "Contains WIP/TODO in critical logic"
- "Contains debugging code (console.log, print)"
- "Contains commented-out code blocks"
# === COMMIT TIMING ===
good_times:
- "Completed functional unit"
- "Specific bug fixed with regression test"
- "Independent refactor (all tests pass)"
- "Runnable state"
bad_times:
- "Build failures"
- "Test failures"
- "Incomplete features"
- "Experimental code with TODOs"
# === GRANULARITY ===
ideal_size:
files: "1-10 (split if >10)"
lines: "50-300"
scope: "single concern"
split_principle:
combine: ["feature + its tests", "tightly related multi-file"]
separate: ["Feature A + Feature B", "refactor + new feature", "bugfix + incidental refactor"]
Configuration Detection
This skill supports project-specific configuration.
Detection Order
- Check
CONTRIBUTING.mdfor "Disabled Skills" section- If this skill is listed, it is disabled for this project
- Check
CONTRIBUTING.mdfor "Code Review Language" section - If not found, default to English
First-Time Setup
If no configuration found and context is unclear:
- Ask the user: "This project hasn't configured code review language. Which option would you like? (English / 中文)"
- After user selection, suggest documenting in
CONTRIBUTING.md:
## Code Review Language
This project uses **[chosen option]** for code review comments.
<!-- Options: English | 中文 -->
Configuration Example
In project's CONTRIBUTING.md:
## Code Review Language
This project uses **English** for code review comments.
<!-- Options: English | 中文 -->
### Comment Prefixes
BLOCKING, IMPORTANT, SUGGESTION, QUESTION, NOTE
Related Standards
- Code Review Checklist - Core code review standard
- Checkin Standards - Pre-commit quality gates
- Testing Standards - Testing requirements
Version History
| Version | Date | Changes |
|---|---|---|
| 1.0.0 | 2025-12-24 | Added: Standard sections (Purpose, Related Standards, Version History, License) |
License
This skill is released under CC BY 4.0.
Source: universal-dev-standards
Examples
Read the usage examples in the source repository.
View source ↗Source history
- Indexed on
- 2026-01-20
- Index updated
- 2026-02-02
- Branch
- main
Index and sync dates describe this directory. View the source repository for code history.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!