# Should Trigger Examples

이 문서의 예시들은 사용자의 요청이 `ultra-grill-me` 스킬의 목적에 부합하여, 스킬이 자동으로 활성화(trigger)되어야 하는 경우를 정의합니다. 모든 문서는 한국어로 작성되었습니다.

---

## 예시 1. 제품 아이디어 압박 검증 요청 (product-idea)

### 사용자 입력
```txt
새로운 사이드 프로젝트로 개발자용 할일 관리 앱 아이디어가 있는데, 만들기 전에 끝까지 빈틈 좀 털어줘.
```

### 기대 동작
1. `ultra-grill-me` 스킬이 즉시 활성화된다.
2. 바로 조언을 하거나 기획안을 작성하지 않고, [product-idea-grill.md](../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](../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](../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](../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](../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](../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. 직접 답변

번호를 선택하거나, 다른 옵션을 요청하거나, 직접 답해 주세요.
```