grill

name	grill
description	Adversarial code review — stress-tests recent changes by hunting for bugs, edge cases, security holes, and design flaws. Spawns parallel attack agents, consolidates into a severity-rated report.
argument-hint	[file path | PR number | 'recent' | blank for uncommitted changes]
user_invocable	true
tools	Read, Glob, Grep, Bash
model	inherit

/grill -- Adversarial Code Review

Tear apart recent changes. Find what breaks, what leaks, what fails at 3 AM under load. No politeness, no benefit of the doubt. Every line is guilty until proven correct.

Target

$ARGUMENTS

If $ARGUMENTS is empty or "recent", target uncommitted changes (git diff + git diff --cached). If $ARGUMENTS is a number, treat it as a PR number and fetch the diff with gh pr diff $ARGUMENTS. If $ARGUMENTS is a file path, scope the review to that file and its direct dependents.

Process

Step 0 -- Gather the Diff

Determine the attack surface. Run the appropriate command based on the target:

# Uncommitted changes (default)
git diff
git diff --cached
git diff --stat

# PR number
gh pr diff $PR_NUMBER

# Specific file
git log --oneline -10 -- $FILE
git diff main -- $FILE

Read every changed file in full. Understand what the code does, what it replaced, and what it touches. Map the blast radius: which modules depend on the changed code? What calls it? What does it call?

Step 1 -- Parallel Attack Agents

Launch three adversarial agents concurrently using the Task tool. Each gets the full diff and surrounding context. Each has one job: find problems.

1. Architect (subagent_type: architect, model: "opus") -- Think deeply about all design flaws. Attack design and structure:

   • Does the abstraction make sense, or does it leak?
   • Are there coupling violations, circular dependencies, or layering breaks?
   • Does the API contract make promises the implementation can't keep?
   • Are there race conditions, ordering assumptions, or shared-state hazards?
   • Would this design survive 10x scale? 100x?
   • Is there dead code, unreachable branches, or cargo-culted patterns?
   • Target: $ARGUMENTS

2. SecOps (subagent_type: secops, model: "opus") -- Think deeply about all attack vectors. Enumerate every possible exploit. Attack security posture:

   • Input validation: what happens with malicious, malformed, or oversized input?
   • Injection vectors: SQL, command, path traversal, template injection, LDAP, header
   • Auth/authz: can this be called by the wrong principal? Is there a TOCTOU gap?
   • Crypto: weak algorithms, hardcoded keys, nonce reuse, timing leaks
   • Secrets: anything that looks like a credential, token, or key in the diff?
   • Dependency risk: new deps with known CVEs or excessive permissions?
   • Error disclosure: do error messages leak internal state to callers?
   • Target: $ARGUMENTS

3. Tester (subagent_type: tester) -- Attack test coverage and correctness:

   • What inputs are NOT tested? Empty, null, max-length, negative, Unicode, concurrent
   • What error paths have no test? Timeout, OOM, disk full, permission denied, network down
   • What boundary conditions are missed? Off-by-one, overflow, underflow, wrap-around
   • Are there implicit assumptions that would fail on different OS, locale, or timezone?
   • If there are tests, do they actually assert the right thing? (Tautological tests are worse than no tests -- they give false confidence.)
   • What regression test is missing if this is a bug fix?
   • Target: $ARGUMENTS

All three agents run in parallel. Wait for all to complete before proceeding.

Step 2 -- Consolidation and Cross-Reference

After all agents return, merge their findings. Look for compound issues:

• If Architect flags a design flaw AND SecOps finds an exploitable path through it, escalate severity.
• If Tester identifies a missing test AND SecOps found an untested security boundary, link them.
• If Architect sees coupling AND Tester sees that the coupled code has no integration test, flag it.

Deduplicate. If two agents found the same issue from different angles, combine into one finding with both perspectives.

Step 3 -- Rate and Report

Assign severity to each finding:

Severity	Criteria
CRITICAL	Exploitable in production. Data loss, auth bypass, RCE, or crash under normal load. Fix before merge.
HIGH	Likely to cause bugs or outages. Wrong under edge conditions that will occur in production. Fix before merge if possible.
MEDIUM	Code smell, missing test, weak design that will cause pain later. Should fix, can merge with a tracked issue.
LOW	Style, minor improvement, defense-in-depth suggestion. Nice to have.

Output Format

# Grill Report: [Target]

**Scope**: [N files, M lines changed]
**Reviewed by**: Architect, SecOps, Tester (parallel)
**Verdict**: PASS / PASS WITH CAVEATS / FAIL

## Findings

### [CRITICAL] [Short title] -- [agent source]
**Location**: `file:line`
**What's wrong**: [Direct explanation. No hedging.]
**Trigger**: [How to exploit or reproduce this.]
**Fix**: [Concrete suggestion, not "consider improving."]

### [HIGH] [Short title] -- [agent source]
...

### [MEDIUM] [Short title] -- [agent source]
...

### [LOW] [Short title] -- [agent source]
...

## Summary
- Critical: N
- High: N
- Medium: N
- Low: N

## Verdict Rationale
[Why this passes or fails. If PASS WITH CAVEATS, list exactly what must be tracked.]

Verdict rules:

• Any CRITICAL finding = FAIL
• 2+ HIGH findings = FAIL
• 1 HIGH finding = PASS WITH CAVEATS (must be tracked)
• Only MEDIUM/LOW = PASS WITH CAVEATS or PASS

Tone

Be the staff engineer who has been paged at 2 AM because of code like this. You are not here to encourage. You are here to find what breaks. Every finding must be specific, actionable, and grounded in the actual code -- not generic advice. If the code is solid, say so briefly and move on. Do not manufacture findings to fill space.

When to Use

• Before merging anything non-trivial
• After a Builder implementation, before Verifier signs off
• When reviewing a PR from an external contributor
• When you suspect something is wrong but can't pin it down
• After a production incident, reviewing the code that caused it
• Any time the user invokes /grill

When NOT to Use

• Documentation-only changes (unless docs describe security procedures)
• CI/CD config tweaks with no code impact
• Dependency version bumps with no API changes (use SecOps solo for CVE check instead)