Skill: glucksberg/pr-review (version 2.0.1)

--- name: pr-review description: Find and fix code issues before publishing a PR. Single-pass review with auto-fix. Use when reviewing code changes before submission or auditing existing code for bugs/security. Don't use when running a coding agent to write code (use coding-agent) or checking GitHub CI status (use github). metadata: {"openclaw": {"requires": {"bins": ["git"]}}} --- # Pre-Review Find and fix issues **before** publishing your PR — not after. Single-pass review using one capable model. No orchestration overhead, no agent swarm. Fast, cheap, thorough. ## When to use - Reviewing code changes before publishing a PR - Auditing existing code for bugs, security, or quality issues - Finding and fixing issues in specific files or directories ## When NOT to use - Running a coding agent to write new code → use `coding-agent` - Checking GitHub CI status → use `github` - Managing forks or rebasing branches → use `fork-manager` ## Usage ``` /pr-review # Review changes on current branch vs main/master /pr-review src/api/ src/auth/ # Audit specific directories /pr-review **/*.ts # Audit files matching a pattern /pr-review --audit # Audit entire codebase with smart prioritization ``` Two modes: | Mode | Trigger | Scope | Fix threshold | |------|---------|-------|---------------| | **Diff** | No args, on branch with changes | Changed files only | >= 70 | | **Audit** | Paths, patterns, or `--audit` | Specified files or full codebase | >= 80 | ## Instructions ### Step 1: Detect Mode and Scope **No arguments provided:** ```bash git diff main...HEAD --name-only 2>/dev/null || git diff master...HEAD --name-only ``` - If changes exist → **Diff mode** - If no changes → inform user, stop **Paths/patterns provided or `--audit`:** - Resolve to actual files (exclude node_modules, dist, build, vendor, .git, coverage) - If > 50 files, ask user to narrow scope or confirm - **Audit mode** ### Step 2: Gather Context Read project guidelines (quick scan, don't overthink): ```bash # Check for project conventions cat CLAUDE.md .claude/settings.json CONTRIBUTING.md 2>/dev/null | head -100 cat .eslintrc* .prettierrc* biome.json tsconfig.json 2>/dev/null | head -50 cat package.json 2>/dev/null | head -20 # tech stack ``` Get the diff or file contents: ```bash # Diff mode git diff main...HEAD # or master # Audit mode cat <files> # read target files ``` ### Step 3: Review (Single Pass) Analyze all code in one pass. Cover these areas in priority order: **1. Correctness** (highest priority) - Logic errors, edge cases, null/undefined handling - Off-by-one, pagination boundaries, numeric precision - Async/await mistakes, race conditions, resource leaks - Data consistency, idempotency **2. Security** - Injection vulnerabilities (SQL, XSS, command, path traversal) - Auth/authz gaps, IDOR risks, exposed secrets - Unvalidated input reaching sensitive operations - Logging sensitive data, insecure defaults **3. Reliability** - Error handling gaps, silent failures, swallowed exceptions - Missing timeouts, retries without backoff - Unbounded operations on user-controlled data **4. Performance** - N+1 queries, unnecessary loops, memory bloat - Missing pagination, inefficient algorithms - Blocking operations in async context **5. Quality** (lowest priority — skip if trivial) - Missing tests for new functionality - Dead code, duplicated logic - Stale comments, unclear naming - Style issues **only** if they violate project guidelines ### Step 4: Score and Classify For each issue found, assign: | Score | Meaning | Action | |-------|---------|--------| | 90-100 | Critical bug or vulnerability | Must fix | | 70-89 | Real issue, will cause problems | Should fix | | 50-69 | Code smell, needs human judgment | Report only | | < 50 | Minor, likely false positive | Discard | **Discard thresholds:** - Diff mode: discard below 50 - Audit mode: discard below 40 **Classify each issue:** - `blocker` — security, data corruption, crash risk - `important` — likely bug, perf regression, missing validation - `minor` — edge case, maintainability, style ### Step 5: Auto-Fix Apply fixes directly for issues meeting the threshold: - **Diff mode:** fix issues scoring **>= 70** - **Audit mode:** fix issues scoring **>= 80** For each fix: read file → apply edit → verify surrounding code preserved. **Never auto-fix:** - Issues requiring architectural changes - Ambiguous fixes with multiple valid approaches - Issues in test files (report only) After fixing, if any files were modified: ```bash git diff --stat # show what changed ``` ### Step 6: Report **Format:** ``` ## Pre-Review Complete **Risk:** Low / Medium / High **Verdict:** ✅ Clean | ⚠️ Issues found | 🔴 Blockers ### 🔴 Blockers (must fix) 1. **file:line** — Description - Impact: what goes wrong - Fix: applied ✅ | manual required (reason) ### ⚠️ Important (should fix) 1. **file:line** — Description (score: XX) - Fix: applied ✅ | suggestion ### 💡 Minor 1. **file:line** — Description ### Tests to Add - description of test ### Files Modified: N - path/to/file.ts ``` If zero issues found: `## Pre-Review Complete — ✅ Clean. No issues found.` ## Guidelines **DO:** - Fix issues directly, not just report them - Match existing code patterns and style - Be specific: file, line, concrete fix - Prioritize impact over thoroughness **DON'T:** - Fix pre-existing issues in diff mode — only what changed - Bikeshed on style unless it violates project guidelines - Report what a linter or type checker would catch (assume CI handles these) - Make architectural changes or large refactors - Spend tokens on obvious non-issues ## False Positives to Avoid - Pre-existing code not touched by the current change (diff mode) - Intentional patterns that look unusual but are correct - Issues a type checker or linter would flag - Style opinions not grounded in project guidelines - General nitpicks a senior engineer would skip

path: plugins/pre-review/CHANGELOG.md
content: # Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [1.0.0] - 2026-01-24

### Added
- Initial release
- `/pre-review` command for reviewing branch changes before PR
  - 5 parallel Sonnet agents for deep analysis
  - Haiku agents for coordination and confidence scoring
  - Auto-fix for issues with confidence >= 70
  - Git history analysis for regression detection
- `/code-audit` command for auditing existing code
  - Risk-based file prioritization (auth, payments, data access)
  - Security-focused analysis agents
  - Conservative auto-fix threshold (>= 80)
  - Comprehensive audit reports with security checklist
- Support for project guidelines discovery (CLAUDE.md, eslint, prettier, etc.)
- Confidence scoring system (0-100) to filter false positives
- Progress tracking via todo list


path: plugins/pre-review/CLAUDE.md
content: <claude-mem-context>
# Recent Activity

<!-- This section is auto-generated by claude-mem. Edit content outside the tags. -->

### Jan 24, 2026

| ID | Time | T | Title | Read |
|----|------|---|-------|------|
| #2156 | 2:12 AM | ✅ | Pre-review skill plugin extracted to local filesystem | ~289 |
</claude-mem-context>

path: plugins/pre-review/README.md
content: # Pre-Review Skill

A Claude Code skill that performs comprehensive code review and audit using specialized agents and **automatically fixes issues**.

## Why This Exists

The official `code-review` plugin from Claude Code marketplace posts comments on GitHub PRs **after** publication. This creates an inefficient workflow:

```
PR published → review → issues found → comments posted → you fix → update PR
```

This skill inverts the workflow:

```
Code ready → /pre-review → issues found AND fixed → PR published clean
```

## Features

- **6 Parallel Agents**: 5 Sonnet agents for deep analysis + Haiku agents for coordination
- **Auto-Fix**: Issues are fixed directly in your code, not just reported
- **Confidence Scoring**: 0-100 scale filters out false positives (threshold: 70)
- **Guidelines Aware**: Reads CLAUDE.md, eslint, prettier configs
- **Git Context**: Analyzes git history to understand code evolution

## Agent Specializations

### `/pre-review` Agents

| Agent | Focus |
|-------|-------|
| #1 | CLAUDE.md & project guidelines compliance |
| #2 | Bug scanning (logic errors, null handling, etc.) |
| #3 | Git history context (regressions, breaking changes) |
| #4 | Security & performance issues |
| #5 | Code quality & test coverage |
| Haiku | Coordination, eligibility checks, confidence scoring |

### `/code-audit` Agents

| Agent | Focus |
|-------|-------|
| #1 | Security audit (injection, XSS, auth, secrets) |
| #2 | Bug detection (null handling, race conditions, leaks) |
| #3 | Data flow analysis (input validation, trust boundaries) |
| #4 | Performance & resources (N+1, memory, algorithms) |
| #5 | Code quality & maintainability |
| Haiku | Scope discovery, file categorization, deduplication |

## Installation

### Option 1: Install from Local Path

```bash
claude /plugin install /path/to/pre-review-skill
```

### Option 2: Add to Your Plugin Directory

Copy this folder to your Claude Code plugins directory:
- macOS/Linux: `~/.claude/plugins/pre-review-skill/`
- Windows: `%USERPROFILE%\.claude\plugins\pre-review-skill\`

### Option 3: Register as Local Marketplace

```bash
claude /plugin marketplace add /path/to/pre-review-skill
```

## Commands

### `/pre-review` - Review Changes Before PR

```bash
# In any git repository with uncommitted or committed changes on a branch
/pre-review
```

Best for: Feature branches, before opening a PR.

The skill will:
1. Check for changes compared to main/master
2. Discover project guidelines
3. Launch 5 parallel analysis agents
4. Score each issue for confidence
5. **Fix issues directly in your code**
6. Provide a summary report
7. Offer next steps (run tests, review diff, commit)

### `/code-audit` - Audit Existing Code

```bash
# Audit specific paths
/code-audit src/api/

# Audit with file pattern
/code-audit **/*.ts

# Audit entire codebase (will prompt for scope)
/code-audit
```

Best for: Personal repos, reviewing existing code, security audits.

The skill will:
1. Determine audit scope (specific paths or full codebase)
2. Categorize files by risk (auth, payments, data access = high priority)
3. Launch 5 parallel analysis agents
4. Score and deduplicate issues
5. **Auto-fix high-confidence issues (score >= 80)**
6. Generate comprehensive audit report
7. Offer next steps

**Key differences from `/pre-review`:**
- Does NOT require a branch or changes
- Audits code as it exists
- Prioritizes security-sensitive code
- Higher fix threshold (80 vs 70) for more conservative auto-fixing

## Output Examples

### `/pre-review` Output

```
## Pre-Review Complete

### Issues Found and Fixed: 3

1. **src/api/handler.ts:45** - Missing null check before accessing user.email
   - Severity: critical
   - Category: bug
   - Fix applied: Added optional chaining operator

2. **src/utils/parser.js:112** - SQL injection vulnerability in query builder
   - Severity: critical
   - Category: security
   - Fix applied: Used parameterized query

3. **src/components/List.tsx:78** - useEffect missing dependency
   - Severity: important
   - Category: bug
   - Fix applied: Added 'items' to dependency array

### Files Modified: 3
- src/api/handler.ts
- src/utils/parser.js
- src/components/List.tsx

### Recommendations
- Run `npm test` to verify fixes
- Review changes with `git diff`
```

### `/code-audit` Output

```
## Code Audit Report

### Summary
- Files Audited: 24
- Issues Found: 8
- Issues Fixed: 5
- Issues Requiring Manual Review: 3

### Critical Issues (Fixed)

1. **src/auth/login.ts:89** - SQL injection in user lookup
   - Category: security
   - Fix applied: Used parameterized query

2. **src/api/upload.ts:34** - Path traversal vulnerability
   - Category: security
   - Fix applied: Sanitized file path input

### Critical Issues (Manual Review Required)

1. **src/db/migrations.ts:156** - Potential race condition in schema update
   - Category: bug
   - Reason: Requires architectural decision on locking strategy
   - Recommended: Add database-level locking

### Security Summary
- [x] No hardcoded credentials found
- [x] No XSS vulnerabilities found
- [ ] 2 SQL injection risks found and fixed
- [ ] 1 path traversal fixed

### Files Modified: 3
- src/auth/login.ts
- src/api/upload.ts
- src/utils/validate.ts

### Recommendations
- Review manual issues before deploy
- Add integration tests for auth flow
- Consider security audit of remaining modules
```

## Configuration

The skill respects your project's existing configuration:
- `CLAUDE.md` - Project-specific Claude guidelines
- `.eslintrc.*` - ESLint rules
- `.prettierrc` - Prettier configuration
- `tsconfig.json` - TypeScript settings
- `CONTRIBUTING.md` - Contribution guidelines

## Command Comparison

| Aspect | `/pre-review` | `/code-audit` |
|--------|---------------|---------------|
| Requires changes | Yes (branch diff) | No |
| Scope | Changed files only | Any files/paths |
| Auto-fix threshold | 70 | 80 (more conservative) |
| Best for | Before PR | Personal repos, audits |
| Git history analysis | Yes | No |

## Comparison with code-review Plugin

| Aspect | code-review (plugin) | pre-review (this skill) |
|--------|---------------------|------------------------|
| When to run | After PR published | Before PR published |
| Output | GitHub comment | Direct code fixes |
| Workflow | Report issues | Fix issues |
| False positive handling | Threshold 80 | Threshold 70 |
| Use case | Team review bot | Solo dev workflow |

## License

MIT


path: plugins/pre-review/commands/CLAUDE.md
content: <claude-mem-context>
# Recent Activity

<!-- This section is auto-generated by claude-mem. Edit content outside the tags. -->

### Jan 24, 2026

| ID | Time | T | Title | Read |
|----|------|---|-------|------|
| #2734 | 5:23 PM | 🔵 | Verified Code-Audit Command Has Correct YAML Frontmatter | ~269 |
</claude-mem-context>

path: plugins/pre-review/commands/code-audit.md
content: | allowed-tools | description |
|---|---|
| Bash(git *), Read, Edit, Write, Glob, Grep, Task | Audit existing code for bugs, security issues, and quality problems |

# Code Audit: Deep Analysis of Existing Code

Analyze existing code in the repository (or specific paths) for bugs, security issues, and quality problems. Unlike pre-review, this does NOT require a branch or changes - it audits code as it exists.

## Usage

The user may specify:
- Specific files or directories to audit: `/code-audit src/api/`
- File patterns: `/code-audit **/*.ts`
- Nothing (audits entire codebase, with smart prioritization)

## Instructions

Follow these steps precisely:

### Step 0: Initialize Progress Tracking

Create a todo list to track progress through all steps. This provides visibility to the user as the audit progresses.

### Step 1: Scope Discovery (Haiku Agent)

Use a Haiku agent to determine audit scope:

**If user specified paths/patterns:**
- Resolve the paths/patterns to actual files
- Count files and estimate scope
- If > 50 files, ask user to narrow scope or confirm full audit

**If no paths specified:**
- List top-level directories
- Identify main source directories (src/, lib/, app/, etc.)
- Exclude obvious non-code: node_modules, dist, build, vendor, .git
- Propose a reasonable scope to the user

Return the list of files to audit.

### Step 2: Discover Project Guidelines (Haiku Agent)

Use a Haiku agent to find and read:
- Root CLAUDE.md file (if exists)
- Any CLAUDE.md files in directories being audited
- .eslintrc, .prettierrc, tsconfig.json, or similar config files
- Any CONTRIBUTING.md or code style guides
- Package.json or similar to understand the tech stack

Return a summary of:
- Tech stack and framework
- Coding guidelines found
- Key patterns to look for

### Step 3: File Categorization (Haiku Agent)

Use a Haiku agent to categorize files by risk/priority:

**High Priority (audit first):**
- Authentication/authorization code
- Payment/financial logic
- Database queries and data access
- API endpoints and controllers
- Input validation and sanitization
- File upload/download handlers
- Encryption/security utilities

**Medium Priority:**
- Business logic
- Service layers
- Utility functions
- State management

**Low Priority:**
- Tests (unless specifically requested)
- Configuration
- Types/interfaces only
- Constants

Return categorized file list.

### Step 4: Parallel Deep Analysis (5 Sonnet Agents)

Launch 5 parallel Sonnet agents to analyze the high and medium priority files. Each agent should return:
- List of specific issues found
- File path and line numbers
- Severity (critical, important, minor)
- Suggested fix
- Confidence score (0-100)

**Agent #1 - Security Audit:**
Scan for security vulnerabilities:
- SQL/NoSQL injection
- XSS vulnerabilities
- Command injection
- Path traversal
- Insecure deserialization
- Hardcoded secrets/credentials
- Weak cryptography
- Authentication bypasses
- Authorization flaws
- SSRF vulnerabilities

**Agent #2 - Bug Detection:**
Scan for bugs and logic errors:
- Null/undefined handling issues
- Off-by-one errors
- Race conditions
- Resource leaks (memory, file handles, connections)
- Infinite loops or recursion
- Dead code paths
- Unreachable code
- Type coercion issues
- Async/await mistakes
- Error swallowing

**Agent #3 - Data Flow Analysis:**
Trace data through the application:
- Unvalidated user input reaching sensitive operations
- Data leaks (logging sensitive data, exposing in errors)
- Missing input sanitization
- Inconsistent data validation
- Trust boundary violations

**Agent #4 - Performance & Resources:**
Identify performance issues:
- N+1 query patterns
- Missing pagination
- Unbounded loops over user data
- Memory accumulation
- Blocking operations in async context
- Missing caching opportunities
- Inefficient algorithms (O(n^2) when O(n) possible)
- Large payload handling

**Agent #5 - Code Quality & Maintainability:**
Check code health:
- Functions/methods too long (> 50 lines)
- High cyclomatic complexity
- Deep nesting (> 4 levels)
- Duplicated logic
- Missing error handling
- Inconsistent patterns
- Outdated patterns (callbacks vs promises vs async/await)
- Dead code
- TODOs and FIXMEs that look critical

### Step 5: Issue Deduplication & Scoring (Haiku Agent)

Use a Haiku agent to:
- Remove duplicate issues found by multiple agents
- Merge related issues
- Re-score based on full context

Scoring criteria:
- **90-100:** Critical security or data loss risk. Must fix.
- **70-89:** Real bug that will cause problems. Should fix.
- **50-69:** Code smell or potential issue. Consider fixing.
- **Below 50:** Minor or stylistic. Note but don't fix automatically.

### Step 6: Fix High-Confidence Issues

For issues scoring >= 80, **fix directly**:

1. Read the file containing the issue
2. Apply the fix using Edit tool
3. Verify the fix doesn't break surrounding code

**DO NOT auto-fix:**
- Issues that require architectural changes
- Issues where the fix is ambiguous
- Issues in test files (report only)
- Issues scoring below 80

### Step 7: Audit Report

Generate a comprehensive report:

```
## Code Audit Report

### Summary
- Files Audited: X
- Issues Found: Y
- Issues Fixed: Z
- Issues Requiring Manual Review: W

### Critical Issues (Fixed)

1. **[file:line]** - Description
   - Category: security/bug/performance/quality/guidelines
   - Fix applied: Description of fix

### Critical Issues (Manual Review Required)

1. **[file:line]** - Description
   - Category: security/bug/performance/quality/guidelines
   - Reason not auto-fixed: Requires architectural decision
   - Recommended fix: Description

### Important Issues

1. **[file:line]** - Description
   - Confidence: XX%
   - Suggested fix: Description

### Minor Issues & Code Smells

1. **[file:line]** - Brief description

### Security Summary
- [ ] No hardcoded credentials found / X instances found
- [ ] No SQL injection risks / X potential risks
- [ ] No XSS vulnerabilities / X potential vulnerabilities
- [ ] Input validation adequate / X gaps found

### Files Modified
- path/to/file1.js
- path/to/file2.ts

### Recommendations
- Priority items for manual review
- Suggested refactoring opportunities
- Tests to add
```

### Step 8: Offer Next Steps

Ask the user:
- "Review specific issues in detail?"
- "Run tests to verify fixes?"
- "Audit additional directories?"
- "Generate a TODO list for manual fixes?"

## Important Guidelines

- **DO fix clear bugs and security issues** with high confidence
- **DON'T make sweeping changes** - focus on real problems
- **DON'T refactor working code** unless it has actual bugs
- **DO preserve existing patterns** - match the codebase style
- **DO be conservative** - when in doubt, report instead of fix
- **DON'T audit node_modules, vendor, or generated code**

## Confidence Scoring Guide

- **100:** Definite bug/vulnerability with clear evidence
- **90:** Very likely real issue, straightforward fix
- **80:** Real issue, fix is clear but verify
- **70:** Probably real, but context might change assessment
- **60:** Possible issue, needs human judgment
- **50:** Code smell, not necessarily wrong
- **Below 50:** Stylistic or very minor

## Notes

- For large codebases, suggest auditing one module at a time
- Prioritize security-sensitive code (auth, payments, data access)
- Update todo list as you complete each step
- If no issues found, confirm the code looks healthy
- Always provide actionable recommendations


path: plugins/pre-review/commands/pre-review.md
content: | allowed-tools | description |
|---|---|
| Bash(git *), Read, Edit, Write, Glob, Grep, Task | Pre-review code and fix issues before publishing PR |

# Pre-Review: Analyze and Fix Code Before PR

Analyze the current branch changes compared to main/master and **fix issues directly** instead of just commenting.

## Instructions

Follow these steps precisely:

### Step 0: Initialize Progress Tracking

Create a todo list to track progress through all steps. This provides visibility to the user as the review progresses.

### Step 1: Eligibility Check (Haiku Agent)

Use a Haiku agent to check:
- Is there a branch with uncommitted or committed changes compared to main/master?
- Are there actual code changes to review? (Config/docs-only changes don't need pre-review - inform user and stop)

If no meaningful changes exist, inform the user and stop.

### Step 2: Discover Project Guidelines (Haiku Agent)

Use a Haiku agent to find and read:
- Root CLAUDE.md file (if exists)
- Any CLAUDE.md files in directories with modified files
- .eslintrc, .prettierrc, tsconfig.json, or similar config files that define code standards
- Any CONTRIBUTING.md or code style guides

Return a summary of the coding guidelines found.

### Step 3: Get Change Summary (Haiku Agent)

Use a Haiku agent to:
- Run `git diff main...HEAD` (or master) to see all changes
- Return a structured summary of what files changed and the nature of changes

### Step 4: Parallel Deep Analysis (5 Sonnet Agents)

Launch 5 parallel Sonnet agents to independently analyze the changes. Each agent should return:
- List of specific issues found
- File path and line numbers
- Severity (critical, important, minor)
- Suggested fix

**Agent #1 - CLAUDE.md/Guidelines Compliance:**
Audit the changes to ensure they comply with project guidelines (CLAUDE.md, eslint rules, etc.). Check:
- Naming conventions
- Code patterns required by the project
- Forbidden patterns or anti-patterns
- Documentation requirements

**Agent #2 - Bug Scanner:**
Read the file changes and scan for obvious bugs:
- Logic errors
- Off-by-one errors
- Null/undefined handling issues
- Race conditions
- Resource leaks
- Error handling gaps
Focus on real bugs, not style issues.

**Agent #3 - Git History Context:**
Read git blame and history of modified code to identify:
- Regressions (re-introducing old bugs)
- Breaking changes to stable code
- Patterns that were intentionally changed before
- Context from previous commits that affects current changes

**Agent #4 - Security & Performance:**
Scan for:
- Security vulnerabilities (injection, XSS, auth issues, exposed secrets)
- Performance issues (N+1 queries, unnecessary loops, memory leaks)
- API misuse
- Unsafe operations

**Agent #5 - Code Quality & Tests:**
Check for:
- Missing or inadequate tests for new functionality
- Dead code introduced
- Duplicated logic that should be refactored
- Inconsistent error handling
- Comments that need updating due to code changes

### Step 5: Confidence Scoring (Haiku Agents)

For each issue found in Step 4, launch a parallel Haiku agent to score confidence (0-100):

- **90-100:** Critical bug or security issue. Clear evidence. Must fix.
- **70-89:** Real bug that will cause problems. Should fix.
- **50-69:** Code smell or potential issue. Consider fixing.
- **Below 50:** Minor, stylistic, or likely false positive. Skip.

Filter out issues scoring below 70.

### Step 6: Fix Issues Directly

For each remaining issue (score >= 70), **fix it directly in the code**:

1. Read the file containing the issue
2. Apply the fix using Edit tool
3. Verify the fix doesn't break surrounding code

Group fixes by file to minimize edits.

### Step 7: Summary Report

After fixing, provide a summary to the user:

```
## Pre-Review Complete

### Issues Found and Fixed: X

1. **[file:line]** - Brief description of issue
   - Severity: critical/important/minor
   - Category: security/bug/performance/quality/guidelines
   - Fix applied: Brief description of fix

2. ...

### Issues Skipped (Low Confidence): Y

1. **[file:line]** - Brief description (score: XX)
   - Reason for low confidence

### Files Modified: Z
- path/to/file1.js
- path/to/file2.ts

### Recommendations
- Any manual review suggestions
- Tests to run
- Areas needing human judgment
```

### Step 8: Offer Next Steps

Ask the user:
- "Run tests to verify fixes?"
- "Review the changes with `git diff`?"
- "Commit the fixes?"

## Important Guidelines

- **DO fix issues directly** - Don't just report, actually edit the code
- **DON'T break working code** - If unsure about a fix, skip it and report
- **DON'T fix pre-existing issues** - Only fix issues in the changed code
- **DON'T make style-only changes** unless explicitly required by guidelines
- **DO preserve code intent** - Fixes should maintain the original purpose
- **DO group related fixes** - Multiple issues in same file = single edit session

## False Positives to Avoid

- Pre-existing issues not introduced by current changes
- Issues a linter/typechecker would catch (assume CI runs these)
- Pedantic nitpicks a senior engineer wouldn't flag
- General quality issues not in project guidelines
- Intentional changes that look unusual but are correct
- Code outside the scope of current changes

## Notes

- Use `git diff main...HEAD` to see changes (or master if no main)
- Update todo list as you complete each step
- If no issues found, congratulate the user on clean code
- Always show what was fixed so user can verify


path: tests/trigger-prompts.csv
content: prompt,expected_skill,should_trigger
"Review this code before I open a PR",pre-review-skill,true
"Check my changes for bugs and issues",pre-review-skill,true
"Revisa esse código antes de commitar",pre-review-skill,true
"Audit this diff for security problems",pre-review-skill,true
"Find issues in my code changes",pre-review-skill,true
"Does this code have any obvious bugs?",pre-review-skill,true
"Write a new feature for user authentication",pre-review-skill,false
"Refactor this module to use async/await",pre-review-skill,false
"Check the GitHub CI status",pre-review-skill,false
"Show me open PRs",pre-review-skill,false
"Sync my fork with upstream",pre-review-skill,false


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: suspicious | SkillSpector: suspicious (CRITICAL)