grill-melisted

# Grill Me 사용자의 계획이나 설계를 곧바로 구현하지 말고, 결정 트리가 닫힐 때까지 구체적이고 친절한 질문으로 압박한다. 목적은 큰 문서 시스템을 만드는 것이 아니라, 구현 전에 위험한 가정과 선택지를 빠르게 드러내는 것이다. ## 두 가지 모드 | 모드 | 호출 | 하는 일 | |------|------|---------| | **기본** | `grill me`, `/grill-me`, `설계 압박 질문` | 질문만. 문서를 쓰지 않는다 | | **`--docs`** | `grill me --docs`, `grill with docs`, `문서랑 맞춰 질문`, `도메인 문서 기준으로 점검`, `ADR까지 정리` | 저장소의 glossary·ADR·코드를 질문의 기준으로 삼고, 확정된 용어를 `CONTEXT.md`에 반영. 필요할 때만 ADR 제안 | 모드가 불분명하면 기본 모드로 진행한다. 대화 중 도메인 용어 충돌이 드러나면 `--docs`로 승격할지 물어본다. ## When to Use - 사용자가 "grill me", "계획을 까다롭게 질문해줘", "설계 압박 질문", "stress-test my plan"처럼 계획 검증을 요청할 때 - 구현 전에 요구사항, 설계, 범위, trade-off를 짧게 점검하고 싶을 때 - `/vague`나 `/ouroboros`보다 가벼운 인터뷰가 충분할 때 - (`--docs`) 새 기능 계획이 기존 glossary, bounded context, ADR, 코드 현실과 충돌할 가능성이 있을 때 - (`--docs`) 단순 명확화보다 domain language 정리가 더 중요한 설계 대화일 때 ## Workflow ### 1. Establish the Target 사용자의 원래 계획을 한두 문장으로 재진술하고, 어떤 결정이 아직 열려 있는지 식별한다. 계획이 코드베이스 사실로 확인 가능한 주장에 의존하면 먼저 파일을 탐색한다. **`--docs` 모드에서는 먼저 도메인 소스를 찾는다:** - 루트 `CONTEXT-MAP.md` - 루트 또는 하위 컨텍스트의 `CONTEXT.md` - 루트 또는 하위 컨텍스트의 `docs/adr/` - 관련 코드, 테스트, API, schema `CONTEXT-MAP.md`가 있으면 여러 컨텍스트가 있다고 보고, 사용자 계획이 어느 컨텍스트에 속하는지 먼저 확인한다. 없으면 가장 가까운 `CONTEXT.md`와 `docs/adr/`를 기준으로 삼는다. 둘 다 없으면 그 사실을 알리고 코드를 기준으로 진행한다 — 없는 문서를 만들기 위해 인터뷰를 늘리지 않는다. ### 2. Ask in Small Batches 한 번에 1-3개 질문만 한다. 각 질문에는 추천 답변을 함께 붙여 사용자가 빠르게 수락, 수정, 거절할 수 있게 한다. 질문은 사용자가 맥락을 다시 떠올리지 않아도 답할 수 있을 만큼 상세해야 한다. 질문 문장 안에 다음을 자연스럽게 포함한다. - 지금 닫아야 하는 결정 - 이 결정이 구현 결과를 바꾸는 이유 - 선택하지