How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/bongrealty/skillcraft --skill grill-meBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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 mainor 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."

