Adversarial Code Review Before Merge
Hostile multi-lens review of a diff that hunts the bugs agreeable reviews miss, with ranked, evidence-backed must-fix findings.
Before & after
Same prompt, same agent — the only difference is the skill.
I can review your recent changes and look for issues. I'd check things like code quality, design patterns, performance considerations, and whether the logic is sound. Let me know what files you want me to look at, and I can give you some feedback. I'll try to be thorough, though I might not catch everything. Is there anything specific you're concerned about?
ADVERSARIAL REVIEW: Recent Code Changes
REVIEWER 1: Hostile Performance Critic
"Your database query in line 23 fetches all user comments before filtering by date. At scale, this is a classic N+1 trap. You're doing 1 query per user per page load. With 100K users, you've built yourself a denial-of-service vulnerability. Add a WHERE clause on the database side, not in JavaScript."
"Verdict: BLOCKER. Rewrite before merge."
REVIEWER 2: Security Hardliner
"API endpoint /api/comments/{id} returns entire comment object including user_id without authorization check (line 45). What stops me from incrementing the ID in the URL to read everyone's comments? Even if users are 'anonymous', this leaks correlation data."
"Also: You're not validating the id parameter is numeric. Regex bypass possible."
"Verdict: CRITICAL SECURITY ISSUE. Reject this PR."
REVIEWER 3: Test Coverage Examiner
"You modified authentication logic (auth.ts lines 12-34) but added zero new tests. The existing test file hasn't been touched. How do I know this doesn't break token refresh on mobile? Or handle clock skew?"
"Coverage dropped from 87% to 79%. This PR removes guardrails without explanation."
"Verdict: REJECT. Require test coverage above baseline before resubmitting."
REVIEWER 4: API Contract Guardian
"You changed the response schema for POST /api/comments. Old: {id, text, author}. New: {id, text, author, createdAt, metadata}. This breaks any client expecting the old shape. Where's the migration plan? Will old clients break silently?"
"No deprecation period, no changelog entry, no backward-compatible flag."
"Verdict: BLOCKERS. Add version header or dual-response support."
SUMMARY
4 Blockers: Database query design, unauthorized API access, missing tests, schema breaking change
3 Nice-to-haves: Logging verbosity, variable naming clarity, comment documentation
Confidence in your review: Low (self-review likely agrees with everything you wrote)About this skill
Your PR got a "LGTM, nice work" and then broke in production on a double-click, a missing ownership check, or a swallowed exception. Reviews by the same model or the same team share the author's blind spots. They read the code the way it was meant to run, not the way it will be abused. This skill reviews your diff as a hostile reviewer. It attacks the change from fixed angles and reports only findings it can back with a concrete triggering input.
What it does
- Runs six hostile lenses over the diff: attacker, concurrency and state, scale, failure paths, 3am operator, and unstated requirements.
- Requires a trigger for every finding (this input or sequence leads to this wrong outcome). Vague worries become labeled questions instead of padding the report.
- Tries to refute each finding before reporting it, and marks a finding conditional when the code that would refute it is not visible.
- Checks the boundary between changed and unchanged code: callers, deleted guards, default and config changes, migration and deploy ordering.
- Audits the tests, flagging tests that execute code without asserting anything, and mocks that stub out the exact thing that breaks.
- Ranks findings by blast radius, likelihood, and reversibility. Each lens ends with an explicit "cleared" line so nothing passes as a silent "looks fine."
What you get
A ranked review: must-fix findings with trigger, impact, and a concrete fix, then should-fix items, questions for the author, a capped list of nits, and a per-lens clearance list that states what was checked and what could not be.
Best for
Developers and tech leads merging AI-written or self-written code, teams whose reviews keep missing the same class of bug, and anyone shipping changes to auth, payments, data migrations, or concurrent workflows.
SKILL.md preview
---
name: adversarial-code-review-before-merge
description: Reviews a code diff as a hostile reviewer. Runs six fixed attack lenses (attacker, concurrency/state, scale, failure paths, 3am operator, unstated requirements), requires a concrete triggering input for every finding, tries to refute each finding before reporting it, and ranks results by blast radius. Use when the user says "review this PR hard", "be brutal about this diff", "the last review was too easy", "what will break in prod", "tear this apart before I merge", "you keep saying my code looks fine", or "our reviews keep missing bugs like this".
---
# Adversarial Code Review Before Merge
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.