482 lines
15 KiB
Markdown
482 lines
15 KiB
Markdown
---
|
|
description: Conduct systematic multi-step code review with severity-classified findings and actionable fixes
|
|
argument-hint: files to review and optional focus areas
|
|
disable-model-invocation: true
|
|
---
|
|
|
|
# CodeReview Investigation Workflow
|
|
|
|
Conduct a **systematic, multi-step code review** of the specified files using the CodeReview methodology. This approach prevents superficial single-pass reviews by enforcing multiple investigation steps with progressive confidence building.
|
|
|
|
**Files to review and focus:** $ARGUMENTS
|
|
|
|
## Code Review Framework
|
|
|
|
### Severity Classification
|
|
|
|
Use this framework to classify every issue found:
|
|
|
|
- 🔴 **CRITICAL** - Security vulnerabilities, crashes, data loss, data corruption
|
|
- 🟠 **HIGH** - Logic errors, reliability problems, significant bugs
|
|
- 🟡 **MEDIUM** - Code smells, maintainability issues, technical debt
|
|
- 🟢 **LOW** - Style issues, minor improvements, documentation gaps
|
|
|
|
### Confidence Levels
|
|
|
|
Track your confidence explicitly at each step using the TodoWrite tool. Progress through these levels as evidence accumulates:
|
|
|
|
- **exploring** - Initial code scan, forming hypotheses about issues
|
|
- **low** - Basic patterns identified, many areas unchecked
|
|
- **medium** - Core issues found, edge cases need validation
|
|
- **high** - Comprehensive coverage, findings validated
|
|
- **very_high** - Exhaustive review, minor gaps only
|
|
- **almost_certain** - All code paths checked
|
|
- **certain** - Complete confidence, no further investigation needed
|
|
|
|
### Investigation State
|
|
|
|
Maintain this state structure throughout the code review:
|
|
|
|
```json
|
|
{
|
|
"step_number": 2,
|
|
"confidence": "medium",
|
|
"findings": [
|
|
"Step 1: Found SQL injection vulnerability in auth.py",
|
|
"Step 2: Discovered race condition in token refresh"
|
|
],
|
|
"files_checked": ["/absolute/path/to/file1.py", "/absolute/path/to/file2.py"],
|
|
"issues_found": [
|
|
{
|
|
"severity": "critical",
|
|
"description": "SQL injection in user query construction",
|
|
"location": "auth.py:45",
|
|
"impact": "Attackers can execute arbitrary SQL commands"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
## Workflow Steps
|
|
|
|
### Step 1: Initial Code Scan (Confidence: exploring)
|
|
|
|
**Focus on:**
|
|
|
|
- Reading specified code files completely
|
|
- Understanding structure, architecture, design patterns
|
|
- Identifying obvious issues (bugs, security vulnerabilities, performance problems)
|
|
- Noting code smells and anti-patterns
|
|
- Looking for common vulnerability patterns
|
|
|
|
**Actions:**
|
|
|
|
- Read all specified files using Read tool
|
|
- Examine imports, dependencies, external integrations
|
|
- Check for obvious security issues (hardcoded secrets, SQL injection points)
|
|
- Note architectural concerns
|
|
|
|
**When done:** Use a **Haiku agent** as your investigation guide with these instructions:
|
|
|
|
---
|
|
|
|
#### Investigator Agent Instructions
|
|
|
|
You are a code review guide specializing in systematic code analysis. Review partial findings and provide focused guidance for the next investigation step.
|
|
|
|
**Your responsibilities:**
|
|
|
|
1. Assess current findings - Evaluate issues discovered so far
|
|
2. Validate severity classifications - Ensure 🔴🟠🟡🟢 levels are appropriate
|
|
3. Identify coverage gaps - Pinpoint what code paths or concerns haven't been checked
|
|
4. Guide next steps - Provide specific, actionable investigation suggestions
|
|
|
|
**Findings assessment:**
|
|
|
|
- Have all specified files been read completely?
|
|
- Are issues backed by actual code examination or just assumptions?
|
|
- Have all code paths been considered (including error handling)?
|
|
- Are there patterns that suggest similar issues elsewhere?
|
|
|
|
**Confidence calibration:**
|
|
|
|
- **If confidence seems too high:** Point out unchecked code paths, identify unvalidated assumptions, suggest additional security/concurrency checks
|
|
- **If confidence seems too low:** Acknowledge thorough coverage achieved, validate major issue categories are addressed, encourage appropriate increase
|
|
|
|
**Gap identification checklist:**
|
|
|
|
- Security: SQL injection, command injection, XSS, hardcoded secrets, auth gaps, input validation?
|
|
- Concurrency: Race conditions, deadlocks, thread-safety, proper locking?
|
|
- Resources: Memory leaks, unclosed files/connections, cleanup in error paths?
|
|
- Error handling: Unhandled exceptions, swallowed errors, missing validation?
|
|
- Performance: O(n²) loops, N+1 queries, unnecessary I/O?
|
|
|
|
**Next step guidance style:**
|
|
|
|
- ✓ **Good:** "Check lines 78-95 for similar SQL injection patterns. Look specifically at how user_input is used in query construction."
|
|
- ✗ **Too vague:** "Review database code"
|
|
|
|
**Red flags to call out:**
|
|
|
|
- Premature certainty - High confidence after only scanning code
|
|
- Severity inflation - Everything marked CRITICAL
|
|
- Severity deflation - SQL injection marked as MEDIUM
|
|
- Pattern blindness - Finding one issue but not checking for similar
|
|
- Happy path only - Ignoring error handling and edge cases
|
|
|
|
**When to suggest completion:** All files analyzed, security/concurrency/resources/error-handling checked, edge cases validated, no major code paths unchecked.
|
|
|
|
**When to push for more:** Files mentioned but not read, security assumed not present vs. verified absent, only happy path checked, patterns suggest similar issues elsewhere.
|
|
|
|
**Output format:**
|
|
|
|
```markdown
|
|
## Code Review Guidance - Step {N}
|
|
|
|
### Findings Assessment
|
|
|
|
[2-3 sentences on coverage and quality]
|
|
|
|
### Severity Validation
|
|
|
|
[Review each classification - appropriate?]
|
|
|
|
### Confidence Calibration
|
|
|
|
**Current:** {stated} **Recommended:** {your assessment}
|
|
[Explain if different]
|
|
|
|
### Coverage Gaps
|
|
|
|
[List specific gaps by category - only include categories with actual gaps]
|
|
|
|
### Next Investigation Focus
|
|
|
|
**Priority 1:** [Specific area] - What to examine, what to look for, why it matters
|
|
**Priority 2:** [Secondary area] - Same format
|
|
|
|
### Confidence Milestone
|
|
|
|
To reach [{next_level}]: [Specific criteria]
|
|
```
|
|
|
|
---
|
|
|
|
Pass the agent: current step number, confidence level, findings, files examined, issues found with severity, areas needing deeper investigation.
|
|
|
|
### Step 2+: Deeper Code Analysis (Confidence: low → medium → high)
|
|
|
|
**The investigator agent will suggest:**
|
|
|
|
- Specific code sections to examine more closely
|
|
- Security vulnerabilities to check for
|
|
- Concurrency issues to validate
|
|
- Performance bottlenecks to analyze
|
|
- Edge cases to verify
|
|
- Whether your confidence assessment is appropriate
|
|
|
|
**Each iteration:**
|
|
|
|
1. Investigate the suggested areas thoroughly
|
|
2. Update your state with new findings and issues
|
|
3. Classify all issues by severity (🔴🟠🟡🟢)
|
|
4. Assess if confidence level should increase
|
|
5. Use a Haiku agent again for next guidance
|
|
6. Repeat until confidence reaches "high" or higher
|
|
|
|
**Technical focus areas by confidence:**
|
|
|
|
- **exploring/low**: Broad code scan, obvious bugs, security vulnerabilities, code smells
|
|
- **medium**: Validate patterns, check edge cases, analyze error handling, verify resource management
|
|
- **high**: Challenge assumptions, check concurrency, validate all code paths, cross-check fixes
|
|
|
|
### Final Step: Comprehensive Validation
|
|
|
|
When your confidence is **"high"** or higher and you believe the review is complete:
|
|
|
|
**If confidence is "certain":**
|
|
|
|
- Skip the analyzer agent
|
|
- Present your complete code review directly
|
|
- Include all issues with severity, locations, and fix examples
|
|
|
|
**If confidence is "high" or "very_high":**
|
|
|
|
Launch a **Sonnet agent** as your senior code reviewer with these instructions:
|
|
|
|
---
|
|
|
|
#### Analyzer Agent Instructions
|
|
|
|
You are an expert code reviewer combining principal engineer knowledge with sophisticated static analysis capabilities. You provide the final comprehensive analysis.
|
|
|
|
**Your role:** You are NOT the initial investigator. The main Claude has conducted a multi-step review. Your job is to:
|
|
|
|
1. **Critically evaluate findings** - Don't blindly accept, verify through code analysis
|
|
2. **Validate severity classifications** - Ensure levels are justified
|
|
3. **Cross-reference patterns** - Check if similar issues exist elsewhere
|
|
4. **Provide actionable fixes** - Include specific code examples (before/after)
|
|
5. **Prioritize recommendations** - Identify top 3 fixes with effort estimates
|
|
|
|
**Critical evaluation - Don't blindly accept:**
|
|
|
|
- Read the code yourself at reported line numbers
|
|
- Verify the issue actually exists as described
|
|
- Validate the severity level is appropriate
|
|
- Check for similar patterns elsewhere in the code
|
|
|
|
**Common false positives to catch:**
|
|
|
|
- Framework-specific patterns misunderstood as vulnerabilities
|
|
- Defensive code mistaken for missing validation
|
|
- Intentional design choices flagged as mistakes
|
|
- Test code reviewed with production standards
|
|
|
|
**Pragmatic philosophy - What NOT to recommend:**
|
|
|
|
- Wholesale framework migrations unless truly justified
|
|
- Complete rewrites when targeted fixes work
|
|
- Improvements unrelated to actual issues found
|
|
- Perfectionist refactors "just because"
|
|
- Premature optimizations
|
|
|
|
**What TO recommend:**
|
|
|
|
- Scoped, actionable fixes with code examples
|
|
- Pragmatic solutions considering constraints
|
|
- Quick wins that reduce risk immediately
|
|
- Long-term improvements when patterns justify them
|
|
|
|
**Code fix requirements - Every recommendation MUST include:**
|
|
|
|
```python
|
|
# ❌ Current code (file.py:45):
|
|
query = f"SELECT * FROM users WHERE id = {user_id}"
|
|
|
|
# ✅ Fixed code:
|
|
query = "SELECT * FROM users WHERE id = ?"
|
|
cursor.execute(query, (user_id,))
|
|
```
|
|
|
|
NOT acceptable: "Fix the SQL injection" (no example) or "Use prepared statements" (too vague)
|
|
|
|
**Output format:**
|
|
|
|
```markdown
|
|
# Code Review Analysis
|
|
|
|
## Investigation Validation
|
|
|
|
### Strengths
|
|
|
|
[What was done well]
|
|
|
|
### Gaps or Concerns
|
|
|
|
[Anything overlooked, false positives to remove]
|
|
|
|
## Findings Analysis
|
|
|
|
[For each issue: Location, Status (✅ Confirmed / ❌ False Positive / ⚠️ Overstated), Description, Impact, Fix with before/after code, Effort estimate]
|
|
|
|
## Pattern Analysis
|
|
|
|
[Were there patterns? Cross-reference similar code]
|
|
|
|
## Additional Issues Identified
|
|
|
|
[Issues you found that initial review missed]
|
|
|
|
## Top 3 Priorities
|
|
|
|
1. [Issue] (🔴/🟠) - [Effort] - Why priority, benefit when fixed
|
|
2. ...
|
|
3. ...
|
|
|
|
## Quick Wins (< 30 minutes)
|
|
|
|
[Simple fixes with code examples]
|
|
|
|
## What NOT to Do
|
|
|
|
❌ [Anti-pattern] - Why wrong
|
|
❌ [Another] - Why avoid
|
|
|
|
## Summary
|
|
|
|
- Total issues by severity
|
|
- Primary concerns
|
|
- Overall code quality assessment
|
|
- Recommended action plan
|
|
- **Is code safe for production?**
|
|
```
|
|
|
|
---
|
|
|
|
Pass the agent: ALL accumulated state from all steps, full file paths for the analyzer to read.
|
|
|
|
## Technical Focus Areas
|
|
|
|
Your code review MUST examine these dimensions:
|
|
|
|
### 1. Security Vulnerabilities
|
|
|
|
- SQL injection, command injection, XSS
|
|
- Hardcoded secrets, credentials, API keys
|
|
- Authentication and authorization gaps
|
|
- Input validation and sanitization
|
|
- Cryptographic weaknesses
|
|
- Information disclosure in errors
|
|
|
|
### 2. Concurrency Issues
|
|
|
|
- Race conditions
|
|
- Deadlocks and livelocks
|
|
- Thread-safety violations
|
|
- Shared state without synchronization
|
|
- Improper use of locks/mutexes
|
|
|
|
### 3. Resource Management
|
|
|
|
- Memory leaks
|
|
- Unclosed files, connections, sockets
|
|
- Resource exhaustion vulnerabilities
|
|
- Missing cleanup in error paths
|
|
- Improper use of finally blocks
|
|
|
|
### 4. Error Handling
|
|
|
|
- Unhandled exceptions
|
|
- Swallowed errors
|
|
- Missing validation
|
|
- Information leakage in error messages
|
|
- Inconsistent error handling patterns
|
|
|
|
### 5. Performance & Algorithmic Complexity
|
|
|
|
- O(n²) algorithms where O(n) is possible
|
|
- N+1 query problems
|
|
- Unnecessary database queries
|
|
- Resource-intensive operations in loops
|
|
- Missing caching opportunities
|
|
|
|
### 6. Architectural Problems
|
|
|
|
- Tight coupling between components
|
|
- Poor abstractions and leaky abstractions
|
|
- Violation of SOLID principles
|
|
- Circular dependencies
|
|
- God objects or classes
|
|
|
|
## Output Format
|
|
|
|
Present your final code review in this structure:
|
|
|
|
```markdown
|
|
# Code Review: [Files Reviewed]
|
|
|
|
## Executive Summary
|
|
|
|
- **Files Analyzed:** X
|
|
- **Total Issues:** Y (Critical: A, High: B, Medium: C, Low: D)
|
|
- **Primary Concerns:** [Main categories of issues found]
|
|
- **Final Confidence:** [level]
|
|
|
|
## Critical Issues 🔴
|
|
|
|
### 1. [Issue Title]
|
|
|
|
**Location:** `file.py:45`
|
|
**Description:** [Detailed description of the issue]
|
|
**Impact:** [What can go wrong]
|
|
**Fix:**
|
|
\`\`\`python
|
|
|
|
# Instead of:
|
|
|
|
[problematic code]
|
|
|
|
# Use:
|
|
|
|
[corrected code with explanation]
|
|
\`\`\`
|
|
|
|
## High Priority Issues 🟠
|
|
|
|
### 1. [Issue Title]
|
|
|
|
**Location:** `file.py:123-145`
|
|
**Description:** [Detailed description]
|
|
**Impact:** [Consequences]
|
|
**Fix:**
|
|
\`\`\`python
|
|
[before/after code example]
|
|
\`\`\`
|
|
|
|
## Medium Priority Issues 🟡
|
|
|
|
### 1. [Issue Title]
|
|
|
|
**Location:** `file.py:78`
|
|
**Description:** [Description]
|
|
**Impact:** [Technical debt or maintainability concern]
|
|
**Fix:**
|
|
[Suggested improvement with code example]
|
|
|
|
## Low Priority Issues 🟢
|
|
|
|
### 1. [Issue Title]
|
|
|
|
**Location:** `file.py:12`
|
|
**Description:** [Minor issue]
|
|
**Fix:**
|
|
[Simple correction]
|
|
|
|
## Top 3 Priorities
|
|
|
|
1. **[Issue name] (SEVERITY)** - [Estimated effort] - [Why this is priority]
|
|
2. **[Issue name] (SEVERITY)** - [Estimated effort] - [Why this is priority]
|
|
3. **[Issue name] (SEVERITY)** - [Estimated effort] - [Why this is priority]
|
|
|
|
## Quick Wins (< 30 minutes)
|
|
|
|
- [Simple fix] - [Estimated time] - [Location]
|
|
- [Another quick fix] - [Estimated time] - [Location]
|
|
|
|
## Long-term Improvements
|
|
|
|
- [Strategic suggestion for architectural improvement]
|
|
- [Suggestion for comprehensive refactoring if justified]
|
|
|
|
## Confidence Assessment
|
|
|
|
[Explain why you reached your final confidence level. What would increase confidence further?]
|
|
```
|
|
|
|
## Code Review Principles
|
|
|
|
Throughout this process:
|
|
|
|
1. **Be specific with line numbers** - Always cite exact locations (file.py:line)
|
|
2. **Provide code examples** - Show before/after for every fix
|
|
3. **Focus on actual issues found** - Don't suggest unrelated improvements
|
|
4. **Balance ideal vs. achievable** - Be pragmatic, not perfectionist
|
|
5. **Classify severity accurately** - Use the 🔴🟠🟡🟢 framework consistently
|
|
6. **Avoid wholesale migrations** - Don't suggest framework changes unless truly justified
|
|
7. **Prioritize actionability** - Every finding needs a concrete fix
|
|
8. **Consider real-world constraints** - Balance security/performance with maintainability
|
|
|
|
## Special Instructions
|
|
|
|
- **Read actual code, not summaries** - Use Read tool extensively
|
|
- **Check all code paths** - Including error handling and edge cases
|
|
- **Look for patterns** - If you find one SQL injection, check for more
|
|
- **Validate severity** - CRITICAL should be reserved for actual security/data loss risks
|
|
- **Include impact analysis** - Explain what can go wrong for HIGH and CRITICAL issues
|
|
- **Track confidence honestly** - Don't inflate or deflate your assessment
|
|
- **If you need more context** - Ask the user for additional files or information
|
|
|
|
---
|
|
|
|
**Begin your code review now. Start with Step 1 at confidence level "exploring".**
|