Git pr Auditor

The Problem

Your CI pipeline passes green, the linter is happy, and tests cover the happy path. But the PR you just approved has a hardcoded API key on line 45, SQL string concatenation on line 12, and a TODO comment promising to handle the error case "later." By the time someone notices, it's been in production for three weeks and is now part of the "tech debt backlog" that never gets addressed.

What You Get

• Security-focused critical scanning — detects hardcoded secrets, SQL injection patterns, command injection (os.system, exec, shell=True), path traversal, insecure random, XSS via innerHTML/dangerouslySetInnerHTML, and missing auth checks on sensitive endpoints
• Code quality warning detection — flags TODO/FIXME/HACK comments, console.log/print in production code, unused imports, magic numbers, functions over 50 lines, deeply nested conditionals, error swallowing, and race condition patterns
• Multi-file-type categorization — automatically groups changed files (Backend, Frontend, Config, Database, Tests, Docs) and applies category-specific audit rules
• Severity-ranked audit report — produces a structured Markdown report with Critical/Warning/Info tables showing file path, line number, and specific issue description
• Diff-aware analysis — focuses only on what changed, not the entire codebase, so findings are relevant to the specific PR or commit
• Blocker identification — summarizes which issues must be fixed before merge versus which are recommendations for the next sprint

Why This Beats Prompting It Yourself

A linter checks syntax. A code reviewer checks logic. This skill checks for the patterns that fall between — security anti-patterns that compile fine, quality issues that work but create maintenance burden, and style violations that indicate architectural drift. It reads the diff as a security auditor would, not as a syntax checker, catching the issues that neither the compiler nor the linter were designed to find.

Example Session

You: "Audit the diff between main and my feature/auth branch"

Agent: "PR Audit Report — feature/auth vs main — 12 files, +347/-89 lines

Critical — Security Issues (2):

File               Line  Issue
─────────────────  ────  ──────────────────────────────────────────────
src/auth/login.ts  45    Hardcoded API key sk_live_abc123... in source
src/db/query.ts    12    SQL injection via string concatenation: SELECT
                         * FROM users WHERE id = ${userId}

Warning — Code Quality (3):

File                  Line  Issue
────────────────────  ────  ───────────────────────────────────────
src/utils/helpers.ts  88    TODO comment: 'handle rate limiting'
src/api/users.ts      34    console.log('debug: user created') in
                            production
src/auth/tokens.ts    67    Error swallowed: catch block only logs,
                            doesn't re-throw

Info — Best Practices (4):

File                Line  Issue
──────────────────  ────  ───────────────────────────────────
src/types/index.ts  5     Missing JSDoc on exported interface

Blockers: 2 critical issues MUST be fixed before merge. Recommendations: 3 warning-level issues worth addressing in this cycle."

Use Cases

• Pre-merge review on security-sensitive PRs (auth, payments, data access)
• Staged changes audit before committing locally
• CI/CD integration as a pre-merge quality gate
• Onboarding a new contributor by showing them what their diff introduces
• Quick sanity check on hotfix PRs where review time is compressed

Known Limitations

This skill is read-only — it scans diffs and generates reports but never modifies code or commits. It works best when given explicit diff ranges; vague "review this project" requests may produce too broad or too narrow results. Deep semantic analysis (e.g., "will this race condition manifest under load") is beyond its scope.