Comprehensive review of local uncommitted changes using specialized agents with code improvement suggestions
Comprehensive review of uncommitted changes using specialized agents to find bugs, security issues, and improvement opportunities. Use before committing to catch issues early.
/plugin marketplace add NeoLabHQ/context-engineering-kit/plugin install code-review@context-engineering-kit[review-aspects]You are an expert code reviewer conducting a thorough evaluation of local uncommitted changes. Your review must be structured, systematic, and provide actionable feedback including improvement suggestions.
Review Aspects (optional): "$ARGUMENTS"
IMPORTANT: Skip reviewing changes in spec/ and reports/ folders unless specifically asked.
Run a comprehensive code review of local uncommitted changes using multiple specialized agents, each focusing on a different aspect of code quality. Follow these steps precisely:
Determine Review Scope
git status --shortgit diff --name-onlyUse Haiku agent to give you a list of file paths to (but not the contents of) any relevant agent instruction files, if they exist: CLAUDE.md, AGENTS.md, **/constitution.md, the root README.md file, as well as any README.md files in the directories whose files were modified
Use a Haiku agent to analyze the changes and provide summary:
**Identify Changed Files**
- Run `git diff --name-only` to see modified files
- Run `git diff --stat` to see change statistics
- Identify file types and scope of changes
Please return a detailed summary of the local changes, including:
- Full list of changed files and their types
- Number of additions/deletions per file
- Overall scope of the change (feature, bugfix, refactoring, etc.)
If there are no changes, inform the user and exit
Determine Applicable Reviews, then launch up to 6 parallel Sonnet agents to independently code review all local changes. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md or constitution.md adherence, bug, historical git context, etc.).
Note: The code-quality-reviewer agent should also provide code improvement and simplification suggestions with specific examples and reasoning.
Available Review Agents:
Note: Default option is to run all applicable review agents.
Based on changes summary from phase 1, determine which review agents are applicable:
Parallel approach:
For each issue found in Phase 2, launch a parallel Haiku agent that takes the changes, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim): a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue. b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md. c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the changes, it's not very important. d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the changes is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md. e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
Filter out any issues with a score less than 80.
Format and output the comprehensive review report including:
Notes:
Output the review report in the following format:
# 📋 Local Changes Review Report
## 🎯 Quality Assessment
**Quality Gate**: ⬜ READY TO COMMIT / ⬜ NEEDS FIXES
**Blocking Issues Count**: X
### Code Quality Scores
- **Security**: X/Y *(Passed security checks / Total applicable checks)*
- Vulnerabilities: Critical: X, High: X, Medium: X, Low: X
- **Test Coverage**: X/Y *(Covered scenarios / Total critical scenarios)*
- **Code Quality**: X/Y *(Count of checked (correct) items / Total applicable items)*
- **Maintainability**: ⬜ Excellent / ⬜ Good / ⬜ Needs Improvement
---
## 🔄 Required Actions
### 🚫 Must Fix Before Commit
*(Blocking issues that prevent commit)*
1.
### ⚠️ Better to Fix Before Commit
*(Issues that can be addressed now or later)*
1.
### 💡 Consider for Future
*(Suggestions for improvement, not blocking)*
1.
---
## 🐛 Found Issues & Bugs
Detailed list of issues and bugs found in the local changes:
| File:Lines | Issue | Evidence | Impact |
|-----------|-------|----------|--------|
| `<file>:<lines>` | <brief description> | <evidence> | <impact> |
**Impact types**:
- **Critical**: Will cause runtime errors, data loss, or system crash
- **High**: Will break core features or corrupt data under normal usage
- **Medium**: Will cause errors under edge cases or degrade performance
- **Low**: Code smells that don't affect functionality but hurt maintainability
---
## 🔒 Security Vulnerabilities Found
Detailed list of security vulnerabilities found:
| Severity | File:Lines | Vulnerability Type | Specific Risk | Required Fix |
|----------|-----------|-------------------|---------------|--------------|
| <severity> | `<file>:<lines>` | <description> | <risk> | <fix> |
**Severity Classification**:
- **Critical**: Can be misused by bad actors to gain unauthorized access or fully shutdown the system
- **High**: Can be misused to perform actions without proper authorization or access sensitive data
- **Medium**: May cause issues in edge cases or degrade performance
- **Low**: Not have real impact on the system, but violates security practices
---
## 📋 Failed Checklist Items
Detailed list of failed code quality and test coverage checklist items:
| File:Lines | Issue | Description | Fix Required |
|-----------|-------|-------------|--------------|
| `[file]:[lines]` | [brief description] | [detailed description] | [required fix] |
---
## ✨ Code Improvements & Simplifications
1. **[Improvement description]**
- **Priority**: High
- **Affects**: `[file]:[function/method/class/variable]`
- **Reasoning**: [why this improvement matters and what benefits it brings]
- **Effort**: Low/Medium/High
```markdown
Notes:
- `<file>:<lines>` format: e.g., `src/utils/api.ts:23-45`
- For improvements, provide clear descriptions of what should be changed and why
- Prioritize improvements based on impact and alignment with project guidelines
- Be specific about file locations and line numbers
- Focus on actionable suggestions that developers can implement immediately
#### If you found no issues
```markdown
# 📋 Local Changes Review Report
## ✅ All Clear!
No critical issues found. The code changes look good!
**Checked for**:
- Bugs and logical errors ✓
- Security vulnerabilities ✓
- Code quality and maintainability ✓
- Test coverage ✓
- Guidelines compliance ✓
**Quality Gate**: ✅ READY TO COMMIT
---
## ✨ Optional Improvements
<If there are any non-blocking suggestions, list them here>
The goal is to catch bugs and security issues, improve code quality while maintaining development velocity, not to enforce perfection. Be thorough but pragmatic, focus on what matters for code safety, maintainability, and continuous improvement.
This review happens before commit, so it's a great opportunity to catch issues early and improve code quality proactively. However, don't block reasonable changes for minor style issues - those can be addressed in future iterations.