grill

Grill the current changes before they become a PR. Fan out independent reviewers to attack your diff from every angle.

/grill reviews a diff — code you've already written, on its way to a PR. To grill an approach before any code exists, use /plan instead. (Same adversarial fan-out, different target: /plan attacks the reasoning, /grill attacks the change.)

Steps

1. Read the working tree as one payload: git diff HEAD (staged and unstaged in a single patch — not git diff plus a separate git diff --cached, which splits a file that is staged and further edited into two half-patches no reviewer sees whole), then append the contents of every untracked, non-ignored file (git ls-files --others --exclude-standard) under a heading marking them as new files. An untracked file appears in no git diff output at all, so a whole new module would otherwise be grilled as if it didn't exist. Skip binaries; name anything you skip for size. If the diff is empty and there are no untracked files, say there's nothing to grill and stop.

2. If that payload is only prose doc/config changes, skip the fan-out — there's nothing to attack. Note it and stop. Embedded code counts as executable — a changed .md carrying a fenced ```js/```ts/```sh block (e.g. a slash-command Workflow script) is in scope, even when every changed file is a .md.

3. Grill the diff adversarially. Reviewing your own diff self-anchors — you defend the choices you just made. Instead, fan out independent reviewer subagents, each a fresh context with one lens, none of them attached to the code. Synthesis stays with you (the main loop).

   Size the grill to the diff — this is the cost dial; don't throw 8 Opus reviewers at a one-file change. Announce the setup in one line and let the user retune before launching. Invoking /grill is your opt-in to run the Workflow, so don't ask whether — only let them change the model or lens set:

   • Small (a focused change — one file or one concern) → the core 4 lenses (★) on Sonnet.
   • Large (cross-cutting, multiple files/subsystems, or security-sensitive) → all 8 lenses on Opus.
   • e.g. "Small diff → core 4 lenses on Sonnet. Say 'opus' or 'all 8' to widen, otherwise I'll launch."
   • Frontend diffs (changed .tsx/.jsx/.vue/.svelte/.html or component/page files) → invoke the test-locators skill first (it carries the authoritative convention), then add the locators lens below to whichever set you chose. Skip it for backend-only diffs.

   The lenses (core 4 marked ★) — each reviewer gets exactly one:

   • ★ correctness — What input breaks this hunk? What edge case is assumed away (empty, null, boundary, large)?
   • ★ failure_modes — What happens on network error, disk full, parse error, null? Any swallowed error or unhandled rejection?
   • ★ tests — What does each test actually assert? Could it pass without the code under test doing anything? What path is untested?
   • ★ architecture — Layering, naming, dependency choices, abstraction shape. Does this fight the grain of the surrounding code?
   • concurrency — What if two callers hit this simultaneously? What if the request is retried? Any shared mutable state?
   • observability — How would we notice if this silently misbehaved in prod? Are the new failure paths logged/measured?
   • scope — What was added that the task didn't require? A premature abstraction, an unrelated refactor bundled in?
   • security — Untrusted input reaching a sink (SQL, shell, fs, HTML)? A missing authz check? A secret logged or committed?
   • locators (frontend diffs only) — Apply the test-locators skill: every interactive or asserted element (button, link, input, select, checkbox, form, modal, list item) needs a stable data-testid/data-test; flag missing ones and brittle names (position/index/CSS-class/color, e.g. country-card-0). Names should be <feature>-<element>-<purpose>, kebab-case, by business meaning.