Run any Skill in Manus with one click

grill-me

Stars2

Forks1

UpdatedMarch 13, 2026 at 23:25

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.

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.

Run Skill in Manus

Source

bongrealty

bongrealty/skillcraft

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

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.
license	MIT
compatibility	Designed for Claude Code. Requires a git repository.
metadata	{"author":"rajit","version":"1.0"}
allowed-tools	Bash(git:*) Read Grep Glob

Enter adversarial review mode. Challenge the current changes, implementation, or approach. Do not make a PR or proceed until the user passes the review.

Modes

A. Code Review (default)

"Grill me on these changes and don't make a PR until I pass your test."

Read the current diff (git diff main or staged changes)
Identify risks: edge cases, missing error handling, performance issues, security holes, missing tests, unclear naming
Ask the user 3–5 hard, specific questions about the changes
Do not accept vague answers — probe further if needed
Only approve (and proceed with PR) once you're satisfied
Alternatively: "Prove to me this works" → diff behavior between main and feature branch, run tests, check logs

B. Elegant Rewrite

"Knowing everything you know now, scrap this and implement the elegant solution."

After a mediocre or working-but-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

C. Spec-Driven Development

"Write detailed specs before handing off this work."

Ask the user clarifying questions until requirements are unambiguous
Produce a written spec: inputs, outputs, edge cases, constraints, acceptance criteria
Only begin implementation once the spec is approved
The more specific the spec, the better the output

Review Checklist (Mode A)

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

Example

User: grill me on these changes and don't make a PR until I pass your test
→ Claude reads diff, asks 4 hard questions
→ User answers
→ Claude probes weak answers
→ User satisfies all concerns
→ Claude: "You passed. Creating PR now."

More from this repository

same repository

cold-email

bongrealty/skillcraft

Write B2B cold emails and follow-up sequences that get replies. Use when the user wants to write cold outreach emails, prospecting emails, cold email campaigns, sales development emails, or SDR emails. Also use when the user mentions "cold outreach," "prospecting email," "outbound email," "email to leads," "reach out to prospects," "sales email," "follow-up email sequence," "nobody's replying to my emails," or "how do I write a cold email." Covers subject lines, opening lines, body copy, CTAs, personalization, and multi-touch follow-up sequences. For warm/lifecycle email sequences, see email-sequence. For sales collateral beyond emails, see sales-enablement.

2026-04-082

conversion-copy

bongrealty/skillcraft

Act as a Senior Conversion Strategist to write complete website copy — hero, features, social proof, FAQ, and footer — with persuasion triggers, power words, and character counts. Use when writing or rewriting copy for a landing page, SaaS site, or product launch. Output populates directly into Figma Make layouts.

2026-03-132

data-query

bongrealty/skillcraft

Run analytics queries against any database using plain English — BigQuery (bq CLI), PostgreSQL, MySQL, SQLite, or any DB with a CLI/MCP/API. Use when you need to pull metrics, analyze data, or answer business questions without writing SQL.

2026-03-132

figma-translator

bongrealty/skillcraft

Translate any technical specification into five precise, self-contained Figma Make prompts ready to paste and generate. Use when you have a systems-architect, visual-system-architect, or conversion-copy output and need to convert it into Figma Make–compatible prompts covering hero, features, social proof, CTA, and mobile views.

2026-03-132

fix-bugs

bongrealty/skillcraft

Autonomously fix bugs from any source — Slack threads, failing CI tests, docker logs, or a plain description. Use when you have a bug report or failing test and want Claude to investigate and fix without step-by-step guidance.

2026-03-132

interaction-engineer

bongrealty/skillcraft

Act as a Senior Frontend Systems Engineer to architect interactive modules — multi-step forms, pricing calculators, faceted search, dashboards, and auth flows. Defines state machines, data flow, error handling, and React component structure. Use when designing complex UI logic for Figma Make prototypes or React implementation.

2026-03-132

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.
license	MIT
compatibility	Designed for Claude Code. Requires a git repository.
metadata	{"author":"rajit","version":"1.0"}
allowed-tools	Bash(git:*) Read Grep Glob

Enter adversarial review mode. Challenge the current changes, implementation, or approach. Do not make a PR or proceed until the user passes the review.

Modes

A. Code Review (default)

"Grill me on these changes and don't make a PR until I pass your test."

Read the current diff (git diff main or staged changes)
Identify risks: edge cases, missing error handling, performance issues, security holes, missing tests, unclear naming
Ask the user 3–5 hard, specific questions about the changes
Do not accept vague answers — probe further if needed
Only approve (and proceed with PR) once you're satisfied
Alternatively: "Prove to me this works" → diff behavior between main and feature branch, run tests, check logs

B. Elegant Rewrite

"Knowing everything you know now, scrap this and implement the elegant solution."

After a mediocre or working-but-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

C. Spec-Driven Development

"Write detailed specs before handing off this work."

Ask the user clarifying questions until requirements are unambiguous
Produce a written spec: inputs, outputs, edge cases, constraints, acceptance criteria
Only begin implementation once the spec is approved
The more specific the spec, the better the output

Review Checklist (Mode A)

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

Example

User: grill me on these changes and don't make a PR until I pass your test
→ Claude reads diff, asks 4 hard questions
→ User answers
→ Claude probes weak answers
→ User satisfies all concerns
→ Claude: "You passed. Creating PR now."