dev-requesting-code-review

Pre-Commit Code Verification

Automated verification pipeline before code lands. Static scans, baseline-aware quality gates, an independent reviewer subagent, and an auto-fix loop.

Core principle: No agent should verify its own work. Fresh context finds what you miss.

When to Use

• After implementing a feature or bug fix, before git commit or git push
• When user says "commit", "push", "ship", "done", "verify", or "review before merge"
• After completing a task with 2+ file edits in a git repo
• After each task in subagent-driven-development (the two-stage review)

Skip for: documentation-only changes, pure config tweaks, or when user says "skip verification".

This skill vs github-code-review: This skill verifies YOUR changes before committing. github-code-review reviews OTHER people's PRs on GitHub with inline comments.

Step 1 — Get the diff

git diff --cached

If empty, try git diff then git diff HEAD~1 HEAD.

If git diff --cached is empty but git diff shows changes, tell the user to git add <files> first. If still empty, run git status — nothing to verify.

If the diff exceeds 15,000 characters, split by file:

git diff --name-only
git diff HEAD -- specific_file.py

Step 2 — Static security scan

Scan added lines only. Any match is a security concern fed into Step 5.

# Hardcoded secrets
git diff --cached | grep "^+" | grep -iE "(api_key|secret|password|token|passwd)\s*=\s*['\"][^'\"]{6,}['\"]"

# Shell injection
git diff --cached | grep "^+" | grep -E "os\.system\(|subprocess.*shell=True"

# Dangerous eval/exec
git diff --cached | grep "^+" | grep -E "\beval\(|\bexec\("

# Unsafe deserialization
git diff --cached | grep "^+" | grep -E "pickle\.loads?\("

# SQL injection (string formatting in queries)
git diff --cached | grep "^+" | grep -E "execute\(f\"|\.format\(.*SELECT|\.format\(.*INSERT"

Step 3 — Baseline tests and linting

Detect the project language and run the appropriate tools. Capture the failure count BEFORE your changes as baseline_failures (stash changes, run, pop). Only NEW failures introduced by your changes block the commit.