How this skill is triggered — by the user, by Claude, or both
Slash command
/code-quality:reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
---
Review code changes for spec adherence, clean code principles, and quality.
Parse the command arguments: {{ args }}
Flags to detect:
--branch or -b: Review branch diff against main--thorough or -t: Force subagent mode--simple or -s: Force single-pass mode--report or -r: Save findings to file--spec <path>: Reference a spec document--help or help: Show help (invoke /review-help instead)If help or --help is present, display the help information from the review-help skill and stop.
Default (no --branch):
git diff
git diff --cached
Combine staged and unstaged changes.
With --branch flag:
git merge-base HEAD main
git diff <merge-base>..HEAD
Get all changes on current branch since diverging from main.
Count the lines changed to determine review mode.
--thorough flag: Use subagent mode--simple flag: Use single-pass mode--spec <path> was provided - read that fileReview the diff against all criteria in one pass:
Tier 1: Critical (Must address)
Spec Adherence:
Clean Code:
Tier 2: Important (Should address)
Tier 3: Minor (Nice to have)
Spawn three specialized agents in parallel using the Task tool:
Agent 1: Spec Reviewer
Prompt: Review this diff against the provided requirements/context.
Requirements/Context:
[Include conversation context or spec document]
Diff:
[Include the diff]
Check:
- Does the implementation match what was requested?
- Is anything missing from the requirements?
- Is there scope creep (features not asked for)?
- Are there features built for hypothetical future needs?
Report findings as [T1] issues. Be specific with file:line references.
Agent 2: Clean Code Reviewer
Prompt: Review this diff for clean code principles.
Diff:
[Include the diff]
Check:
- Is the code modular with clear separation of concerns?
- Is it maintainable—easy to understand and modify?
- Is it flexible and extensible without being overengineered?
- Are components loosely coupled and cohesive?
- Can future developers easily work with this code?
Report findings as [T1] for critical issues, [T2] for important. Be specific with file:line references.
Agent 3: Overengineering Detector
Prompt: Review this diff for overengineering.
Problem being solved:
[Brief problem statement from context]
Diff:
[Include the diff]
Check:
- Unnecessary abstractions or indirection
- YAGNI violations (features for hypothetical future needs)
- Premature optimizations
- Excessive configurability or extensibility
- Solving a generalized problem instead of the actual problem
Report findings as [T1] issues. Be specific with file:line references.
After all agents complete, collect and deduplicate findings.
Format findings by tier:
## Code Review Results
**Diff:** [X files changed, Y insertions, Z deletions]
**Mode:** [Single-pass | Thorough (subagent)]
### [T1] Critical Issues
[List each issue with file:line reference and explanation]
### [T2] Important Issues
[List each issue]
### [T3] Minor Issues
[List each issue]
### Summary
- Critical: X issues
- Important: Y issues
- Minor: Z issues
If no issues found in a tier, note "None found."
--report flag)Write findings to docs/reviews/YYYY-MM-DD-review.md with:
Create docs/reviews/ directory if it doesn't exist.
npx claudepluginhub rickym-h/jadefall-marketplace --plugin code-qualityReviews code changes since a fixed point (commit, branch, tag) against coding standards and spec requirements, reporting results side by side.
Automates code reviews on git diffs, staged changes, PRs, files, or branches against CLAUDE.md conventions and prioritized best practices (security first).
Reviews local changes, PRs/MRs, or branch diffs against project coding guidelines using 5-7 parallel review agents (bug detection, security/logic, guideline compliance, code simplification, test coverage, contract quality). High-signal findings only.