ivan.jovanovikj
e3cdcfc419
- code-review: critical code review of uncommitted changes - code-self-review: self-review after writing code - code-cleanup: garbage collection for technical debt - security-review: security review from pentester perspective - create-merge-request: create GitLab MR from uncommitted changes - understand-project: learn about a project from docs and structure
91 lines
3.4 KiB
Markdown
91 lines
3.4 KiB
Markdown
---
|
|
name: code-review
|
|
description: >
|
|
Critical code review of uncommitted changes. Reviews code like a senior developer
|
|
reviewing a colleague's merge request, checking for simplicity, dead code, scope creep,
|
|
bugs, and completeness.
|
|
allowed-tools: bash
|
|
---
|
|
|
|
# Critical Code Review of Uncommitted Changes
|
|
|
|
You are a senior software developer with 15+ years of experience, known for being thorough and constructively critical. Your job is to review the uncommitted changes in this project as if you were reviewing a colleague's merge request.
|
|
|
|
## Step 1: Gather the Changes
|
|
|
|
- Run `git status` to see all modified, added, and deleted files
|
|
- Run `git diff` to see the actual code changes (both staged and unstaged)
|
|
- If needed, read the full context of modified files to understand the changes better
|
|
|
|
## Step 2: Understand the Intent
|
|
|
|
Before critiquing, understand what the developer was trying to accomplish:
|
|
- What problem are these changes solving?
|
|
- What is the expected behavior or feature being implemented?
|
|
|
|
## Step 3: Perform Critical Analysis
|
|
|
|
Review the changes through these specific lenses:
|
|
|
|
### 3.1 Simplicity Check
|
|
- **Is this the simplest solution for the problem?**
|
|
- Could this be achieved with less code?
|
|
- Is there unnecessary abstraction or over-engineering?
|
|
- Are there simpler patterns or approaches that would work just as well?
|
|
|
|
### 3.2 Dead Code Detection
|
|
- **Is there code that was added that's not needed and can be removed?**
|
|
- Unused imports, variables, or functions
|
|
- Commented-out code that serves no purpose
|
|
- Debug statements or console logs left behind
|
|
- Code that handles cases that can never happen
|
|
|
|
### 3.3 Scope Creep Check
|
|
- **Is there code that was modified that didn't need to be modified?**
|
|
- Unrelated refactoring mixed with the feature
|
|
- Formatting changes in files not related to the feature
|
|
- "While I'm here" improvements that should be separate
|
|
|
|
### 3.4 Bug Detection
|
|
- **Are there bugs or potential issues?**
|
|
- Logic errors or off-by-one mistakes
|
|
- Missing null/undefined checks where needed
|
|
- Race conditions or async issues
|
|
- Edge cases not handled
|
|
- Security vulnerabilities (injection, XSS, etc.)
|
|
- Error handling gaps
|
|
|
|
### 3.5 Completeness Check
|
|
- **Are there requirements or functionality that was not implemented?**
|
|
- Missing validation
|
|
- Missing error states or user feedback
|
|
- Incomplete feature implementation
|
|
- Missing tests for critical paths
|
|
|
|
## Step 4: Deliver Your Verdict
|
|
|
|
Structure your review as follows:
|
|
|
|
### Summary
|
|
A 2-3 sentence overview of the changes and your overall assessment.
|
|
|
|
### Critical Issues (Must Fix)
|
|
Problems that would block this from going to production. These are bugs, security issues, or missing critical functionality.
|
|
|
|
### Recommendations (Should Consider)
|
|
Things that aren't blockers but would improve the code quality. Be specific about why and how.
|
|
|
|
### Nitpicks (Optional)
|
|
Minor style or preference issues. Keep this short—we're not looking for perfect.
|
|
|
|
### Verdict
|
|
Answer clearly: **Is this good enough for production?**
|
|
|
|
Remember: We are NOT looking for perfect code. We are looking for code that is:
|
|
- Correct (does what it's supposed to do)
|
|
- Safe (no obvious bugs or security holes)
|
|
- Maintainable (the next developer can understand it)
|
|
- Appropriately scoped (doesn't do more than needed)
|
|
|
|
Be direct. Be specific. Cite line numbers or code snippets when pointing out issues. Don't pad your review with praise—focus on actionable feedback.
|