Claude Skill

grill-me

사용자가 /grill-me 를 호출하거나 아이디어·기능 요청·스펙을 구현 전에 굽고(grill)·압박 검증하고·심문해 달라고 할 때 사용. superpowers:brainstorming 의 opt-in 대체재 — 작업마다 사용자가 둘 중 하나를 고른다.

LLM Mart · 0 points · 12 views 2 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download leeyudok-agents-scaffold-.claude_skills_grill-me-1b2f034.zip · 2 KB
Part of leeyudok/agents-scaffold — 32 skills

Install

skills CLI npx skills add https://github.com/LeeYudok/agents-scaffold/tree/main/.claude/skills/grill-me
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install leeyudok-agents-scaffold@llmmart
Git git clone https://github.com/LeeYudok/agents-scaffold.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole leeyudok/agents-scaffold collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Grill Me — 적대적 요구사항 심문

obra/superpowers(MIT) 의 brainstorming 스킬에서 영감을 받아 그 opt-in 대체재로 설계한 자체 스킬 — 이후 워크플로(계획 → TDD → 리뷰)는 superpowers 의 프로세스를 따른다.

스펙이 더 이상 바뀌지 않을 때까지 사용자의 아이디어를 심문한 뒤, 단단해진 스펙을 일반 구현 플로에 넘긴다. 이 스킬을 명시적으로 호출하면 현재 작업에 한해 superpowers:brainstorming 을 대체하며, 이후 단계(계획 → TDD → 리뷰)는 그대로다.

이것은 다회전 인터뷰지 설문지가 아니다. 피해야 할 실패 모드: 명확화 질문을 한 뭉치 던지고, 답을 액면 그대로 받아들이고, 바로 설계로 점프하는 것. 매 라운드는 이전 라운드의 답을 파고든다.

절차

  1. 모드 선언. 한 줄로: 코드 작성 전에 아이디어를 심문할 것이며, 산출물은 단단해진 스펙이라고 알린다. 5단계 전까지 구현·설계 제안 금지.

  2. 라운드 루프. 라운드당 최대 3개 질문, 모두 한 주제로 묶어 던지고 답을 기다린다. 매 라운드 가장 날카로운 미해결 주제를 고른다. 대략적 순서:

    • 목적 — 누가 필요로 하나, 없으면 뭐가 깨지나, 왜 지금인가?
    • 숨은 가정 — 당연시하고 있는 것(인증 모델, 데이터 형태, 규모)은?
    • 엣지케이스·실패 모드 — 회수(revocation), 동시성, 부분 실패, 악용.
    • 보안/프라이버시 — PII 노출, 새 공격 표면, 비인증 경로 (P0).
    • YAGNI — v1 에서 손실 없이 잘라낼 수 있는 부분은?
    • 운영 — 롤백, 마이그레이션, 모니터링, 장애 시 누가 호출되나?
  3. 답을 재반박. 모호한 답("나중에 생각하죠", "아마 괜찮을 듯")을 조용히 수용하지 않는다 — 구체적 결과를 들어 한 번 되받아치거나("만료를 생략하면 퇴사자가 대시보드 접근을 유지하는데, 수용 가능한가?"), 스펙의 수용한 리스크 항목에 원문 그대로 기록한다. 모든 유보는 비목표 또는 수용한 리스크로 남는다; 증발하는 것은 없다.

  4. 종료 조건. 한 라운드 전체가 스펙 변경을 만들지 못하거나 사용자가 중단을 말하면 멈춘다. 답이 한 번 왔다는 이유만으로 멈추지 않는다.

  5. 단단해진 스펙 전달 — 정확히 이 형태로:

    ## 단단해진 스펙 — <기능>
    ### 결정 사항        <!-- 각 항목 "질문 → 결정" -->
    ### 비목표 (v1)      <!-- YAGNI 컷, 유보한 범위 -->
    ### 수용한 리스크    <!-- 사용자가 수용을 선택, 원문 그대로 -->
    ### 인수 기준
    

    이후 핸드오프: 프로젝트 워크플로(이슈 → 브랜치 → 계획/TDD)로 진행한다.

사용하지 않을 때

  • 사소한 수정, 오타, 기계적 변경 — 그냥 한다.
  • 사용자가 협업형 아이디어 생성을 원함 → superpowers:brainstorming (별도 플러그인).
  • 요구사항이 모호한 큰 작업을 스펙화한 뒤 실행·평가까지 루프로 돌려야 함 → Ouroboros (별도 MCP 서버). 세션이 끊겨도 상태가 남는 대신 이 셋 중 가장 무겁다.
  • 구현 도중의 질문 — 이 스킬은 작업 시작 전용이다.

이 스킬은 취조만 하고 대화 안에서 끝난다 — 파일도 서버 상태도 남기지 않는다. 그게 부족할 때만 위의 무거운 쪽으로 올라간다. 셋 비교는 README 의 "요구사항 다지기 도구 고르기" 참조.

Files (agents-scaffold)
  • SKILL.md 4 KB
    ---
    name: grill-me
    description: 사용자가 /grill-me 를 호출하거나 아이디어·기능 요청·스펙을 구현 전에 굽고(grill)·압박 검증하고·심문해 달라고 할 때 사용. superpowers:brainstorming 의 opt-in 대체재 — 작업마다 사용자가 둘 중 하나를 고른다.
    user-invocable: true
    ---
    
    # Grill Me — 적대적 요구사항 심문
    
    > [obra/superpowers](https://github.com/obra/superpowers)(MIT) 의 `brainstorming` 스킬에서
    > 영감을 받아 그 opt-in 대체재로 설계한 자체 스킬 — 이후 워크플로(계획 → TDD → 리뷰)는 superpowers 의 프로세스를 따른다.
    
    스펙이 더 이상 바뀌지 않을 때까지 사용자의 아이디어를 심문한 뒤, 단단해진 스펙을
    일반 구현 플로에 넘긴다. 이 스킬을 명시적으로 호출하면 현재 작업에 한해
    `superpowers:brainstorming` 을 대체하며, 이후 단계(계획 → TDD → 리뷰)는 그대로다.
    
    **이것은 다회전 인터뷰지 설문지가 아니다.** 피해야 할 실패 모드: 명확화 질문을
    한 뭉치 던지고, 답을 액면 그대로 받아들이고, 바로 설계로 점프하는 것. 매 라운드는
    이전 라운드의 답을 파고든다.
    
    ## 절차
    
    1. **모드 선언.** 한 줄로: 코드 작성 전에 아이디어를 심문할 것이며, 산출물은 단단해진
       스펙이라고 알린다. 5단계 전까지 구현·설계 제안 금지.
    
    2. **라운드 루프.** 라운드당 **최대 3개 질문**, 모두 한 주제로 묶어 던지고 답을
       기다린다. 매 라운드 가장 날카로운 미해결 주제를 고른다. 대략적 순서:
       - 목적 — 누가 필요로 하나, 없으면 뭐가 깨지나, 왜 지금인가?
       - 숨은 가정 — 당연시하고 있는 것(인증 모델, 데이터 형태, 규모)은?
       - 엣지케이스·실패 모드 — 회수(revocation), 동시성, 부분 실패, 악용.
       - 보안/프라이버시 — PII 노출, 새 공격 표면, 비인증 경로 (P0).
       - YAGNI — v1 에서 손실 없이 잘라낼 수 있는 부분은?
       - 운영 — 롤백, 마이그레이션, 모니터링, 장애 시 누가 호출되나?
    
    3. **답을 재반박.** 모호한 답("나중에 생각하죠", "아마 괜찮을 듯")을 조용히
       수용하지 않는다 — 구체적 결과를 들어 한 번 되받아치거나("만료를 생략하면 퇴사자가
       대시보드 접근을 유지하는데, 수용 가능한가?"), 스펙의 **수용한 리스크** 항목에
       원문 그대로 기록한다. 모든 유보는 **비목표** 또는 **수용한 리스크**로 남는다;
       증발하는 것은 없다.
    
    4. **종료 조건.** 한 라운드 전체가 스펙 변경을 만들지 못하거나 사용자가 중단을
       말하면 멈춘다. 답이 한 번 왔다는 이유만으로 멈추지 않는다.
    
    5. **단단해진 스펙 전달** — 정확히 이 형태로:
    
       ```markdown
       ## 단단해진 스펙 — <기능>
       ### 결정 사항        <!-- 각 항목 "질문 → 결정" -->
       ### 비목표 (v1)      <!-- YAGNI 컷, 유보한 범위 -->
       ### 수용한 리스크    <!-- 사용자가 수용을 선택, 원문 그대로 -->
       ### 인수 기준
       ```
    
       이후 핸드오프: 프로젝트 워크플로(이슈 → 브랜치 → 계획/TDD)로 진행한다.
    
    ## 사용하지 않을 때
    
    - 사소한 수정, 오타, 기계적 변경 — 그냥 한다.
    - 사용자가 협업형 아이디어 *생성*을 원함 → `superpowers:brainstorming` (별도 플러그인).
    - 요구사항이 모호한 큰 작업을 스펙화한 뒤 실행·평가까지 루프로 돌려야 함 → Ouroboros
      (별도 MCP 서버). 세션이 끊겨도 상태가 남는 대신 이 셋 중 가장 무겁다.
    - 구현 도중의 질문 — 이 스킬은 작업 시작 전용이다.
    
    이 스킬은 **취조만** 하고 대화 안에서 끝난다 — 파일도 서버 상태도 남기지 않는다. 그게
    부족할 때만 위의 무거운 쪽으로 올라간다. 셋 비교는 README 의 "요구사항 다지기 도구
    고르기" 참조.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related