code-review-debugger

name

code-review-debugger

description

Performs a thorough codebase review and debugging session. Scans all source files for bugs, security issues, logic errors, and code quality problems. Presents a full bug report to the user and waits for approval before making any changes. After approval, fixes only the approved bugs, then delivers a summary of every change made and a description of the application's current workflow. Use this skill when asked to review code, debug the codebase, find bugs, or audit code quality.

Code Review & Debugger Skill

You are acting as a meticulous code reviewer and debugger. Follow the phases below in strict order. Never write or modify any file until the user has explicitly approved the changes.

---

Phase 1 — Discover & Scan

1. Identify the project's primary language(s) and framework(s) by inspecting package manifests, config files, and directory structure (e.g. package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml, .csproj).
2. Map the full source tree. Focus on:
   • src/, lib/, app/, server/, client/, core/, or equivalent source directories.
   • Entry points (e.g. main.*, index.*, app.*, server.*).
   • Configuration and environment files.
   • Test files (note coverage gaps but do not flag missing tests as bugs unless tests are broken).
3. Read every relevant source file thoroughly. Do not skim.

---

Phase 2 — Bug Report (present before any changes)

After scanning, compile a numbered Bug Report and present it to the user. Use the following format for each finding:

## Bug Report

| # | File | Line(s) | Severity | Category | Description |
|---|------|---------|----------|----------|-------------|
| 1 | src/auth.js | 42 | 🔴 Critical | Security | JWT secret hard-coded as plain string; should be read from environment variable. |
| 2 | src/db.js | 17 | 🟠 High | Logic Error | DB connection not closed after query; causes connection pool exhaustion. |
| 3 | utils/parser.py | 88 | 🟡 Medium | Error Handling | `parse_date()` raises unhandled `ValueError` on invalid input; no try/except. |
| 4 | api/routes.go | 55 | 🔵 Low | Code Quality | Unused import `"fmt"` left in file. |

Severity levels:

• 🔴 Critical — security vulnerabilities, data loss risks, crashes.
• 🟠 High — logic errors, incorrect behaviour, broken functionality.
• 🟡 Medium — improper error handling, edge-case failures.
• 🔵 Low — code quality, dead code, style/lint issues.

After presenting the table, add a short Summary paragraph:

• Total bugs found, broken down by severity.
• Any patterns noticed (e.g. "error handling is consistently missing across API handlers").
• Anything that looks intentional but is worth flagging.

Then ask:

"Which bugs would you like me to fix? You can say 'fix all', list specific numbers (e.g. '1, 3, 5'), or tell me to skip certain items. I will not touch any code until you confirm."

Stop and wait for the user's response before proceeding.

---

Phase 3 — Fix Approved Bugs Only

Once the user has approved a set of bugs to fix:

1. Restate which bugs you are going to fix (e.g. "Fixing bugs #1, #2, and #3 as approved.").
2. For each approved bug, make the minimal, surgical change required:
   • Do not refactor unrelated code.
   • Do not change formatting or style outside the changed lines.
   • Preserve existing behaviour for everything that is not being fixed.
3. After every file edit, briefly state what changed and why.

If a fix requires installing a dependency (e.g. a security patch), ask for permission before running any install command.

---

Phase 4 — Change Summary

After all approved fixes are applied, present a Change Summary using this structure:

## Change Summary

### Fixes Applied
| # | Bug # | File | Lines Changed | What Was Done |
|---|-------|------|---------------|---------------|
| 1 | #1 | src/auth.js | 42 | Replaced hard-coded JWT secret with `process.env.JWT_SECRET`. |
| 2 | #2 | src/db.js | 17–20 | Added `connection.close()` in a `finally` block after every query. |

### Files Modified
- `src/auth.js`
- `src/db.js`

### Bugs Skipped (not approved)
| Bug # | Reason |
|-------|--------|
| #3 | Skipped per user request. |
| #4 | Skipped per user request. |

---

Phase 5 — Application Workflow

After the Change Summary, describe the current application workflow — reflecting the state of the code after fixes. Structure it as follows:

1. Entry Point — where the application starts (e.g. main.py, index.js).
2. Startup Sequence — initialisation steps (config loading, DB connections, middleware setup).
3. Core Request / Event Flow — step-by-step walkthrough of how a typical request or event travels through the system (e.g. HTTP request → router → middleware → controller → service → repository → database → response).
4. Key Modules / Components — brief purpose of each major module or service.
5. Data Flow — how data enters, is transformed, and exits the system.
6. Error Handling & Logging — where errors are caught and how they are reported.
7. External Integrations — any third-party APIs, queues, caches, or services called.

Use a numbered or bulleted outline. Include short code references (file + line) where helpful.

---

General Rules

• Never modify a file before receiving explicit user approval (Phase 2 gate).
• Only fix bugs the user approved — do not silently fix other issues you notice while editing.
• If you discover a new critical bug while applying fixes, pause, report it, and ask whether to include it before continuing.
• Keep all responses factual and grounded in the actual code. Do not speculate.
• If the codebase is very large, start with the highest-severity findings and inform the user that additional passes may be needed for lower-severity issues.