grill-me

Stars10

Forks5

UpdatedJuly 9, 2026 at 16:51

Adversarial code review before a PR — Claude asks hard questions until you pass the test. Also supports elegant rewrites ("scrap this and implement the elegant solution") and spec-driven development. Use before opening any pull request. For mechanically finding bugs in a diff, prefer a platform-native code-review skill; this is the human-gate interrogation.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

rajitsaha

rajitsaha/100xprism

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	grill-me
description	Adversarial code review before a PR — Claude asks hard questions until you pass the test. Also supports elegant rewrites ("scrap this and implement the elegant solution") and spec-driven development. Use before opening any pull request. For mechanically finding bugs in a diff, prefer a platform-native code-review skill; this is the human-gate interrogation.
category	engineering
tier	core
slash_command	/grill
allowed-tools	Bash(git:*) Read Grep Glob

Grill — Adversarial Code Review

Enter adversarial review mode. Challenge the current changes before a PR is created. Do not approve until satisfied.

How to use

/grill — adversarial review of current diff before /pr
/grill rewrite — scrap and implement the elegant solution
/grill spec — write detailed specs before handing off work

Mode A — Code Review (default)

PROJECT_ROOT=$(git rev-parse --show-toplevel)
cd "$PROJECT_ROOT"
git diff main
git diff --staged

Read the diff. Identify risks:

Does this handle the unhappy path?
Are there race conditions or async issues?
Is this the right abstraction (over- or under-engineered)?
Will this break anything that depends on it?
Are tests missing for the new behaviour?
Is the naming clear to someone reading this cold?
Could this be 50% simpler?

Ask the user 3–5 hard, specific questions about the changes. Do not accept vague answers — probe further. Only approve (and proceed with /pr) once satisfied.

Mode B — Elegant Rewrite

After a messy fix, start fresh:

Identify the root insight that makes the solution simple
Rewrite with that insight as the foundation — no legacy cruft
The elegant solution is usually 30–50% less code

Mode C — Spec-Driven Development

Ask clarifying questions until requirements are unambiguous. Produce a written spec (inputs, outputs, edge cases, acceptance criteria). Only begin implementation once spec is approved.

GATE: User has answered all questions satisfactorily. Only then proceed to /pr.

More from this repository

same repository

copywriting

rajitsaha/100xprism

When the user wants to write, rewrite, or improve marketing copy for any page — homepage, landing, pricing, feature, about, or product pages; "headline help," "CTA copy," "value proposition," "tagline," "hero section," "make this more compelling," "conversion copy," or complete Figma-ready full-page copy (see Full-Page Mode below). For email copy, see email-sequence. For popups, see popup-cro. For editing existing copy, see copy-editing.

2026-07-2410

page-cro

rajitsaha/100xprism

When the user wants to increase conversions on any marketing page — homepage, landing, pricing, feature, or blog; "CRO," "this page isn't converting," "low conversion rate," "bounce rate," "my landing page sucks" — or just shares a URL asking for feedback. For signup flows, see signup-flow-cro; post-signup activation, onboarding-cro; forms, form-cro; popups, popup-cro.

2026-07-2410

seo-audit

rajitsaha/100xprism

When the user wants to audit or diagnose SEO issues — "technical SEO," "why am I not ranking," "meta tags review," "my traffic dropped," "Google update hit me," "core web vitals," "crawl errors," "indexing issues," or even a vague "my SEO is bad." For pages at scale, see programmatic-seo. For structured data, see schema-markup. For AI search, see ai-seo.

2026-07-2410

pair-loop

rajitsaha/100xprism

Coder<->reviewer handoff loop (Claude<->Codex, roles swappable) with self-instrumented per-round cost tracking. Loops locally via HANDOFF.md until approved, then opens a PR with the full transcript.

2026-07-1010

a11y-auditor

rajitsaha/100xprism

Act as a Senior Accessibility Engineer to audit a page, component, or design against WCAG 2.2 AA. Produces a triaged finding list (critical/serious/moderate), focus-order map, contrast report, ARIA decision tree, and a screen-reader test plan. Use when shipping new UI, hardening an existing flow, or preparing for VPAT/accessibility conformance.

2026-07-0910

ab-test-setup

rajitsaha/100xprism

When the user wants to plan, design, or implement an A/B test or experiment — "split test," "variant copy," "multivariate test," "hypothesis," "statistical significance," "how long should I run this test," or comparing two versions. For tracking implementation, see analytics-tracking. For page-level conversion optimization, see page-cro.

2026-07-0910

name	grill-me
description	Adversarial code review before a PR — Claude asks hard questions until you pass the test. Also supports elegant rewrites ("scrap this and implement the elegant solution") and spec-driven development. Use before opening any pull request. For mechanically finding bugs in a diff, prefer a platform-native code-review skill; this is the human-gate interrogation.
category	engineering
tier	core
slash_command	/grill
allowed-tools	Bash(git:*) Read Grep Glob

Grill — Adversarial Code Review

Enter adversarial review mode. Challenge the current changes before a PR is created. Do not approve until satisfied.

How to use

/grill — adversarial review of current diff before /pr
/grill rewrite — scrap and implement the elegant solution
/grill spec — write detailed specs before handing off work

Mode A — Code Review (default)

PROJECT_ROOT=$(git rev-parse --show-toplevel)
cd "$PROJECT_ROOT"
git diff main
git diff --staged

Read the diff. Identify risks:

Does this handle the unhappy path?
Are there race conditions or async issues?
Is this the right abstraction (over- or under-engineered)?
Will this break anything that depends on it?
Are tests missing for the new behaviour?
Is the naming clear to someone reading this cold?
Could this be 50% simpler?

Ask the user 3–5 hard, specific questions about the changes. Do not accept vague answers — probe further. Only approve (and proceed with /pr) once satisfied.

Mode B — Elegant Rewrite

After a messy fix, start fresh:

Identify the root insight that makes the solution simple
Rewrite with that insight as the foundation — no legacy cruft
The elegant solution is usually 30–50% less code

Mode C — Spec-Driven Development

Ask clarifying questions until requirements are unambiguous. Produce a written spec (inputs, outputs, edge cases, acceptance criteria). Only begin implementation once spec is approved.

GATE: User has answered all questions satisfactorily. Only then proceed to /pr.