code-review

## When to Use This Skill | Use this skill when... | Use something else instead when... | |------------------------|------------------------------------| | Running an end-to-end review across quality, security, perf, and tests | Walking a manual security/correctness checklist → `code-review-checklist` | | Auditing a directory or PR delta with delegated agent analysis | Specifically scanning for code smells → `code-antipatterns` | | Spotting missing test cases or weak assertions | Auditing test code quality on its own → `code-test-quality` | | Producing a consolidated review report | Refactoring after the review surfaces issues → `code-refactor` | ## Context - Review path: `$1` (defaults to current directory if not specified) ## Parameters - `$1`: Path to review (defaults to current directory) ## Your task **Delegate this task to the `agents-plugin:review` agent.** Use the Agent tool with `subagent_type: agents-plugin:review` to perform a comprehensive code review. First, use the Glob tool to discover source files to review: - `**/*.py`, `**/*.js`, `**/*.ts`, `**/*.go`, `**/*.rs` for source files - `**/*test*` patterns for test files Then pass the discovered files to the agent. The code-review agent should: 1. **Analyze code quality**: - Naming conventions and readability - Code structure and maintainability - SOLID principles adherence 2. **Security assessment**: - Input validation vulnerabilities - Authentication and authorization issues - Secrets and sensitive data exposure 3. **Performance evaluation**: - Bottlenecks and inefficiencies - Memory usage patterns - Optimization opportunities 4. **Architecture review**: - Design patterns usage - Component coupling - Dependency management 5. **Test coverage gaps**: - Missing test cases - Edge cases not covered - Integration test needs 6. **Apply fixes** where appropriate and safe 7. **Re-verify each candidate finding** (false-positive gate — run BEFORE reporting): For every candidate finding from steps 1–5, re-read the cited code at the reported `file:line` and confirm the claim actually holds against the current source — not against a remembered or assumed shape. A finding survives only if the re-read confirms it; drop the rest. See "Re-verification Pass" below. 8. **Score every surviving finding** against the anchors below: - Assign a **severity** (Critical/High/Medium/Low) using the "Severity Rubric". - Assign a **confidence** (High/Medium/Low) using the "Confidence Scale", and drop or explicitly flag findings below the reporting threshold. 9. **Generate report** with: - Surviving findings ranked most-severe first, each carrying its `severity`, `confidence`, and verified `file:line` - Summary of issues found/fixed - Remaining manual interventions needed - Improvement recommendations Provide the agent with: - The review path from context - Project type (language/framework) - Any specific focus areas requested The agent has expertise in: - Multi-language code analysis (Python, TypeScript, Go, Rust) - LSP integration for accurate diagnostics - Security vulnerability patterns (OWASP) - Performance analysis and optimization ## Severity Rubric Score every surviving finding against these anchors. Rank the report most-severe first. | Severity | Criteria | |----------|----------| | **Critical** | Exploitable security hole, data loss/corruption, or a crash on a common path. Ship-blocker — must fix before merge. | | **High** | A real correctness bug that misbehaves on realistic input, a serious perf regression (N+1, unbounded growth), or an auth/validation gap without a known exploit. Fix before merge. | | **Medium** | Bug on an edge case, missing error handling, a test gap over important behavior, or a maintainability problem that will bite soon. Fix or file a follow-up. | | **Low** | Style, naming, minor readability, or a nit with no behavioral impact. Optional. | ## Confidence Scale Assign each finding a confidence and let it gate what reaches the report. A finding whose defect you cannot demonstrate from the code in front of you is a guess, and guesses erode trust in the review. | Confidence | Meaning | Reporting rule | |------------|---------|----------------| | **High** | The defect is provable from the cited code — you can name the input and the wrong result. | Report. | | **Medium** | The defect is likely but depends on context you could not fully see. | Report, labeled as needing confirmation. | | **Low** | Speculative — a hunch not grounded in the code as read. | Drop, or downgrade to a one-line "consider checking X" note; never present as a defect. | The reporting threshold is **Medium**: report High and Medium findings; do not present Low-confidence hunches as findings. ## Re-verification Pass Before the report step, re-check every candidate finding against the actual code. This kills false positives mechanically rather than trusting the initial read: 1. Re-open the finding's `file:line` with `Read` and confirm the cited code still says what the finding claims (line numbers drift; assumptions decay). 2. Confirm the failure the finding describes is reachable — name the concrete input or state that triggers it. If you cannot, it is Low confidence. 3. Keep only findings that survive both checks. Every reported finding must carry a verified `file:line`, a severity, and a confidence. ## Agent Teams (Optional) For comprehensive review of large codebases, spawn specialized review teammates in parallel: | Teammate | Focus | Value | |----------|-------|-------| | Security reviewer | OWASP, secrets, auth flaws | Deep security analysis without blocking quality review | | Performance reviewer | N+1 queries, algorithmic complexity, resource leaks | Performance-focused review in parallel | | Correctness reviewer | Logic errors, edge cases, type safety | Functional correctness in parallel | This is optional — the skill works without agent teams for standard reviews. ## Related Configure Skills - If security scanning not configured → `/configure:security` - If linting not set up → `/configure:linting` - If test coverage not tracked → `/configure:coverage`