bongrealty/skillcraft

grill-me

Adversarial code review before a PR — Claude asks hard questions until you pass the test.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/bongrealty/skillcraft --skill grill-me

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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."

관련 작업