grill-me

Estrellas10

Forks5

Actualizado9 de julio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

rajitsaha

rajitsaha/100xprism

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.