grill-me

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 의 "요구사항 다지기 도구 고르기" 참조.