@bhoon716/skill-forge 1.0.0

package/skills/ultra-grill-me/references/implementation-plan-grill.ko.md

@@ -0,0 +1,87 @@
+# 구현 계획 검증
+
+## 이 reference를 사용할 때
+
+- 이미 방향은 정해졌고, 실행 계획이 현실적인지 검증해달라는 요청
+- 구현 순서가 맞는지 질문으로 확인해달라는 요청
+- 출시 전 계획의 빈틈을 찾아달라는 요청
+- 작업 분해가 적절한지 grill 해달라는 요청
+- 딜리버리 리스크를 검토해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 아직 무엇을 만들지 정해지지 않은 경우 → `product-idea-grill.md` 사용
+- 기술 설계 자체를 검증하는 경우 → `technical-design-grill.md` 사용
+- 아키텍처 방향을 정하는 경우 → `architecture-decision-grill.md` 사용
+- 계획을 바로 작성해달라는 요청
+
+## 질문 우선순위
+
+1. 완료 기준 — "이 작업이 끝났다"를 어떻게 판단하는가?
+2. 작업 분해 — 각 작업이 1~3일 안에 끝나는 크기인가?
+3. 의존성 — 어떤 작업이 다른 작업을 막고 있는가?
+4. 실행 순서 — 의존성과 리스크를 고려한 최적 순서는?
+5. 위험한 작업 — 가장 불확실하거나 어려운 작업은 뭔가?
+6. 검증 지점 — 중간에 "제대로 가고 있는지" 확인할 수 있는 시점은?
+7. 테스트 / QA — 각 단계를 어떻게 검증하는가?
+8. 롤백 계획 — 문제가 생기면 어떻게 되돌리는가?
+9. 일정 리스크 — 예상보다 오래 걸릴 가능성이 높은 작업은?
+10. 첫 번째 실행 단위 — 지금 당장 시작할 수 있는 가장 작은 작업은?
+
+## 강한 질문 패턴
+
+- "이 10개 작업 중 가장 불확실한 건 어떤 건가요? 그걸 먼저 하면 어떨까요?"
+- "'로그인 구현' 이 한 작업이 3일 안에 끝나나요? 더 쪼개야 하지 않나요?"
+- "3번 작업이 2주 늦어지면 전체 일정에 어떤 영향이 있나요?"
+- "중간에 '이 방향이 맞다'고 확인할 수 있는 첫 번째 지점은 언제인가요?"
+- "배포 후 문제가 생기면 5분 안에 롤백할 수 있나요?"
+
+## 약한 질문 패턴
+
+- "이 계획 괜찮나요?"
+- "일정이 넉넉한가요?"
+- "뭔가 빠진 거 없나요?"
+
+## 추천 옵션 구성 규칙
+
+- **완료 기준(Definition of Done)이 없을 때**: `(추천) 기능 정상 동작 + 테스트 커버리지 만족 + 머지 전 코드 리뷰 완료` 옵션을 추천하고, 동작만 확인하는 느슨한 대안들로 선택지 구성
+- **중간 검증 지점(Milestone)이 없을 때**: `(추천) 전체 일정 30% 시점에서 핵심 비즈니스 경로(Happy Path) 엔드투엔드 동작 확인` 옵션을 추천하고, 최종일 일괄 검증 대안들로 선택지 구성
+- **롤백 계획이 없을 때**: `(추천) 배포 실패 시 이전 빌드 버전으로 5분 내 롤백 가능한 파이프라인 가용` 옵션을 추천하고, 수동 핫픽스 패치 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "일정은 대충 맞을 거야" → "가장 불확실한 작업 하나만 골라서 최악의 경우 며칠이 걸릴지 추정해볼까요?"로 구체화
+- "문제 생기면 그때 보지" → "롤백 계획을 '이전 버전 배포'로 임시로 둘까요?"로 기본값 제안
+- "순서는 상관없어" → "그럼 가장 불확실한 작업부터 하는 순서를 기본값으로 둘까요?"로 리스크 기반 순서 제안
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 완료 기준이 정의되었다
+- 작업이 실행 가능한 크기로 분해되었다
+- 의존성이 파악되었다
+- 가장 위험한 작업이 식별되었다
+- 검증 지점이 최소 하나 있다
+- 첫 번째 실행 단위가 정해졌다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 정리된 실행 계획
+- 우선순위
+- 의존성
+- 리스크 작업
+- 검증 지점
+- 롤백 계획
+- 첫 번째 액션
+
+## 실패 모드
+
+- 작업을 너무 크게 잡아서 실행 불가능한 경우
+- 의존성을 무시하고 순서를 정하는 경우
+- 가장 위험한 작업을 마지막에 두는 경우
+- 검증 지점 없이 끝까지 달리는 경우
+- 롤백 계획이 없는 경우
+- 일정 리스크를 무시하는 경우

package/skills/ultra-grill-me/references/implementation-plan-grill.md

@@ -0,0 +1,70 @@
+# Implementation Plan Verification
+
+## When to use this reference
+
+- Reviewing step-by-step project execution plans or roadmap milestones
+- Checking development sequence, dependency paths, and scheduling risks
+- Verifying deployment, rollout, migration, or fallback strategies
+- Stress-testing delivery timelines before launching sprint schedules
+
+## When not to use this reference
+
+- Reviewing code designs or API specifications → Use `technical-design-grill.md`
+- Critique of product market fit or user persona → Use `product-idea-grill.md`
+- Directly generating project timeline charts or Gantt graphics
+
+## Question Priority
+
+1. **Definition of Done (DoD)** — What does "completed" mean for each task?
+2. **Task Decomposition** — Are tasks broken down into chunks smaller than 3 developer-days?
+3. **Dependency Path** — Which tasks must be completed before others can begin?
+4. **Critical Path & Bottlenecks** — Which sequence of tasks determines the final release date?
+5. **External Dependencies** — Are there external APIs, reviews, or approvals outside our control?
+6. **Milestones & Checkpoints** — Where and when do we verify the path is correct?
+7. **Rollout & Migration Strategy** — How do we deploy this change to production safely?
+8. **Rollback & Fallback Plan** — What is the plan if the deployment fails?
+9. **Timeline Buffers** — How much schedule risk is allocated to high-uncertainty tasks?
+10. **Smallest Next Action** — What is the single smallest task that can start today?
+
+## Strong Question Patterns
+
+- "How do we define 'Done' for this phase? Does it include test automation and staging deployments?"
+- "If Task B is delayed by 5 days, how does that impact the target release date?"
+- "What task in this timeline has the highest uncertainty? Should we build a prototype first to reduce this risk?"
+- "If the production deployment fails, can we revert to the previous version in less than 5 minutes?"
+
+## Weak Question Patterns
+
+- "Is this timeline realistic?"
+- "Will everyone work hard to meet the deadline?"
+- "Do you have enough developers?"
+
+## Recommended Option Rules
+
+- **DoD Ambiguity**: Recommend `(Recommended) Functionally working + Test coverage met + Code reviewed before merge` and include looser "developer-done" alternatives to build the option set.
+- **Checkpoint Ambiguity**: Recommend `(Recommended) Validate core happy path E2E at 30% of total timeline` and include launch-day-only validation alternatives to build the option set.
+- **Rollback Ambiguity**: Recommend `(Recommended) 5-minute automated rollback capability using previous build pipeline` and include hotfix patch alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "The timeline should be fine" → Push for reality: "What is the single most uncertain task in this list? If it takes twice as long, how does that affect other tasks?"
+- "We'll deal with deployment failures when they happen" → Force fallback: "Shall we set a default rollback policy, such as 'Revert to previous build version if errors exceed 1% in 5 minutes'?"
+- "Tasks are self-contained" → Map order: "Does the frontend task depend on database schema deployment? Let's establish that database migration must happen first."
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- Clear Definition of Done (DoD) is established.
+- Tasks are decomposed into small units (<3 days).
+- Core dependencies and the critical path are mapped.
+- Staging verification milestones are defined.
+- Rollback protocols are defined.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Clear Definition of Done (DoD)
+- Sequence of Tasks (Critical Path)
+- Key Project Checkpoints (Milestones)
+- External Dependencies List
+- Deployment & Rollback Strategy

package/skills/ultra-grill-me/references/learning-plan-grill.ko.md

@@ -0,0 +1,87 @@
+# 학습 계획 검증
+
+## 이 reference를 사용할 때
+
+- 학습 계획이 현실적인지 grill 해달라는 요청
+- 공부 로드맵을 질문으로 검증해달라는 요청
+- 스킬 습득 계획의 빈틈을 찾아달라는 요청
+- 학습 프로젝트가 적절한지 확인해달라는 요청
+- 학습 목표가 측정 가능한지 확인해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 학습 자료를 추천해달라는 요청
+- 개념을 설명해달라는 요청
+- 공부 계획을 바로 작성해달라는 요청
+- 커리어 전환 같은 개인 의사결정 → `personal-decision-grill.md` 사용
+
+## 질문 우선순위
+
+1. 최종 목표 — 이 학습이 끝나면 무엇을 할 수 있어야 하는가?
+2. 현재 수준 — 지금 이 분야에서 어디까지 알고 있는가?
+3. 시간 제약 — 주당 몇 시간, 총 몇 주를 쓸 수 있는가?
+4. 평가 기준 — "배웠다"를 어떻게 확인할 수 있는가?
+5. 실전 프로젝트 — 배운 걸 바로 적용할 프로젝트가 있는가?
+6. 피드백 루프 — 틀린 걸 어떻게 알 수 있는가?
+7. 우선순위 — 전부 배울 수 없다면 가장 중요한 것부터 순서는?
+8. 포기할 범위 — 이번에 안 배워도 되는 건 뭔가?
+9. 유지 가능성 — 이 학습 속도를 4주 이상 유지할 수 있는가?
+10. 다음 7일 행동 — 지금 당장 시작할 수 있는 가장 구체적인 행동은?
+
+## 강한 질문 패턴
+
+- "이 학습이 끝나면 '이걸 할 수 있다'를 한 문장으로 말하면 뭔가요?"
+- "주당 몇 시간 쓸 수 있나요? 그 시간이 정말 비어 있나요?"
+- "'배웠다'를 어떻게 확인할 건가요? 시험? 프로젝트? 다른 사람에게 설명?"
+- "이 로드맵을 4주 동안 유지할 수 있나요? 비슷한 계획을 전에 세운 적 있나요?"
+- "이 중에서 안 배워도 목표 달성에 큰 영향이 없는 건 뭔가요?"
+
+## 약한 질문 패턴
+
+- "이 계획 괜찮나요?"
+- "더 효율적으로 배울 수 있나요?"
+- "이 분야 전망이 어떤가요?"
+
+## 추천 옵션 구성 규칙
+
+- **자가 평가 기준이 모호할 때**: `(추천) 학습한 내용을 활용해 동작하는 가장 간단한 핵심 기능의 토이 프로젝트 직접 구현 및 검증` 옵션을 추천하고, 시험 문제 풀이/강의 완강 대안들로 선택지 구성
+- **투입 가용 시간이 불분명할 때**: `(추천) 무리 없는 지속 가능한 주 5시간, 총 4주 완수 계획` 옵션을 추천하고, 전일제 공부/불규칙한 틈새 시간 공부 대안들로 선택지 구성
+- **피드백 루프(오류 교정)가 없을 때**: `(추천) 매주 배운 개념을 한 페이지 문서로 재구성해 타인에게 설명하고 질문 받기` 옵션을 추천하고, 혼자서 연습문제 복습 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "전부 다 배우고 싶어" → "4주 안에 가장 중요한 것 3개만 고르면 뭔가요?"로 좁히기
+- "시간은 되는 대로" → "주 5시간을 기본값으로 둘까요? 아니면 더 쓸 수 있나요?"로 기본값 제안
+- "배우면 알게 되겠지" → "목표를 '이 기술로 X를 만들 수 있다'로 임시 정의할까요?"로 구체화
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 학습 목표가 "X를 할 수 있다" 형태로 정의되었다
+- 현재 수준이 파악되었다
+- 시간 제약이 현실적으로 설정되었다
+- 평가 기준이 최소 하나 있다
+- 우선순위가 정해져 있다
+- 다음 7일 계획이 구체적이다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 학습 목표
+- 현재 수준 기준
+- 우선순위
+- 제외할 범위
+- 실전 프로젝트
+- 피드백 루프
+- 다음 7일 계획
+
+## 실패 모드
+
+- 학습 목표를 "잘 알기"처럼 모호하게 두는 경우
+- 현재 수준을 파악하지 않는 경우
+- 시간 제약을 무시하고 비현실적인 계획을 세우는 경우
+- 평가 기준 없이 진행하는 경우
+- 실전 프로젝트 없이 이론만 나열하는 경우
+- 포기할 범위를 정하지 않아 전부 하려는 경우

package/skills/ultra-grill-me/references/learning-plan-grill.md

@@ -0,0 +1,68 @@
+# Learning Plan Verification
+
+## When to use this reference
+
+- Stress-testing custom study roadmaps, skills acquisition plans, or schedules
+- Verifying target topics, practice methods, and feedback loops
+- Reviewing curriculum outlines, coding tutorials, or textbook reading roadmaps
+- Assessing learning targets, metrics, or required project boundaries
+
+## When not to use this reference
+
+- Critique of high-level company or product strategies → Use `business-strategy-grill.md`
+- Verifying code models or API specifications → Use `technical-design-grill.md`
+- Generating raw study summaries or writing explanations of technical topics
+
+## Question Priority
+
+1. **Learning Goal** — What is the specific target skills or outcomes?
+2. **Evaluation Metric** — How do we prove the target skills have been acquired?
+3. **Time Commitment** — How many hours per week are allocated? For how many weeks?
+4. **Prerequisites & Current Level** — What background context or skills do we already have?
+5. **Topics to Cover** — What is the sequence of concepts to learn?
+6. **Practice & Implementation** — How do we apply the theory to practice?
+7. **Feedback & Loop** — How do we identify gaps and correct errors?
+8. **Diminishing Returns Point** — Are we learning irrelevant or overly deep topics?
+
+## Strong Question Patterns
+
+- "What is your main goal? (e.g., 'To build a full-stack Next.js app from scratch' vs. 'To pass an exam')"
+- "What is your validation criteria? What output will prove you acquired the skill?"
+- "How many hours per week can you consistently commit? Over-ambitious plans usually fail."
+- "How will you get feedback when you get stuck or make mistakes? Do you have a mentor, community, or test framework?"
+
+## Weak Question Patterns
+
+- "Is this study plan good?"
+- "Do you think this technology is promising?"
+- "Will you study hard?"
+
+## Recommended Option Rules
+
+- **Goal Metric Ambiguity**: Recommend `(Recommended) Complete a small, functional toy project demonstrating the core skill` and include finishing a lecture/passing a test to build the option set.
+- **Time Commitment Ambiguity**: Recommend `(Recommended) A realistic, sustainable commitment of 5 hours per week for 4 weeks` and include full-time/irregular options to build the option set.
+- **Feedback Loop Ambiguity**: Recommend `(Recommended) Summarize concepts into a 1-page guide and explain it to others to find gaps` and include solo review to build the option set.
+
+## Handling Vague Answers
+
+- "I want to learn everything about AI" → Narrow down: "Within 4 weeks, what is the single sub-topic or model architecture you must understand first?"
+- "I'll study in my free time" → Quantify: "Let's set a concrete target of '30 minutes every morning before work'. Shall we use this as our study schedule?"
+- "I'll just search Google if I get stuck" → Map loop: "Shall we set up a rule to spend maximum 30 minutes searching, and if still stuck, ask a specific question in a community?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- The target skill/outcome is clearly defined.
+- A functional project target (evaluation metric) is established.
+- The time budget (weekly hours, total weeks) is quantified.
+- The concept learning sequence is mapped.
+- An error-correction feedback loop is defined.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Clear Learning Goals
+- Output Verification Project
+- Time Budget Constraint
+- Weekly Learning Roadmap (Outline)
+- Feedback & Error Correction Plan

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

@@ -0,0 +1,98 @@
+# 개인 의사결정 검증
+
+## 이 reference를 사용할 때
+
+- 이직할지 말지 질문으로 검증해달라는 요청
+- 개인적 선택이 맞는지 grill 해달라는 요청
+- 이 결정을 후회하지 않게 빈틈을 찾아달라는 요청
+- 커리어 방향을 pressure-test 해달라는 요청
+- 구매 결정이나 생활 선택을 검증해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 커리어 조언을 일반적으로 해달라는 요청
+- 선택지를 추천해달라는 요청
+- 가벼운 고민을 들어달라는 요청
+- 학습 계획을 검증하는 경우 → `learning-plan-grill.md` 사용
+
+## 안전 경계
+
+이 reference는 개인 의사결정을 다루므로 다음을 반드시 지킨다.
+
+- 법률, 의료, 금융, 정신건강 영역에서는 단정적 조언을 피한다.
+- 전문가 상담이 필요한 경우 명시한다.
+- 사용자를 압박해서 특정 선택으로 몰지 않는다.
+- 판단 프레임워크를 제공하되, 최종 결정은 사용자가 한다.
+
+## 질문 우선순위
+
+1. 결정해야 하는 것 — 정확히 어떤 결정을 내려야 하는가?
+2. 선택지 — 현실적으로 고려 중인 선택지는 무엇인가?
+3. 목표 — 이 결정으로 달성하고 싶은 것은 뭔가?
+4. 제약 — 시간, 돈, 건강, 관계 등 움직일 수 없는 제약은?
+5. 기회비용 — 한 선택을 하면 포기하는 것 중 가장 아까운 건?
+6. 되돌릴 수 있는지 — 이 결정을 나중에 바꿀 수 있는가?
+7. 최악의 경우 — 이 결정이 완전히 틀렸을 때 최악의 상황은?
+8. 후회 가능성 — 5년 뒤에 어떤 선택을 더 후회할 것 같은가?
+9. 작은 실험 — 결정하기 전에 작게 시험해볼 방법이 있는가?
+10. 결정 기한 — 언제까지 결정해야 하는가?
+
+## 강한 질문 패턴
+
+- "이 결정을 한 문장으로 정리하면 'A를 할지 B를 할지'인가요?"
+- "A를 선택하면 포기하는 것 중 가장 아까운 건 뭔가요?"
+- "이 결정이 완전히 틀렸을 때 최악의 경우를 상상하면 어떤 상황인가요?"
+- "5년 뒤에 '그때 이걸 안 했으면 좋았을 텐데'라고 할 가능성이 더 높은 선택은 어느 쪽인가요?"
+- "결정 전에 1~2주 안에 작게 시험해볼 수 있는 방법이 있나요?"
+
+## 약한 질문 패턴
+
+- "어떤 게 나은 것 같나요?"
+- "행복할 수 있을까요?"
+- "다른 사람들은 어떻게 하나요?"
+
+## 추천 옵션 구성 규칙
+
+- **선택지가 1개뿐이거나 다른 현실적 대안이 없을 때**: `(추천) 현 상태 유지(아무 변화 없음)` 옵션을 대안 선택지에 강제 추가하여 비교 구성
+- **결정의 마감 기한이 정해지지 않았을 때**: `(추천) 향후 2주 이내에 의사결정 확정 후 행동 개시` 마감 옵션을 추천하고, 장기 유보/즉시 결정 대안들로 선택지 구성
+- **검증을 위한 사전 실험이 모호할 때**: `(추천) 가장 두려워하는 최악의 리스크 시나리오를 1주일 동안 직접 작게 모사하여 체험` 옵션을 추천하고, 주변 지인 인터뷰/이론적 정보 조사 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "둘 다 장단점이 있어" → "장단점 중 가장 중요한 한 가지씩만 고르면 뭔가요?"로 좁히기
+- "그냥 고민이야" → "이 결정을 내리지 않으면 3개월 뒤에 어떤 상태인가요?"로 결정의 긴급성 확인
+- "잘 모르겠어" → "가장 걱정되는 시나리오 하나만 말해주시면 거기서 시작할까요?"로 시작점 제시
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 결정 대상이 한 문장으로 정리되었다
+- 선택지가 최소 2개 비교되었다
+- 각 선택의 기회비용이 파악되었다
+- 되돌릴 수 있는지 여부가 확인되었다
+- 최악의 경우가 검토되었다
+- 작은 실험 또는 다음 행동이 정해졌다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 결정 대상
+- 선택지
+- 판단 기준
+- 기회비용
+- 리스크
+- 되돌릴 수 있는 조건
+- 작은 검증 행동
+- 결정 기한
+
+## 실패 모드
+
+- 사용자를 특정 선택으로 몰아가는 경우
+- 감정적 압박을 가하는 경우
+- 되돌릴 수 있는지를 확인하지 않는 경우
+- 최악의 경우를 검토하지 않는 경우
+- 기회비용을 무시하는 경우
+- 전문가 영역(법률, 의료, 금융)에서 단정적 조언을 하는 경우
+- 작은 실험 가능성을 검토하지 않는 경우

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

@@ -0,0 +1,71 @@
+# Personal Decision Verification
+
+## When to use this reference
+
+- Verifying complex personal choices (e.g., career moves, job changes, major purchases, relocate)
+- Stress-testing lifestyle schedules, personal priorities, or financial investments
+- Evaluating tradeoffs, opportunity costs, and worst-case scenarios for individuals
+- Reviewing decision metrics, timelines, or risk tolerances
+
+## When not to use this reference
+
+- Reviewing technical systems or code architecture → Use `technical-design-grill.md`
+- Critique of product MVP scope or features → Use `product-idea-grill.md`
+- Giving definitive legal, medical, or investment advice → Skip and warn (Safety check)
+
+## Question Priority
+
+1. **Decision Objective** — What is the primary outcome or problem this choice solves?
+2. **Current Options** — What are the concrete options available?
+3. **Core Constraints** — What are the non-negotiable boundaries? (e.g., location, cost, health)
+4. **Pros & Cons (Tradeoffs)** — What is the opportunity cost of choosing one over another?
+5. **Worst-Case Scenario** — What is the absolute worst result? Is it acceptable?
+6. **Reversibility** — Can this decision be undone? If so, what is the cost of reversing?
+7. **Timeline & Deadline** — By when must this decision be finalized?
+8. **Smallest Experiment** — How can we test/experience the choice on a micro-scale first?
+9. **Decision Tie-Breaker** — What is the single metric that breaks a tie?
+
+## Strong Question Patterns
+
+- "What is your primary constraint? If option A violates this constraint, it must be rejected immediately."
+- "What is the worst-case scenario for this choice? If it happens, do you have a fallback plan to recover?"
+- "Is this choice reversible? How difficult is it to change your mind after 6 months?"
+- "How can you run a 3-day experiment to mock this decision? (e.g., visit the city before relocating)"
+
+## Weak Question Patterns
+
+- "Which option makes you happier?"
+- "What do other people think?"
+- "Will it be a good choice?"
+
+## Recommended Option Rules
+
+- **Single Option Ambiguity**: Recommend `(Recommended) Maintain current status quo (no changes)` as the second option to build a comparative option set.
+- **Deadline Ambiguity**: Recommend `(Recommended) Finalize the decision and take action within 2 weeks` and include long-term delay options to build the option set.
+- **Experiment Ambiguity**: Recommend `(Recommended) Mock the worst-case risk scenario on a small scale for 1 week` and include searching online to build the option set.
+
+## Handling Vague Answers
+
+- "Both options are perfect" → Propose tie-breaker: "Which option has the lower financial risk? Let's use that to decide if all else is equal."
+- "I'll decide when the time is right" → Force deadline: "Shall we set a default deadline of 2 weeks from now to finalize our choice?"
+- "I can't test it beforehand" → Mock it: "Can we talk to someone who already made this choice? Let's find one person to interview."
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- The primary personal goal/objective is defined.
+- Core non-negotiable constraints are listed.
+- Tradeoffs (what is being sacrificed) are acknowledged.
+- Reversibility and worst-case scenario have been evaluated.
+- A micro-scale test/experiment is designed.
+- A final decision deadline is set.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Core Objective & Options
+- Non-negotiable Constraints
+- Tradeoffs & Opportunity Costs
+- Worst-Case Mitigation Plan
+- Next Smallest Test/Experiment
+- Final Decision Deadline

package/skills/ultra-grill-me/references/product-idea-grill.ko.md

@@ -0,0 +1,87 @@
+# 제품 아이디어 검증
+
+## 이 reference를 사용할 때
+
+- 제품 아이디어가 만들 가치가 있는지 검증해달라는 요청
+- SaaS 아이디어의 빈틈을 찾아달라는 요청
+- 기능을 만들기 전에 질문으로 검증해달라는 요청
+- MVP 범위가 적절한지 확인해달라는 요청
+- 제품 가설을 pressure-test 해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- SaaS 아이디어를 추천해달라는 요청
+- 제품 기획서를 바로 작성해달라는 요청
+- 제품 관련 개념을 설명해달라는 요청
+- 가격이나 GTM 전략만 따로 검증하는 요청 → `business-strategy-grill.md` 사용
+
+## 질문 우선순위
+
+1. 대상 사용자 — 이 제품의 1차 사용자는 누구인가?
+2. 해결하려는 문제 — 그 사용자의 어떤 문제를 해결하는가?
+3. 문제의 빈도와 강도 — 이 문제가 얼마나 자주, 얼마나 아프게 발생하는가?
+4. 기존 대안 — 사용자가 지금 이 문제를 어떻게 해결하고 있는가?
+5. 차별화 — 기존 대안 대비 어떤 점이 다른가?
+6. 지불 의사 — 누가 돈을 내는가? 얼마까지 낼 의사가 있는가?
+7. 성공 지표 — 이 제품이 성공했다는 걸 어떻게 알 수 있는가?
+8. MVP 범위 — 가장 작은 첫 버전에는 무엇이 들어가고 무엇이 빠지는가?
+9. 유통 / GTM — 1차 사용자에게 어떻게 도달하는가?
+10. 가장 작은 검증 실험 — 만들기 전에 가설을 검증할 수 있는 가장 작은 실험은?
+
+## 강한 질문 패턴
+
+- "이 제품이 없으면 대상 사용자가 지금 어떻게 해결하고 있나요?"
+- "이 문제가 주 1회 이상 발생하나요, 아니면 가끔 한 번씩인가요?"
+- "돈을 내는 사람과 실제로 쓰는 사람이 같은가요?"
+- "기존 대안이 '충분히 좋은' 수준이라면 사용자가 전환할 이유가 뭔가요?"
+- "만들기 전에 이 가설을 72시간 안에 검증할 수 있는 실험이 있나요?"
+
+## 약한 질문 패턴
+
+- "이 아이디어 좋은 것 같나요?"
+- "시장이 큰가요?"
+- "경쟁사가 있나요?"
+
+## 추천 옵션 구성 규칙
+
+- **대상 사용자가 불분명할 때**: `(추천) 가장 자주 이 문제를 겪는 구체적인 직군 및 기업 규모` 옵션을 추천하고, 넓은 타겟 범위의 대안들을 포함하여 선택지 구성
+- **성공 지표가 없을 때**: `(추천) 첫 달 유료 활성 사용자 수(Retention)` 또는 `(추천) 사전 예약 지불 의사 확인 수` 구조 옵션을 추천하고, 방문자 수/가입자 수 대안들로 선택지 구성
+- **MVP 범위가 넓을 때**: `(추천) 사용자가 기존 대안 대신 이걸 쓸 핵심 기능 딱 1개` 옵션을 추천하고, 확장형 기능 대안들을 포함하여 선택지 구성
+
+## 모호한 답변 처리
+
+- "모든 사람이 쓸 수 있어" → "가장 먼저 돈을 낼 사용자 한 그룹만 고르면 누구인가요?"로 좁히기
+- "문제가 있으니까 만드는 거지" → "그 문제가 주 1회 이상 발생하는지, 발생할 때 시간/돈이 얼마나 드는지 알고 계신가요?"로 구체화
+- "잘 모르겠어" → 가장 비슷한 기존 제품을 기본값으로 제안
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 대상 사용자가 구체적으로 정의되었다
+- 해결하려는 문제가 빈도와 강도를 포함해 설명되었다
+- 기존 대안이 파악되었다
+- 성공 지표가 최소 하나 있다
+- MVP 범위에서 포함/제외가 구분되었다
+- 가장 작은 검증 실험이 정해졌다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 명확해진 제품 가설
+- 타겟 사용자
+- 해결할 문제
+- 기존 대안
+- 가장 큰 리스크
+- 검증해야 할 핵심 가정
+- 가장 작은 다음 검증 실험
+
+## 실패 모드
+
+- 대상 사용자를 "모든 사람"으로 두고 넘어가는 경우
+- 문제의 빈도와 강도를 확인하지 않는 경우
+- 기존 대안을 무시하고 차별화를 검증하지 않는 경우
+- MVP 범위를 좁히지 않고 전체 제품을 논의하는 경우
+- 검증 실험 없이 바로 개발 계획으로 넘어가는 경우
+- 지불 의사를 확인하지 않는 경우

package/skills/ultra-grill-me/references/product-idea-grill.md

@@ -0,0 +1,67 @@
+# Product Idea Verification
+
+## When to use this reference
+
+- Surfacing loopholes in a product/feature idea
+- Stress-testing user problem statements or assumptions
+- Verifying the Minimum Viable Product (MVP) scope
+- Evaluating user personas, pain points, or differentiation strategies
+
+## When not to use this reference
+
+- The request is for pure code generation
+- General brainstorming of new ideas (e.g., "Give me 10 ideas")
+- Verifying technical architecture → Use `technical-design-grill.md`
+- Verifying business monetization/GTM → Use `business-strategy-grill.md`
+
+## Question Priority
+
+1. **Target User** — Who has this problem most severely?
+2. **Core Problem** — What is the specific pain point? Why does it matter?
+3. **Alternative Solutions** — How are they solving this problem today?
+4. **Core Value Proposition** — Why would they switch from their current solution?
+5. **MVP Scope** — What is the absolute minimum feature set to prove value?
+6. **Success Metric** — How do we measure if they actually find it valuable?
+7. **Risks & Assumptions** — What must be true for this to succeed?
+8. ** Diminishing Returns Point** — Are we building unnecessary bloat?
+
+## Strong Question Patterns
+
+- "Who is the single target user who suffers from this problem daily? Please define by role, scale, and context."
+- "What is their current workaround? If they use Excel or pen-and-paper, why is that no longer sufficient?"
+- "What is the single feature that, if removed, makes this product completely useless? That should be your MVP."
+- "How will you measure initial retention? (e.g., 30% of signed-up users returning on Day 7)"
+
+## Weak Question Patterns
+
+- "Is this a good idea?"
+- "Do you think people will buy this?"
+- "What features do you want to add in the future?"
+
+## Recommended Option Rules
+
+- **Target User Ambiguity**: Recommend `(Recommended) A highly specific niche user group experiencing this pain point daily` and include broad demographic alternatives to build the option set.
+- **Problem Ambiguity**: Recommend `(Recommended) A specific, quantifiable loss of time or money` and include general frustration alternatives to build the option set.
+- **MVP Scope Ambiguity**: Recommend `(Recommended) Exactly one core feature that solves the primary bottleneck` and include feature-rich alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "Everyone is my target user" → Narrow it down: "If you only had $100 for marketing, which single, specific group of 100 people would you target first?"
+- "It will have AI search, chat, dashboard, and notifications" → Force priority: "If you could only build one of these features before launch, which one is it?"
+- "Success is when it goes viral" → Quantify: "Let's set a concrete initial target, such as '10 active users using it twice a week'. Shall we use this as our temporary baseline?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- A specific, narrow target user is defined.
+- The primary pain point is articulated in terms of time/money loss.
+- The MVP is stripped down to 1-2 core features.
+- A quantifiable success metric is established.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Refined Target User Profile
+- Core Problem Statement
+- MVP Scope Boundaries (In/Out)
+- Primary Success Metric