@bhoon716/skill-forge 1.0.0

package/skills/ultra-grill-me/examples/should-trigger.md

@@ -0,0 +1,254 @@
+# Should Trigger Examples
+
+이 문서의 예시들은 사용자의 요청이 `ultra-grill-me` 스킬의 목적에 부합하여, 스킬이 자동으로 활성화(trigger)되어야 하는 경우를 정의합니다. 모든 문서는 한국어로 작성되었습니다.
+
+---
+
+## 예시 1. 제품 아이디어 압박 검증 요청 (product-idea)
+
+### 사용자 입력
+```txt
+새로운 사이드 프로젝트로 개발자용 할일 관리 앱 아이디어가 있는데, 만들기 전에 끝까지 빈틈 좀 털어줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. 바로 조언을 하거나 기획안을 작성하지 않고, [product-idea-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/product-idea-grill.md) reference 파일 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 질문 형식에 맞추어, 대상 사용자를 명확히 좁히는 **가장 작고 구체적인 단일 질문**을 생성한다.
+5. 선택지에 `(추천)` 표시를 포함하고, 마지막에는 항상 `다른 옵션 더 추천받기`와 `직접 답변`을 제공한다.
+
+### 기대 출력
+```markdown
+**현재 이해**: 개발자용 할일 관리 앱 아이디어를 검증하고 싶은 상태입니다.
+
+**막힌 결정**: 대상 사용자의 범위가 너무 넓어, 구체적인 킬러 기능과 성공 지표를 정의할 수 없습니다.
+
+**질문**: 이 앱을 사용할 1차 타겟 개발자는 누구인가요?
+
+**왜 중요한지**: 개발자마다 업무 스타일(프리랜서, 대기업 사원, 1인 개발자)이 다르므로, 구체적인 타겟을 좁혀야 이들의 진짜 페인포인트를 해결하는 기능 범위(MVP)를 도출할 수 있습니다.
+
+**선택지**:
+1. (추천) 1인 개발자 또는 인디 해커 — 여러 프로젝트의 컨텍스트 스위칭과 일정 관리에 집중
+2. 5인 이하 소규모 스타트업의 풀스택 개발자 — 협업과 빠른 배포 동기화에 집중
+3. 대기업에 근무하는 플랫폼 엔지니어 — 티켓 관리 시스템(Jira 등)과의 연동에 집중
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 2. 아키텍처 결정(ADR) 반대신문 요청 (architecture-decision)
+
+### 사용자 입력
+```txt
+우리 서비스 데이터베이스를 PostgreSQL에서 MongoDB로 전환하려고 해. 이 아키텍처 결정이 맞는지 반대신문하듯이 질문으로 압박 검증해줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. [architecture-decision-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/architecture-decision-grill.md) reference 파일 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 질문 형식에 맞추어, 전환하려는 대안의 명확한 기술적 근거(기준)를 묻는 **가장 작고 구체적인 단일 질문**을 던진다.
+
+### 기대 출력
+```markdown
+**현재 이해**: 데이터베이스를 PostgreSQL에서 MongoDB로 전환하는 아키텍처 결정을 검증하고 싶은 상태입니다.
+
+**막힌 결정**: RDB에서 NoSQL로 전환하려는 핵심 판단 기준이 정의되지 않아 장기 기술 tradeoff를 비교할 수 없습니다.
+
+**질문**: PostgreSQL에서 MongoDB로 전환하려는 가장 결정적인 기술적 요구사항은 무엇인가요?
+
+**왜 중요한지**: 스키마의 유연성, 동시성 처리 성능, 혹은 분산 확장성 등 전환하려는 주된 목적이 명확해야 대안(MongoDB)이 정말 그 문제를 해결할 수 있는지, 그리고 그로 인해 포기하는 것(ACID 트랜잭션 등)의 대가가 감당 가능한지 검토할 수 있습니다.
+
+**선택지**:
+1. (추천) 스키마 없는 데이터 모델링의 필요성 — 데이터 구조가 자주 바뀌어 마이그레이션 비용이 너무 큼
+2. 대용량 쓰기 트래픽의 수평 확장(Sharding) 필요성 — RDB의 단일 노드 한계를 넘음
+3. 계층형/도큐먼트 구조의 직관적 매핑 — 개발 생산성 극대화
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 3. 이직 결정(개인 의사결정) 검증 요청 (personal-decision)
+
+### 사용자 입력
+```txt
+두 회사에서 합격 오퍼를 받았어. 하나는 연봉이 높은 스타트업이고, 하나는 네임밸류가 있는 대기업이야. 후회 없는 선택을 하고 싶은데, 질문으로 내 생각을 털어줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. [personal-decision-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/personal-decision-grill.md) reference 파일 하나만 로드한다.
+3. 단정적이고 일방적인 진로나 직무 조언을 피하며 안전 가이드를 준수한다.
+4. 의사결정의 가장 큰 기회비용이나 제약 요소를 파악하기 위한 질문을 하나만 생성하여 제공한다.
+
+### 기대 출력
+```markdown
+**현재 이해**: 연봉이 높은 스타트업과 네임밸류가 있는 대기업 오퍼 중 하나를 선택해야 하는 고민입니다.
+
+**막힌 결정**: 이번 커리어 결정에서 가장 우선시하는 가치 기준(제약/목표)이 정리되지 않아 양자택일의 tradeoff를 저울질할 수 없습니다.
+
+**질문**: 3년 뒤 본인의 커리어에서 가장 중요하게 남기고 싶은 자산은 무엇인가요?
+
+**왜 중요한지**: 단기 소득(연봉) 극대화와 장기적 안정성/네임밸류는 서로 다른 기회비용을 갖습니다. 3년 뒤의 지향점이 명확해야 각 선택지가 주는 최악의 시나리오를 감당할 수 있는지 판단할 수 있습니다.
+
+**선택지**:
+1. (추천) 급격한 직무 확장과 빠른 성과 창출 — 주도적으로 비즈니스를 키우는 경험 선호
+2. 안정적인 환경에서의 체계적인 프로세스 학습 — 대규모 시스템 운영 경험 선호
+3. 현금 흐름 및 자산 축적 극대화 — 현재 가처분 소득의 중요성 선호
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 4. 구현 일정 계획 검증 요청 (implementation-plan)
+
+### 사용자 입력
+```txt
+이번 신규 간편결정 기능의 출시 3주 마일스톤 계획을 세웠어. 리스크나 의존성 오류가 없는지 질문으로 털어봐줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. [implementation-plan-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/implementation-plan-grill.md) reference 파일 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 구현 일정의 현실성과 가장 불확실한 부분을 확인하기 위한 질문을 하나만 생성하여 제공한다.
+
+### 기대 출력
+```markdown
+**현재 이해**: 신규 간편결정 기능의 3주 출시 마일스톤 계획을 검증하려는 상태입니다.
+
+**막힌 결정**: 완료(Done)의 공통 기준과 가장 지연될 리스크가 큰 작업 단위가 식별되지 않아 일어날 일정 밀림을 예측할 수 없습니다.
+
+**질문**: 이 3주 마일스톤 중 외부 의존성(예: 결제 PG사 심사, 앱스토어 검수 등)을 타야 하거나 통제 불가능한 영역의 작업은 무엇인가요?
+
+**왜 중요한지**: 외부 의존성이나 심사 기간이 포함된 경우, 내부 개발 속도와 무관하게 3주 일정이 늘어질 수 있습니다. 이를 먼저 확인해야 리스크 대비용 버퍼 일정을 계획에 반영할 수 있습니다.
+
+**선택지**:
+1. (추천) 결제 PG사 API 계약 및 연동 테스트 — 외부 심사 기간 예측 불가
+2. 구글 플레이 / iOS 앱스토어 심사 등록 — 마켓 가이드라인 위반 리스크 상존
+3. 사내 보안 및 컴플라이언스 승인 — 내부 심사 프로세스 지연 가능성
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 5. 글쓰기/발표 방향 검증 요청 (writing-direction)
+
+### 사용자 입력
+```txt
+다음 달 사내 기술 세미나에서 '마이크로서비스 아키텍처 전환 후기'를 발표하려고 해. 장표 흐름이나 내러티브에 빈틈이 없는지 압박 질문으로 털어줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. [writing-direction-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/writing-direction-grill.md) reference 파일 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 발표의 1차 청중(독자)이 누구인지를 명확히 좁히는 질문을 우선적으로 수행한다.
+
+### 기대 출력
+```markdown
+**현재 이해**: 사내 기술 세미나 발표인 '마이크로서비스 아키텍처 전환 후기'의 내러티브를 검증하려는 상태입니다.
+
+**막힌 결정**: 1차 청중이 누구인지 정해지지 않아, 기술적 깊이와 공유할 아키텍처 디테일의 한계선을 그을 수 없습니다.
+
+**질문**: 이 발표의 주된 청중(대상 독자)은 어떤 직군인가요?
+
+**왜 중요한지**: 청중이 경영진인지, 주니어 개발자인지, 혹은 타 부서 기획자/PM인지에 따라 'MSA 전환 이유'와 '전환 성과'의 내러티브 강조점(비용 절감 vs 코드 복잡도 해소)이 완전히 달라집니다.
+
+**선택지**:
+1. (추천) 사내 소프트웨어 엔지니어 전체 — 구체적인 코드 패턴, 장애 극복 스토리, 기술적 tradeoff에 관심
+2. 비즈니스 부서 PM 및 기획자 — 출시 속도 개선량, 부서 간 협업 프로세스 변화에 관심
+3. 개발 본부 경영진 — 인프라 비용 절감 효과, 팀 리소스 생산성 향상 비율에 관심
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 6. Agent Skill 설계 검증 요청 (skill-design)
+
+### 사용자 입력
+```txt
+사용자의 Git Commit 메시지를 규칙에 따라 자동으로 정제해주는 스킬을 하나 만드려고 해. SKILL.md 쓰기 전에 모호한 부분들 질문으로 털어봐줘.
+```
+
+### 기대 동작
+1. `ultra-grill-me` 스킬이 즉시 활성화된다.
+2. [skill-design-grill.md](file:///Users/bhoon/Project/skill-forge/skills/ultra-grill-me/references/skill-design-grill.md) reference 파일 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 스킬 설계의 핵심인 trigger 조건이나 스펙의 경계를 묻는 질문을 하나 던진다.
+
+### 기대 출력
+```markdown
+**현재 이해**: Git Commit 메시지 자동 정제 스킬의 설계를 검증하려는 상태입니다.
+
+**막힌 결정**: 스킬의 정확한 작동 범위와 trigger 규칙이 모호하여 불필요하게 스킬이 과발동되거나 오동작할 위험이 있습니다.
+
+**질문**: 이 커밋 메시지 정제 스킬이 발동되면 안 되는 예외(Non-trigger) 상황은 언제인가요?
+
+**왜 중요한지**: 일반 소스 코드 질문이나 단순 기술 설명, 혹은 이미 사용자가 완벽하게 수작업으로 작성한 커밋 메시지 제출 상황 등에서도 스킬이 오발동되면 리소스 낭비 및 사용자 경험 저하를 유발합니다. 경계를 명확히 해야 합니다.
+
+**선택지**:
+1. (추천) 커밋 메시지 정제와 무관한 일반 소스 코드 Q&A 또는 리팩토링 요청 시
+2. 사용자가 커밋 옵션(예: `--amend`, `--no-verify` 등)의 개념적 질문을 던졌을 때
+3. Git 관련 설정 오류를 물어보는 단순 트러블슈팅 요청 시
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+
+---
+
+## 예시 7. 명시적 스킬 호출 (슬래시 커맨드 및 스킬명 직접 명시)
+
+### 사용자 입력
+```txt
+/ultra-grill-me 내 React 공부 로드맵 검증 시작해줘.
+```
+또는
+```txt
+ultra-grill-me 스킬 적용해서 내 포트폴리오 사이트 기술 스택 고민 검증해줘.
+```
+
+### 기대 동작
+1. 에이전트 라우팅 시스템이 사용자가 입력한 명령어(`/ultra-grill-me`) 또는 스킬 이름(`ultra-grill-me`)을 직접 매칭하여 **최우선 순위로 스킬을 활성화**한다.
+2. 사용자의 구체적 요구 도메인(React 공부 → `learning-plan`, 기술 스택 고민 → `technical-design` 또는 `architecture-decision`)에 맞춰 reference 하나만 로드한다.
+3. 세션 로그 파일(`logs/`)을 생성한다.
+4. 질문 형식에 맞추어 **가장 작고 구체적인 단일 질문**을 생성하여 인터뷰를 시작한다.
+
+### 기대 출력 (React 로드맵 예시)
+```markdown
+**현재 이해**: React 공부 로드맵 계획을 명시적으로 검증하기 위해 ultra-grill-me 스킬을 활성화했습니다.
+
+**막힌 결정**: 현재 학습 전반의 최종 목표(React로 구체적으로 무엇을 만들고 싶은지)가 알려지지 않아, 로드맵 상의 불필요한 기술 스택을 필터링할 수 없습니다.
+
+**질문**: 이 React 학습을 끝마친 뒤, 최종적으로 구현해내고 싶은 프로젝트 결과물은 무엇인가요?
+
+**왜 중요한지**: 단순 이론 학습과 달리, 실전 구현 목표(예: 개인 블로그, 대형 커뮤니티, B2B 대시보드)에 따라 학습해야 하는 관련 기술(Redux, Next.js, React Query 등)의 범위가 크게 달라집니다.
+
+**선택지**:
+1. (추천) 서버 사이드 렌더링(SSR)과 SEO가 필수적인 복합 반응형 쇼핑몰/블로그 완성
+2. 실시간 기능(웹소켓)이 포함된 인터랙티브 협업 도구 및 대시보드 완성
+3. 라이브러리 수준의 복잡한 커스텀 훅과 상태 관리 패턴의 심층적 구현체 완성
+4. 다른 옵션 더 추천받기
+5. 직접 답변
+
+번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
+```
+

package/skills/ultra-grill-me/logs/template.md

@@ -0,0 +1,41 @@
+# [주제] Grill 세션
+
+- 날짜: YYYY-MM-DD
+- 케이스: [사용된 reference 이름]
+- 상태: 진행 중 | 완료
+
+## 요약
+
+[세션의 한 줄 요약. 세션 종료 시 작성.]
+
+## 질문 로그
+
+### Q1. [질문 내용]
+
+- 막힌 결정: [어떤 불확실성이 막고 있었는지]
+- 답변: [사용자의 답변]
+- 결과: 확정 | 임시 가정 | 거부
+
+### Q2. [질문 내용]
+
+- 막힌 결정: [어떤 불확실성이 막고 있었는지]
+- 답변: [사용자의 답변]
+- 결과: 확정 | 임시 가정 | 거부
+
+## 확정된 결정
+
+- [결정 1]
+- [결정 2]
+
+## 임시 가정
+
+- [가정 1]
+- [가정 2]
+
+## 남은 known unknowns
+
+- [미해결 항목 1]
+
+## 최종 정리
+
+[종료 조건 충족 시 최종 정리 내용을 여기에 기록]

package/skills/ultra-grill-me/references/architecture-decision-grill.ko.md

@@ -0,0 +1,87 @@
+# 아키텍처 결정 검증
+
+## 이 reference를 사용할 때
+
+- 큰 아키텍처 선택의 장기적 tradeoff를 검증해달라는 요청
+- 모놀리스 vs 마이크로서비스 같은 구조적 결정을 grill 해달라는 요청
+- 데이터베이스, 클라우드, 프레임워크 같은 플랫폼 선택을 검증해달라는 요청
+- 장기 기술 방향을 반대신문해달라는 요청
+- ADR(Architecture Decision Record)을 만들기 전에 질문으로 검증해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 구체적인 API나 데이터 모델 설계 → `technical-design-grill.md` 사용
+- 구현 순서나 작업 계획 → `implementation-plan-grill.md` 사용
+- 아키텍처 개념을 설명해달라는 요청
+- 아키텍처를 바로 설계해달라는 요청
+
+## 질문 우선순위
+
+1. 내려야 하는 결정 — 정확히 어떤 결정을 내려야 하는가?
+2. 대안 후보 — 현실적으로 고려 중인 대안은 무엇인가?
+3. 결정 기준 — 무엇을 기준으로 판단하는가?
+4. 장기 확장성 — 3~5년 뒤에도 이 결정이 유효한가?
+5. 운영 복잡도 — 이 선택이 운영 부담을 얼마나 늘리는가?
+6. 팀 역량 — 현재 팀이 이 기술을 운영할 수 있는가?
+7. 비용 — 초기 비용과 장기 비용이 어떻게 되는가?
+8. 되돌릴 수 있는지 — 이 결정을 나중에 바꿀 수 있는가? 바꾸는 비용은?
+9. 실패 시 피해 — 이 결정이 틀렸을 때 최악의 상황은?
+10. ADR로 남길 결론 — 이 결정의 맥락, 이유, tradeoff를 기록할 수 있는가?
+
+## 강한 질문 패턴
+
+- "이 결정을 2년 뒤에 바꿔야 한다면 비용이 얼마나 드나요?"
+- "지금 팀에서 이 기술을 production에서 운영해본 사람이 있나요?"
+- "A 대신 B를 골랐을 때 포기하는 것 중 가장 아까운 건 뭔가요?"
+- "이 결정이 완전히 틀렸다고 밝혀지면 어떤 일이 벌어지나요?"
+- "결정 기준 중 가장 중요한 하나만 고르면 뭔가요?"
+
+## 약한 질문 패턴
+
+- "어떤 게 더 나은가요?"
+- "최신 기술인가요?"
+- "대기업도 쓰나요?"
+
+## 추천 옵션 구성 규칙
+
+- **결정 기준이 불분명할 때**: `(추천) 운영 복잡도 최소화, 현재 팀의 기술 역량 일치 여부, 아키텍처 가역성(되돌릴 수 있는지)` 기준을 추천하고, 성능 극대화/최신 유행 기준 대안들로 선택지 구성
+- **고려 대안이 하나뿐일 때**: `(추천) 현재 아키텍처 상태 유지(현상 유지)` 대안을 두 번째 대안으로 추가하여 비교 선택지 구성
+- **되돌릴 수 있는지 여부가 모호할 때**: `(추천) 되돌릴 수 없는 영구 결정(Hard Decision)으로 간주하고 안전장치 마련` 옵션을 추천하고, 가볍게 보고 우회하려는 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "둘 다 괜찮아 보여" → "그럼 A와 B 중 운영 복잡도가 낮은 쪽을 기본값으로 둘까요?"로 판단 기준 제시
+- "나중에 바꿀 수 있으니까" → "바꾸는 데 드는 추정 비용(시간, 인력, 데이터 마이그레이션)을 한번 짚어볼까요?"로 구체화
+- "팀이 배우면 되지" → "학습 기간을 3개월로 잡았을 때 그동안 delivery에 영향이 있나요?"로 현실성 확인
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 결정 대상이 명확하다
+- 현실적인 대안이 최소 2개 비교되었다
+- 결정 기준이 우선순위와 함께 정리되었다
+- 되돌릴 수 있는지 여부가 확인되었다
+- tradeoff가 명시되었다
+- ADR 초안에 들어갈 핵심 문장이 나왔다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 결정 대상
+- 비교한 대안
+- 선택 기준과 우선순위
+- 추천 방향
+- 핵심 tradeoff
+- 되돌릴 수 있는 조건
+- ADR 초안에 들어갈 핵심 문장
+
+## 실패 모드
+
+- 대안 없이 하나의 선택지만 논의하는 경우
+- 되돌릴 수 있는지를 확인하지 않는 경우
+- 팀 역량을 무시하고 기술적 우수성만 논의하는 경우
+- 운영 복잡도를 고려하지 않는 경우
+- 결정 기준 없이 감으로 결론을 내리는 경우
+- 실패 시 피해를 검토하지 않는 경우

package/skills/ultra-grill-me/references/architecture-decision-grill.md

@@ -0,0 +1,68 @@
+# Architecture Decision Verification
+
+## When to use this reference
+
+- Verifying high-level technology choices (e.g., framework, database engine, cloud provider)
+- Evaluating system topology (e.g., monolith vs. microservices, serverless vs. container)
+- Comparing technical tradeoffs of multiple system-wide options
+- Reviewing Architectural Decision Records (ADRs) before committing
+
+## When not to use this reference
+
+- Small developer-level design critiques (e.g., code structure, utility classes) → Use `technical-design-grill.md`
+- Verifying business viability or market segments → Use `business-strategy-grill.md`
+- Building boilerplate server templates
+
+## Question Priority
+
+1. **Core Technical Goals** — What is the primary problem this architecture solves?
+2. **Evaluation Criteria** — What is the most critical constraint? (e.g., speed, maintainability, team skill)
+3. **Alternative Options** — What alternative architectures were considered?
+4. **Tradeoffs (Pros/Cons)** — What are we sacrificing to achieve this architecture?
+5. **Reversibility** — How expensive is it to undo or change this decision in 6 months?
+6. **Operational Overhead** — How complex is this to deploy, monitor, and debug?
+7. **Cost / Resource Implications** — How does this impact infra billing and developer velocity?
+8. **Failure & Migration Path** — How do we migrate from the old system without downtime?
+
+## Strong Question Patterns
+
+- "Why is a monolith no longer sufficient? What specific scaling bottleneck forces us to go to microservices?"
+- "What alternative database engine did you consider? Why was it rejected?"
+- "This architecture introduces significant network overhead. How do you plan to handle distributed tracing and network latency?"
+- "Is this decision reversible? If we need to migrate off this database next year, how much code must we rewrite?"
+
+## Weak Question Patterns
+
+- "Is this the best framework?"
+- "Is this architecture standard?"
+- "Is it easy to use?"
+
+## Recommended Option Rules
+
+- **Criteria Ambiguity**: Recommend `(Recommended) Minimizing operational overhead and matching current team skillsets` criteria and include bleeding-edge hype-based alternatives to build the option set.
+- **Single Option Ambiguity**: Recommend `(Recommended) Maintain current architecture (status quo) as baseline` option to build a comparative option set.
+- **Reversibility Ambiguity**: Recommend `(Recommended) Assume this is an irreversible choice (Type 1 Decision) and establish mitigation fallbacks` and include lightweight, temporary-change alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "Both options are good" → Propose differentiator: "Between A and B, which one has the lower operational complexity? Let's use that as our tie-breaker criteria."
+- "We'll build it to scale infinitely" → Force limits: "Shall we set a concrete horizon constraint, such as 'supporting 10x current scale for 12 months', to avoid over-engineering?"
+- "It is easily reversible" → Force reality check: "If we had to revert, would it require database schema migration? Let's mark this as a Type 1 (high-risk, irreversible) decision for safety."
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- Clear architectural goals are defined.
+- Tradeoffs (what we are actively giving up) are explicitly listed.
+- At least one alternative option (including status quo) has been compared.
+- The cost/maintenance overhead is quantified.
+- The migration path is outline.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Chosen Architectural Option
+- Active Tradeoffs (Pros vs. Cons)
+- Rejected Alternatives and Why
+- Reversibility Assessment (Type 1 vs. Type 2)
+- Operational Risk Mitigations

package/skills/ultra-grill-me/references/business-strategy-grill.ko.md

@@ -0,0 +1,88 @@
+# 사업 전략 검증
+
+## 이 reference를 사용할 때
+
+- 사업 전략의 빈틈을 찾아달라는 요청
+- GTM 전략을 질문으로 검증해달라는 요청
+- 가격/패키징 전략이 적절한지 grill 해달라는 요청
+- ICP(Ideal Customer Profile)가 명확한지 확인해달라는 요청
+- 수익화 전략을 pressure-test 해달라는 요청
+- 시장 선택이나 유통 채널을 검증해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 제품 아이디어 자체를 검증하는 경우 → `product-idea-grill.md` 사용
+- 기술 설계를 검증하는 경우 → `technical-design-grill.md` 사용
+- 사업 전략 개념을 설명해달라는 요청
+- 사업 계획서를 바로 작성해달라는 요청
+
+## 질문 우선순위
+
+1. ICP — 이상적인 고객은 구체적으로 누구인가?
+2. 구매자와 사용자 — 돈을 내는 사람과 쓰는 사람이 같은가?
+3. 예산 출처 — 구매자의 예산은 어디서 나오는가?
+4. 경쟁 대안 — 고객이 지금 이 문제를 어떻게 해결하고 있는가?
+5. 시장 세그먼트 — 어떤 시장 세그먼트를 먼저 공략하는가?
+6. 유통 채널 — 고객에게 어떻게 도달하는가?
+7. 가격 / 패키징 — 가격 구조와 패키징이 ICP에 맞는가?
+8. 세일즈 사이클 — 첫 구매까지 얼마나 걸리는가?
+9. retention driver — 고객이 계속 쓰는 이유는 뭔가?
+10. 핵심 검증 지표 — 이 전략이 작동하는지 어떤 숫자로 확인하는가?
+
+## 강한 질문 패턴
+
+- "ICP를 한 문장으로 말하면 누구인가요? 직군, 규모, 상황까지 포함해서요."
+- "돈을 내는 사람이 팀 리더인가요, 경영진인가요, 개인인가요? 각각 예산 승인 과정이 다를 텐데요."
+- "지금 경쟁 대안이 '충분히 좋은' 상태라면 고객이 전환할 이유가 뭔가요?"
+- "첫 유료 고객 10명을 어떤 채널로 확보할 건가요?"
+- "고객이 3개월 뒤에도 계속 쓸 이유가 뭔가요?"
+
+## 약한 질문 패턴
+
+- "시장이 큰가요?"
+- "가격이 적당한가요?"
+- "마케팅은 어떻게 할 건가요?"
+
+## 추천 옵션 구성 규칙
+
+- **ICP(타겟 고객)가 불분명할 때**: `(추천) 이 문제로 인해 가장 큰 금전적/시간적 손실을 겪고 있으며 즉시 결제할 수 있는 구체적인 한 그룹` 옵션을 추천하고, 광범위한 대안들로 선택지 구성
+- **가격 정책이 미정일 때**: `(추천) 직접적인 경쟁 대안(기존 대안)의 비용 대비 80~120% 범위 내 가격 책정` 옵션을 추천하고, 완전 무료/과도한 고가 책정 대안들로 선택지 구성
+- **유통 채널(GTM)이 불분명할 때**: `(추천) 타겟 고객(ICP)들이 이미 밀집해 활동하고 있는 기존 커뮤니티나 B2B 플랫폼 채널 우선 진입` 옵션을 추천하고, 매스 마케팅/전단 광고 등 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "모든 기업이 고객이 될 수 있어" → "가장 먼저 돈을 낼 기업을 산업, 규모, 직군으로 좁히면 어떤 그룹인가요?"로 좁히기
+- "가격은 나중에 정할게" → "경쟁 대안 가격을 기준으로 월 $X를 임시 기본값으로 둘까요?"로 기본값 제안
+- "입소문으로 퍼질 거야" → "입소문의 시작점이 되는 첫 10명의 사용자를 어디서 확보할 건가요?"로 구체화
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- ICP가 구체적으로 정의되었다
+- 구매자와 사용자가 구분되었다
+- 경쟁 대안이 파악되었다
+- 유통 채널이 최소 하나 정해졌다
+- 가격/패키징 방향이 잡혔다
+- 핵심 검증 지표가 최소 하나 있다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 명확해진 전략 가설
+- ICP
+- 구매자 / 사용자 구분
+- 가장 큰 go-to-market 리스크
+- 가격 / 유통 관련 가정
+- retention driver
+- 검증해야 할 지표
+
+## 실패 모드
+
+- ICP를 "모든 기업"으로 두고 넘어가는 경우
+- 구매자와 사용자를 구분하지 않는 경우
+- 경쟁 대안을 무시하는 경우
+- 유통 채널 없이 "입소문"에만 의존하는 경우
+- 가격을 정하지 않고 전략을 논의하는 경우
+- retention을 고려하지 않는 경우

package/skills/ultra-grill-me/references/business-strategy-grill.md

@@ -0,0 +1,70 @@
+# Business Strategy Verification
+
+## When to use this reference
+
+- Stress-testing monetization models or pricing packaging
+- Validating GTM (Go-To-Market) strategies
+- Verifying target customer segments or ICP (Ideal Customer Profile)
+- Critiquing distribution channels or sales cycle assumptions
+
+## When not to use this reference
+
+- Reviewing early-stage product features or MVP scope → Use `product-idea-grill.md`
+- Highlighting system architecture or code designs → Use `technical-design-grill.md`
+- Generating marketing pitch decks or corporate landing pages
+
+## Question Priority
+
+1. **ICP (Ideal Customer Profile)** — Who is the single most valuable customer group?
+2. **Buyer vs. User** — Are the person paying and the person using the same?
+3. **Budget Source** — Where does the buyer's budget come from?
+4. **Competitors & Alternatives** — How are they solving this problem today?
+5. **Market Segment** — Which market segment do we attack first?
+6. **Distribution Channel (GTM)** — How do we reach this customer profile?
+7. **Pricing / Packaging** — Does pricing structure fit the ICP's budget rules?
+8. **Sales Cycle** — How long does it take from first contact to payment?
+9. **Retention Driver** — Why does the customer stay and pay next month?
+10. **Key Metric (KPI)** — What single metric proves this business model works?
+
+## Strong Question Patterns
+
+- "Who is the ideal customer who will pay for this immediately? Define by industry, size, and role."
+- "Are you selling to developers but charging the CTO? How does the developer justify this cost to the CTO?"
+- "What is the alternative they use today? Why would they switch if their current method is 'good enough'?"
+- "How will you acquire your first 10 paying customers without expensive ads?"
+
+## Weak Question Patterns
+
+- "Is the market big?"
+- "Is the pricing fair?"
+- "How will you market this?"
+
+## Recommended Option Rules
+
+- **ICP Ambiguity**: Recommend `(Recommended) A niche target user group experiencing immediate quantifiable loss of time or money` and include broad general demographics to build the option set.
+- **Monetization Ambiguity**: Recommend `(Recommended) Price based on direct competitor pricing (80~120% range) matching existing budgets` and include free/overpriced models to build the option set.
+- **GTM Ambiguity**: Recommend `(Recommended) Prioritize channels where target ICPs already gather (existing platforms/communities)` and include mass-marketing alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "Everyone can use our service" → Narrow down: "If you could only pitch to 100 companies this week, which specific industry/size would you target?"
+- "We'll set the price later" → Force default: "Let's establish a temporary price of $X per month based on competitor Y to test assumptions. Deal?"
+- "We'll grow by word of mouth" → Force initial step: "Where will the first 10 active customers who start the word-of-mouth loop come from?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- Target customer profile (ICP) is explicitly defined.
+- The distinction between buyer and user is mapped.
+- Direct and indirect competitor alternatives are analyzed.
+- At least one customer acquisition channel is verified.
+- Initial pricing model is proposed.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Refined ICP Profile
+- Buyer vs. User Breakdown
+- Primary GTM Acquisition Channel
+- Initial Pricing & Packaging Model
+- Key Business Monetization Risks