Day3 Clarify

Day 3: Clarify

이 스킬이 호출되면 아래 STOP PROTOCOL을 반드시 따른다.

---

용어 정리

---

STOP PROTOCOL — 절대 위반 금지

이 프로토콜은 이 스킬의 최우선 규칙이다.

아래 규칙을 위반하면 수업이 망가진다.

각 블록은 반드시 2턴에 걸쳐 진행한다

┌─ Phase A (첫 번째 턴) ──────────────────────────────┐
│ 1. references/에서 해당 블록 파일의 EXPLAIN 섹션을 읽는다    │
│ 2. 기능을 설명한다                                        │
│ 3. references/에서 해당 블록 파일의 EXECUTE 섹션을 읽는다    │
│ 4. "지금 직접 실행해보세요"라고 안내한다                     │
│ 5. ⛔ 여기서 반드시 STOP. 턴을 종료한다.                    │
│                                                          │
│ ❌ 절대 하지 않는 것: 퀴즈 출제, QUIZ 섹션 읽기             │
│ ❌ 절대 하지 않는 것: AskUserQuestion 호출                  │
│ ❌ 절대 하지 않는 것: "실행해봤나요?" 질문                   │
└──────────────────────────────────────────────────────────┘

  ⬇️ 사용자가 돌아와서 "했어", "완료", "다음" 등을 입력한다

┌─ Phase B (두 번째 턴) ──────────────────────────────┐
│ 1. references/에서 해당 블록 파일의 QUIZ 섹션을 읽는다       │
│ 2. AskUserQuestion으로 퀴즈를 출제한다                     │
│ 3. 정답/오답 피드백을 준다                                 │
│ 4. 다음 블록으로 이동할지 AskUserQuestion으로 묻는다         │
│ 5. ⛔ 다음 블록을 시작하면 다시 Phase A부터.                │
└──────────────────────────────────────────────────────────┘

핵심 금지 사항 (절대 위반 금지)

1. Phase A에서 AskUserQuestion을 호출하지 않는다 — 설명 + 실행 안내 후 바로 Stop 2. Phase A에서 퀴즈를 내지 않는다 — QUIZ 섹션은 Phase B에서만 읽는다 3. Phase A에서 "실행해봤나요?"를 묻지 않는다 — 사용자가 먼저 말할 때까지 기다린다 4. 한 턴에 EXPLAIN + QUIZ를 동시에 하지 않는다 — 반드시 2턴으로 나눈다

Phase A 종료 시 필수 문구

Phase A의 마지막에는 반드시 아래 형태의 문구를 출력하고 Stop한다:

---
👆 위 내용을 직접 실행해보세요.
실행이 끝나면 "완료" 또는 "다음"이라고 입력해주세요.

이 문구 이후에 어떤 도구 호출(AskUserQuestion 포함)이나 추가 텍스트도 출력하지 않는다.

블록 특수 규칙

• Block 0 (Concept): 표준 Phase A/B. AskUserQuestion 체험이 EXECUTE의 핵심.
• Block 1 (Experience Vague): 예외 — Phase A에서 Claude가 clarify:vague 프로토콜을 시연한다. 학생이 모호한 요구사항을 던지면 Claude가 AskUserQuestion으로 clarify한다. 학생은 "clarify 받는 사람" 역할.
• Block 2 (Build Clarify): 표준이지만 EXECUTE에서 플러그인의 vague SKILL.md를 Read로 분석한 후, 템플릿 기반으로 나만의 스킬을 작성한다.
• Block 3 (Plugin & Unknown): 메인 블록 — Plugin 심화 분석 + clarify:unknown 체험.
• Block 4 (PRD & GitHub): 표준 Phase A/B이지만 PRD 작성은 인터랙티브. Claude가 GitHub ID 확인 → PRD 초안 작성 → 검증 → PR 제출까지 자동으로 진행. Phase B 퀴즈 후 Day 3 과제 안내.

---

소요 시간

---

핵심 전략

"설치한 플러그인을 해부하고, 직접 만들어보기"

Day 1에서 설치한 clarify 플러그인을 체험 → 구조 분석 → 나만의 버전 제작 → 심화 활용

Day 1에서 설치          Day 3에서 깊이 파기
┌──────────────┐       ┌──────────────────────────┐
│ /plugin      │       │ Block 0: 개념 이해        │
│   install    │  ───▶ │ Block 1: vague 체험       │
│   clarify    │       │ Block 2: 나만의 스킬 제작  │
└──────────────┘       │ Block 3: Plugin 해부 +    │
                       │          unknown 체험     │
                       │ Block 4: PRD + GitHub 제출 │
                       └──────────────────────────┘

---

References 파일 맵

파일 경로는 이 SKILL.md 기준 상대경로다.

각 reference 파일은 ## EXPLAIN, ## EXECUTE, ## QUIZ 섹션으로 구성된다.

---

Templates 파일 맵

---

진행 규칙

• 한 번에 한 블록씩 진행한다
• "다음", "skip", 블록 번호/이름으로 이동한다
• Claude Code 관련 질문이 오면 claude-code-guide 에이전트(내장 도구)로 답변한다. 답변 후 사용자가 직접 따라할 수 있게 단계별로 안내하고, 질문할 때는 AskUserQuestion을 사용한다. 내장 에이전트 답변이 부정확하다고 판단되면, 공식 문서를 curl로 파일에 저장한 뒤 Read 툴로 꼼꼼히 읽고 정확한 정보로 다시 답한다 (WebFetch는 요약/손실 위험이 있으므로 사용하지 않는다)

---

시작

스킬 시작 시 아래를 안내하고 AskUserQuestion으로 어디서 시작할지 물어본다.

아직 camp-2 스킬이 설치되지 않았다면:

```

npx skills add ai-native-camp/camp-2

```

AskUserQuestion({
  "questions": [{
    "question": "어디서부터 시작할까요?",
    "header": "시작 블록",
    "options": [
      {"label": "Block 0: Concept", "description": "Clarify 개념 + AskUserQuestion 체험"},
      {"label": "Block 1: Experience", "description": "clarify:vague 플러그인 체험"},
      {"label": "Block 2: Build", "description": "나만의 Clarify 스킬 만들기"},
      {"label": "Block 3: Plugin & Unknown", "description": "Plugin 심화 + unknown 체험"},
      {"label": "Block 4: PRD & GitHub", "description": "PRD 작성 + GitHub 첫 PR 제출"}
    ],
    "multiSelect": false
  }]
})

시작 블록 선택 후 → 해당 블록의 Phase A부터 진행한다.

Block 0: Clarify 개념 + AskUserQuestion

EXPLAIN

왜 Clarify가 필요한가

Garbage In, Garbage Out

프로그래밍에서 가장 오래된 격언 중 하나다: 쓰레기가 들어가면, 쓰레기가 나온다.

Claude Code도 마찬가지다. 아무리 똑똑한 AI라도 모호한 입력을 받으면 모호한 결과를 낸다.

사용자: "로고 만들어줘"
Claude: (어떤 브랜드? 어떤 스타일? 어디에 쓸 건지? 색상은?)
        → 아무것도 모르니까 아무거나 만든다
        → 결과물이 마음에 안 든다
        → "아니 그게 아니라..."
        → 3번 반복

이게 바로 모호한 요구사항의 함정이다. 머릿속에는 그림이 있는데, Claude에게 전달한 건 단어 3개뿐.

Plan은 해결책이 아니다

"그러면 Plan 모드를 쓰면 되지 않나?"

Plan은 토큰을 본격적으로 써서 내용을 불리는 단계다. 코드를 탐색하고, 파일 구조를 분석하고, 작업을 분해한다. 여기서 비로소 "어떻게 만들지"를 설계한다.

문제는 — Plan이 "뭘 만들지"를 추출해주지 않는다는 것이다.

❌ 모호한 채로 Plan에 들어가면:
   "로고 만들어줘" → Plan → "로고를 만드는 계획을 세웠습니다"
   → 뭘 만드는 건지 여전히 모호
   → 계획이 방향을 잡아주지 못함
   → 토큰만 낭비

✅ Clarify를 거치면:
   "로고 만들어줘" → Clarify → "미니멀, 남색+흰색, 앱 아이콘" → Plan
   → 명확한 목표로 계획을 세움
   → 토큰이 의미 있는 곳에 쓰임

Clarify는 Plan보다 앞선 단계다. 내 의도를 먼저 추출해야, Plan이 올바른 방향으로 토큰을 쓸 수 있다.

CC Workflow: 코딩의 4단계

실제로 Claude Code를 제대로 쓰려면 최소 4단계가 필요하다. 이건 1기 캠퍼분들도 쓰고 있는 실전 워크플로우다:

┌─────────────────────────────────────────────────────────────────────────┐
│                        CC Workflow 101 전체 흐름                         │
└─────────────────────────────────────────────────────────────────────────┘

  사용자 요청
       │
       ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  clarify    │────▶│    plan     │────▶│  implement  │────▶│    wrap     │
│             │     │             │     │             │     │             │
│ 뭘 만들지   │     │ 어떻게      │     │ 만든다      │     │ 마무리      │
│ 명확화      │     │ 만들지 계획 │     │             │     │ 커밋/PR     │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘

  ════════════════════════════════════════════════════════════════════════
  필수 흐름:  clarify ──▶ plan ──▶ implement ──▶ wrap
  ════════════════════════════════════════════════════════════════════════

오늘 배우는 Clarify는 이 4단계의 첫 번째다. 여기서 의도를 명확히 하지 않으면, 나머지 3단계가 전부 잘못된 방향으로 간다.

Clarify가 하는 일

Clarify는 이 간극을 메운다:

모호한 요구사항          Clarify           구체적인 스펙
"로고 만들어줘"  ──────▶  질문 5개  ──────▶  "미니멀 스타일, 남색+흰색,
                         ▲                    앱 아이콘용, 심볼 마크,
                         │                    PNG 512x512"
                    AskUserQuestion
                    (가설 기반 선택지)

AskUserQuestion이란

Claude Code에는 사용자에게 구조화된 질문을 할 수 있는 도구가 있다. 그게 AskUserQuestion이다.

핵심은 Hypothesis-as-Options (가설을 선택지로) 원칙:

❌ BAD (열린 질문):
   "어떤 스타일로 만들까요?"
   → 사용자: "음... 그냥 예쁘게?"  (답변 불가)

✅ GOOD (가설 기반 선택지):
   "어떤 스타일로 만들까요?"
   - 미니멀 (선과 여백 중심)
   - 일러스트 (캐릭터/아이콘 중심)
   - 타이포그래피 (글자 중심)
   → 사용자: "미니멀!"  (즉시 결정)

왜 선택지가 나올까? — AI가 토큰을 더 쓰는 것이다

AskUserQuestion은 question(질문)과 option(선택지)을 동시에 제공하는 도구다.

이게 뭘 의미하냐면 — Claude가 단순히 "뭘 원해요?"라고 물어보는 게 아니라, 더 많은 토큰을 사용해서 여러분의 상황을 분석하고, 그럴듯한 선택지까지 만들어서 제안하는 것이다.

일반 질문:     "어떤 스타일로 만들까요?"          ← 토큰 적게 사용, 사용자에게 부담 전가
AskUserQuestion: "어떤 스타일?" + [미니멀/일러스트/타이포]  ← 토큰 더 사용, AI가 먼저 고민

즉, AI가 먼저 생각하고, 사용자는 고르기만 하면 된다. 토큰을 아끼려고 열린 질문을 하면, 결국 모호한 답변 → 재질문 → 더 많은 토큰 낭비로 이어진다. 선택지를 제시하는 게 오히려 효율적이다.

실제 도구 구조

AskUserQuestion은 이런 구조로 되어 있다:

{
  "questions": [
    {
      "question": "어떤 스타일로 만들까요?",
      "header": "스타일",
      "options": [
        {"label": "미니멀", "description": "선과 여백 중심의 깔끔한 디자인"},
        {"label": "일러스트", "description": "캐릭터나 아이콘 중심"},
        {"label": "타이포그래피", "description": "글자 자체가 로고"}
      ],
      "multiSelect": false
    }
  ]
}

한 번에 최대 4개 질문을 묶어서 보낼 수 있다. 관련 있는 질문을 묶으면 왕복 횟수가 줄어든다.

사용자에게는 항상 "Other" 옵션이 자동으로 추가된다. 선택지에 없는 답변도 자유롭게 입력할 수 있다.

왜 이게 더 좋은가?

6가지 모호함 카테고리

요구사항에서 모호한 부분은 보통 6가지 카테고리로 분류된다:

Day 1에서 설치한 clarify 플러그인

Day 1 Block 3-7에서 이미 clarify 플러그인을 설치했다. 기억나는가?

/plugin marketplace add team-attention/plugins-for-claude-natives
/plugin install clarify

오늘은 이 플러그인을 직접 써보고, 해부하고, 나만의 버전을 만든다.

EXECUTE

AskUserQuestion이 어떻게 동작하는지 직접 체험해보자.

Claude에게 이렇게 말해보라:

나한테 오늘 저녁 뭐 먹을지 AskUserQuestion으로 물어봐.
가설 기반 선택지로 3개 질문해줘.

Claude가 AskUserQuestion 도구를 사용해서 구조화된 질문을 던질 것이다.

선택지를 고르면서 "아, 이렇게 질문을 받으면 쉽게 답할 수 있구나"를 느껴보자.

QUIZ

AskUserQuestion({
  "questions": [{
    "question": "Hypothesis-as-Options 원칙의 핵심은 무엇인가요?",
    "header": "Quiz 0",
    "options": [
      {"label": "열린 질문 대신 가설을 선택지로 제시한다", "description": "각 선택지가 사용자의 의도에 대한 검증 가능한 가설"},
      {"label": "질문을 최대한 많이 한다", "description": "질문 수보다 질문의 질이 중요"},
      {"label": "사용자가 직접 요구사항을 작성하게 한다", "description": "Claude가 가설을 먼저 제시하는 것이 핵심"},
      {"label": "모든 가능성을 나열한다", "description": "선택지는 2-4개가 적정, 너무 많으면 선택 피로"}
    ],
    "multiSelect": false
  }]
})

정답: 1번. Hypothesis-as-Options의 핵심은 열린 질문("뭘 원하세요?") 대신 그럴듯한 가설을 선택지로 제시하는 것이다. 사용자의 인지 부하를 줄이고, 답변이 즉시 구체적이 된다.

Block 1: clarify:vague 체험

EXPLAIN

clarify 플러그인의 vague 스킬

Day 1에서 설치한 clarify 플러그인에는 vague라는 스킬이 있다. 모호한 요구사항을 구체적인 스펙으로 바꿔주는 스킬이다.

vague 스킬의 4단계 프로토콜:

Phase 1: Capture        원본 요구사항을 그대로 기록
    ↓
Phase 2: Iterate        AskUserQuestion으로 5-8개 질문
    ↓                   (가설 기반 선택지, 최대 4개씩 묶어서)
Phase 3: Before/After   변환 전후를 비교하여 보여줌
    ↓
Phase 4: Save           결과를 파일로 저장할지 물어봄

실제 변환 예시

┌─ Before ──────────────────────────┐
│ "우리 팀 회의록 자동화해줘"         │
└───────────────────────────────────┘
                 ↓ Clarify (질문 6개)
┌─ After ───────────────────────────┐
│ 목표: 주간 팀 회의 후 회의록 자동 생성│
│ 범위: 월요일 오전 회의만 대상        │
│ 형식: Notion 페이지, 참석자별 액션   │
│ 입력: Fireflies 녹취록             │
│ 제약: 회의 후 30분 내 완성          │
│ 우선순위: 액션 아이템 > 논의 내용    │
└───────────────────────────────────┘

"회의록 자동화해줘"라는 5단어가 구체적인 실행 스펙으로 바뀌었다. 이 과정에서 사용자 스스로도 "아, 나는 전체 회의가 아니라 월요일 회의만 원했구나"를 발견하게 된다.

EXECUTE

이제 clarify:vague를 직접 체험해보자.

1단계: 플러그인 설치 확인

먼저 clarify 플러그인이 설치되어 있는지 확인한다:

/plugin

목록에 clarify가 보이면 OK. 없으면 아래 명령으로 다시 설치한다:

```

/plugin marketplace add team-attention/plugins-for-claude-natives

/plugin install clarify

```

2단계: 모호한 요구사항 던지기

자신의 1주일 과제 중 가장 모호한 부분을 하나 골라서, Claude에게 던져보자.

예시:

나는 [내 과제 중 모호한 부분]을 하고 싶어.
근데 아직 구체적으로 뭘 어떻게 해야 할지 모르겠어.
모호한 부분을 clarify해줘.

또는 직접 스킬을 호출할 수도 있다:

/clarify:vague

Claude가 AskUserQuestion으로 5-8개의 가설 기반 질문을 던질 것이다.

각 질문에 선택지를 고르면서, 처음에는 몰랐던 내 요구사항이 구체화되는 과정을 경험하자.

마지막에 Before/After 요약이 나온다.

QUIZ

AskUserQuestion({
  "questions": [
    {
      "question": "clarify:vague의 핵심 원칙은 무엇인가요?",
      "header": "Quiz 1-1",
      "options": [
        {"label": "가설을 선택지로 제시 (Hypothesis-as-Options)", "description": "열린 질문 대신 가설 기반 옵션을 AskUserQuestion으로 제시"},
        {"label": "최대한 많은 질문을 한다", "description": "5-8개 상한이 있음"},
        {"label": "사용자의 답을 그대로 실행한다", "description": "Clarify 후에도 확인이 필요함"}
      ],
      "multiSelect": false
    },
    {
      "question": "clarify:vague 체험 중 가장 의외였던 점은 무엇인가요?",
      "header": "체험 소감",
      "options": [
        {"label": "내가 뭘 원하는지 스스로 몰랐던 부분이 있었다", "description": "질문을 받으면서 비로소 깨달음"},
        {"label": "선택지로 물어보니 결정이 빨라졌다", "description": "열린 질문보다 인지 부하가 낮았음"},
        {"label": "Before/After 비교가 인상적이었다", "description": "변환 전후의 차이가 명확"},
        {"label": "아직 잘 와닿지 않는다", "description": "다음 블록에서 직접 만들어보면 더 체감됨"}
      ],
      "multiSelect": true
    }
  ]
})

정답: Quiz 1-1은 1번. Hypothesis-as-Options이 clarify:vague의 핵심이다. 열린 질문이 아니라, Claude가 먼저 가설을 세워서 선택지로 제시한다. 체험 소감은 어떤 것이든 좋다 — 중요한 건 "clarify 받는 사람" 입장을 직접 경험한 것이다.

Block 2: 나만의 Clarify 스킬 만들기

EXPLAIN

플러그인 스킬을 해부한다

Block 1에서 clarify:vague를 체험했다. 이제 그 스킬이 어떻게 만들어져 있는지 직접 열어보자.

Claude에게 이렇게 요청한다:

clarify 플러그인의 vague SKILL.md를 Read로 읽어줘

Claude가 Read 도구로 설치된 플러그인의 SKILL.md 파일을 열어서 보여줄 것이다.

SKILL.md의 구조

vague SKILL.md를 열어보면 이런 구조로 되어 있다:

---
name: vague                          ← 스킬 이름
description: ...trigger on...         ← 언제 이 스킬이 호출되는지
---

# Vague: Requirement Clarification   ← 제목

## When to Use                        ← 사용 상황
## Core Principle                     ← 핵심 원칙 (Hypothesis-as-Options)
## Protocol                           ← 실행 프로토콜
  ### Phase 1: Capture                ←   1단계: 캡처
  ### Phase 2: Iterate                ←   2단계: 반복 질문
  ### Phase 3: Before/After           ←   3단계: 전후 비교
  ### Phase 4: Save                   ←   4단계: 저장
## Ambiguity Categories              ← 모호함 분류표
## Rules                              ← 규칙

나만의 버전을 만든다

이 구조를 기반으로, 자신의 업무에 맞는 Clarify 스킬을 만들어보자.

뭘 바꿀 수 있나?

6단계 작성 가이드

1. Read: 플러그인의 vague SKILL.md를 읽어서 구조를 파악한다 2. Copy: 이 스킬의 templates/clarify-vague.md 템플릿을 가져온다 3. Customize: <!-- CUSTOMIZE --> 주석이 있는 부분을 자기 업무에 맞게 수정한다 4. Save: .claude/skills/my-clarify/SKILL.md로 저장한다 5. Test: 저장 후 새 세션에서 트리거 키워드로 호출해본다 6. Iterate: 써보면서 질문/카테고리를 계속 다듬는다

EXECUTE

나만의 Clarify 스킬을 직접 만들어보자.

1단계: 플러그인 스킬 분석

먼저 원본을 분석한다. Claude에게 이렇게 요청한다:

clarify 플러그인의 vague SKILL.md를 Read로 읽어서 구조를 분석해줘

2단계: 템플릿 기반으로 작성

이 스킬의 templates/clarify-vague.md를 기반으로 자신만의 버전을 만든다:

templates/clarify-vague.md를 Read로 읽어서 보여줘.
이 템플릿을 기반으로 내 업무([자신의 업무 설명])에 맞는 clarify 스킬을 만들어줘.
.claude/skills/my-clarify/SKILL.md에 저장해줘.

<!-- CUSTOMIZE --> 주석이 있는 부분을 꼭 자기 상황에 맞게 바꿔야 한다.

그대로 복사하면 의미가 없다.

3단계: 테스트

저장이 되었으면 바로 테스트해보자:

내가 만든 my-clarify 스킬로 [모호한 요구사항]을 clarify해줘

잘 동작하는지 확인한다. 질문이 자기 업무에 맞게 나오는지, Before/After가 유용한지 체크한다.

QUIZ

AskUserQuestion({
  "questions": [
    {
      "question": "SKILL.md의 Protocol에서 Phase 2의 핵심은 무엇인가요?",
      "header": "Quiz 2-1",
      "options": [
        {"label": "AskUserQuestion으로 가설 기반 질문을 반복한다", "description": "최대 4개씩 묶어서, 5-8개 상한"},
        {"label": "사용자에게 자유롭게 설명하게 한다", "description": "열린 질문은 Hypothesis-as-Options 위반"},
        {"label": "Claude가 알아서 결정한다", "description": "가정하지 않는 것이 규칙"}
      ],
      "multiSelect": false
    },
    {
      "question": "Phase 3에서 반드시 보여줘야 하는 것은 무엇인가요?",
      "header": "Quiz 2-2",
      "options": [
        {"label": "Before/After — 원본과 구체화된 요구사항의 비교", "description": "변환 과정을 시각화하여 확인"},
        {"label": "질문 목록만 나열", "description": "질문보다 결과(변환된 스펙)가 중요"},
        {"label": "실행 코드", "description": "Clarify는 스펙을 만드는 과정, 코드는 그 다음"}
      ],
      "multiSelect": false
    }
  ]
})

정답: Quiz 2-1은 1번. Phase 2의 핵심은 AskUserQuestion으로 가설 기반 질문을 반복하는 것이다. 관련 질문을 최대 4개씩 묶어서 효율적으로 물어본다.

정답: Quiz 2-2는 1번. Phase 3의 핵심은 Before/After 비교다. 원래 모호했던 요구사항과 clarify 후 구체화된 스펙을 나란히 보여줘야 한다. 이 비교가 있어야 "이 과정이 의미 있었다"는 걸 실감할 수 있다.

Block 3: Plugin 심화 + clarify:unknown 체험 + 과제

EXPLAIN

Part 1: Plugin Deep Dive (~15분)

Day 1 복습: Plugin이란

Day 1 Block 3-7에서 배웠다. Plugin은 Skill + MCP + Hook + Agent를 하나의 설치 단위로 묶은 패키지다.

개별 설치 (Plugin 없이)          Plugin (한 번에)
┌─────────┐                    ┌─────────────────┐
│ Skill A │ ← 수동 복사         │ clarify plugin  │
│ Skill B │ ← 수동 복사         │ ┌─ vague        │
│ MCP 설정 │ ← 수동 설정   vs   │ ├─ unknown      │
│ Hook 설정│ ← 수동 설정         │ └─ metamedium   │
│ Agent   │ ← 수동 설정         └────────┬────────┘
└─────────┘                             │
  팀원 각자 반복                  /plugin install clarify
                                   한 줄이면 끝

clarify 플러그인 해부

clarify 플러그인은 이렇게 구성되어 있다:

clarify/
├── .claude-plugin/
│   └── plugin.json          ← 플러그인의 신분증
│                               name, version, description,
│                               author, keywords 등
├── skills/
│   ├── vague/               ← 스킬 1: 요구사항 명확화
│   │   └── SKILL.md
│   ├── unknown/             ← 스킬 2: 전략 사각지대 분석
│   │   ├── SKILL.md
│   │   └── references/
│   │       ├── question-design.md
│   │       └── playbook-template.md
│   └── metamedium/          ← 스킬 3: 내용 vs 형식 관점 전환
│       ├── SKILL.md
│       └── references/
│           └── alan-kay-quotes.md

plugin.json 핵심 필드:

3개 스킬의 역할 차이:

Plugin Marketplace 심화

Plugin은 Marketplace를 통해 배포된다.

┌─ 마켓플레이스 등록 ─────────────────────────────┐
│ /plugin marketplace add [owner/repo]             │
│ 예: /plugin marketplace add team-attention/...   │
└──────────────────────────────┬───────────────────┘
                               ↓
┌─ 플러그인 설치 ─────────────────────────────────┐
│ /plugin install [name]                           │
│ 예: /plugin install clarify                      │
└──────────────────────────────┬───────────────────┘
                               ↓
┌─ 설치된 플러그인 확인 ──────────────────────────┐
│ /plugin                                          │
│ → 설치된 모든 플러그인과 스킬 목록               │
└──────────────────────────────────────────────────┘

나중에 자신만의 플러그인을 만들어 마켓플레이스에 등록할 수도 있다. 오늘은 "사용하는 쪽"에 집중한다.

---

Part 2: clarify:unknown 체험 (~15분)

Known/Unknown 4분면 프레임워크

vague가 "모호한 요구사항"을 다뤘다면, unknown은 "전략의 사각지대"를 다룬다.

              ┌─────────────────────────────────────┐
              │           내가 아는가?                │
              │       YES              NO            │
         ┌────┼──────────────┬──────────────────┐   │
   남들이│YES │  KK (60%)     │  KU (25%)         │   │
   아는가?│    │ 이미 아는 것  │ 모르는 줄 아는 것  │   │
         │    │ → 체계화      │ → 실험 설계        │   │
         ├────┼──────────────┼──────────────────┤   │
         │ NO │  UK (10%)     │  UU (5%)          │   │
         │    │ 갖고 있지만   │  모르는 줄도       │   │
         │    │ 활용 안 하는것│  모르는 것          │   │
         │    │ → 레버리지    │  → 안테나 설치     │   │
         └────┴──────────────┴──────────────────┘   │
              └─────────────────────────────────────┘

3-Round Depth Pattern

unknown 스킬은 3라운드에 걸쳐 점점 깊이 파고든다:

R1: 넓게 (3-4개 질문)     "대충 맞나요?"
  ↓ R1 답변 분석
R2: 집중 (2-3개 질문)     "여기가 약하네요, 더 파봅시다"
  ↓ R2 답변 분석
R3: 실행 (2-3개 질문)     "구체적으로 어떻게 할까요?" (선택)

핵심: R2 질문은 R1 답변에서 만든다. R3 질문은 R2 답변에서 만든다. 미리 준비한 질문을 쓰지 않는다.

EXECUTE

Part 1: Plugin 파일 탐색

설치된 clarify 플러그인의 실제 파일을 직접 확인해보자.

/plugin

설치된 플러그인 목록을 확인한다.

그 다음, Claude에게 플러그인 파일을 직접 읽어달라고 해보자:

clarify 플러그인의 plugin.json을 Read로 읽어줘

clarify 플러그인의 skills 폴더에 어떤 SKILL.md 파일들이 있는지 보여줘

Plugin의 구조를 직접 눈으로 확인하는 것이 목표다.

Part 2: clarify:unknown 체험

이제 clarify 플러그인의 두 번째 스킬, unknown을 사용해보자.

자신의 과제나 업무 전략에 대해 Known/Unknown 분석을 요청한다:

/clarify:unknown

또는:

내 [1주일 과제 / 업무 전략]에 대해 Known/Unknown 분석해줘

R1 → R2 → R3 라운드를 거치면서, 자신이 "모르는 줄도 몰랐던 것"이 드러나는 경험을 한다.

QUIZ

AskUserQuestion({
  "questions": [
    {
      "question": "Plugin의 핵심 파일은 무엇인가요?",
      "header": "Quiz 3-1",
      "options": [
        {"label": "plugin.json", "description": "플러그인의 이름, 버전, 설명 등 메타데이터를 담는 매니페스트 파일"},
        {"label": "SKILL.md", "description": "스킬의 본체이지만, 플러그인 전체를 정의하는 파일은 아님"},
        {"label": "CLAUDE.md", "description": "프로젝트 설정 파일이지, 플러그인의 핵심 파일은 아님"}
      ],
      "multiSelect": false
    },
    {
      "question": "clarify 플러그인에 포함된 스킬 개수는 몇 개인가요?",
      "header": "Quiz 3-2",
      "options": [
        {"label": "3개 (vague, unknown, metamedium)", "description": "요구사항 명확화, 전략 사각지대, 관점 전환"},
        {"label": "1개 (vague만)", "description": "unknown과 metamedium도 포함"},
        {"label": "2개 (vague, unknown)", "description": "metamedium도 있음"}
      ],
      "multiSelect": false
    },
    {
      "question": "vague와 unknown의 차이는 무엇인가요?",
      "header": "Quiz 3-3",
      "options": [
        {"label": "vague는 요구사항 명확화, unknown은 전략 사각지대 분석", "description": "vague=모호한 요청→스펙, unknown=전략→4분면 분석"},
        {"label": "vague는 쉬운 버전, unknown은 어려운 버전", "description": "난이도 차이가 아니라 목적이 다름"},
        {"label": "둘 다 같은 기능의 다른 이름", "description": "프로토콜과 출력 형식이 완전히 다름"}
      ],
      "multiSelect": false
    }
  ]
})

정답: Quiz 3-1은 1번. plugin.json이 플러그인의 핵심 파일이다. 이름, 버전, 설명, 키워드 등 메타데이터를 담고 있어 마켓플레이스에서 검색/설치의 기준이 된다.

정답: Quiz 3-2는 1번. clarify 플러그인에는 3개 스킬 (vague, unknown, metamedium)이 포함되어 있다.

정답: Quiz 3-3은 1번. vague는 모호한 요구사항을 구체적 스펙으로 바꾸고 (Phase 1-4), unknown은 전략의 사각지대를 4분면으로 분석한다 (R1→R2→R3). 목적이 다르기 때문에 프로토콜도 다르다.

---

과제 안내

Quiz 완료 후 아래 과제를 안내한다:

Day 3 과제

1주일 과제 중 하나를 골라서, clarify를 시켜보세요.

1. 1주일 과제 중 가장 모호한 부분을 하나 고른다 2. Claude에게 clarify를 요청한다 (직접 만든 my-clarify 스킬 또는 clarify:vague 플러그인 사용) 3. AskUserQuestion을 통한 질문에 답하면서, 요구사항이 구체화되는 과정을 경험한다

Slack 공유 (#day3)

채널에 올릴 내용:

• clarify 전: 처음에 Claude에게 던진 요구사항 (원문 그대로)
• clarify 후: AskUserQuestion을 거친 뒤 구체화된 요구사항
• 가장 의외였던 질문: Claude가 물어본 것 중 "아, 이걸 생각 못 했네" 싶었던 질문 1개

요구사항이 완벽하지 않아도 된다. "이 과정을 거치니까 내가 뭘 원하는지 더 알게 됐다"는 경험 자체가 핵심이다.

Block 4: PRD 작성 & GitHub 첫 제출

EXPLAIN

1. PRD란?

PRD(Product Requirements Document)는 "이 프로젝트가 뭘 해결하고, 뭘 만드는지" 정리한 문서입니다.

비유: 건축 설계도

집을 짓기 전에 설계도를 그리듯, 프로젝트를 시작하기 전에 PRD를 씁니다. "누구의, 어떤 불편을, 어떻게 해결하는가"를 한 장에 정리하는 것입니다.

2. 왜 지금 PRD를 쓰나?

Day 1~3에서 배운 것들을 정리할 때입니다:

• Day 1: Claude Code 핵심 기능 7개를 배웠다
• Day 2: MCP를 연결하고 Context Sync 스킬을 만들었다
• Day 3: Clarify로 모호한 요구사항을 명확하게 만들었다

지금이 가장 좋은 타이밍입니다. 배운 기술을 기반으로 "나는 이걸 만들겠다"를 선언하는 문서가 PRD입니다.

3. PRD 템플릿

# [프로젝트 제목]

## 문제
> 한 줄: 누구의, 어떤 불편을, 어떻게 해결하는가

- **현재 상태**: (구체적 수치 — 몇 건, 몇 분, 몇 명)
- **원하는 상태**: (1주 후 돌아가고 있을 모습)
- **성공 기준**: (숫자로 판단 가능한 것 1~2개)

## 스킬
| # | 스킬명 | 한 줄 설명 | 상태 |
|---|--------|-----------|------|
| 1 | `/my-skill-1` | 입력 → 출력 | ✅ 동작 / 🔨 진행중 |
| 2 | `/my-skill-2` | 입력 → 출력 | ✅ 동작 / 🔨 진행중 |

## 변화 기록
- **Day 1**: "처음 정의" →
- **Day 3**: "지금 정의" →
- **가장 크게 달라진 점**:

4. GitHub으로 제출하기

GitHub은 코드와 문서를 함께 관리하고 공유하는 온라인 서비스입니다. Google Docs의 코드 버전이라고 생각하세요.

여러분의 개인 저장소(repo)가 이미 만들어져 있습니다.

운영진이 캠프 시작 전에 여러분 각자의 GitHub ID로 private repo를 만들어뒀습니다:

https://github.com/ai-native-camp/{여러분의-github-id}

이 repo는 PRD만 넣는 곳이 아닙니다. 캠프 기간 동안 만드는 모든 작업물(스킬, PRD, 과제 결과물)이 여기에 쌓입니다. 캠프가 끝나면 여러분의 포트폴리오가 됩니다.

GitHub이 처음이라면? git-for-everyone 플러그인을 설치하세요.

이 플러그인은 1기 개발자 캠퍼들이 비개발자를 위해 직접 만든 Claude Code 플러그인입니다.

>

```

/plugin install git-onboarding

```

>

설치 후 /git-onboarding-auto를 실행하면, 환경 점검 → Git 설정 → 파일 생성 → 브랜치 → PR 생성까지 한 번에 자동 처리합니다. 이미 설정이 된 환경이면 필요한 단계만 건너뛰고 바로 진행됩니다. 막히면 /git-onboarding-help로 용어 설명과 FAQ를 볼 수 있습니다.

제출 과정 요약:

[개인 repo clone] → [PRD 작성] → [브랜치에서 저장] → [PR로 검토 요청]

걱정하지 마세요. Claude가 모든 명령어를 자동으로 실행합니다. 여러분은 내용만 채우면 됩니다.

---

EXECUTE

Step 0: 환경 체크

Claude에게 아래를 입력하세요:

git이 설치되어 있는지, gh CLI가 인증되어 있는지 확인해줘.

문제가 있으면 Claude가 해결 방법을 안내합니다. 모두 통과하면 다음 단계로.

>

GitHub이 처음이라면 git-for-everyone 플러그인을 설치하세요. 1기 개발자 캠퍼들이 만든 Git 자동 온보딩 도구입니다. /git-onboarding-auto 한 줄이면 설정부터 PR까지 자동으로 진행됩니다.

Step 1: 내 repo 가져오기

내 GitHub 개인 repo를 clone해줘.
내 GitHub ID를 물어봐줘.
repo 주소는 ai-native-camp/{내 GitHub ID}야.

Claude가 GitHub ID를 물어본 뒤 gh repo clone ai-native-camp/{id}로 여러분의 개인 repo를 가져옵니다.

Step 2: PRD 작성

오늘까지 배운 내용을 바탕으로 PRD를 작성해줘.
PRD 템플릿을 써서, 내가 캠프에서 만든 스킬 기반으로.
.claude/skills/ 폴더에 어떤 스킬이 있는지 먼저 확인해줘.

Claude가 여러분이 만든 스킬 목록을 보여준 다음, PRD 초안을 작성합니다.

Step 3: PRD 검증

Claude가 아래 8개 항목을 자동으로 검증합니다:

Step 4: GitHub PR 제출

검증 통과 후:

PRD를 내 GitHub repo에 제출해줘. PR까지 만들어줘.

Claude가 개인 repo에서 브랜치 생성 → commit → push → PR 생성을 자동으로 처리합니다.

완료되면 PR URL이 출력됩니다. 이 URL을 과제 제출에 사용합니다.

---

QUIZ

AskUserQuestion({
  "questions": [
    {
      "question": "PRD에서 가장 중요한 섹션은?",
      "header": "Quiz 4-1",
      "options": [
        {"label": "변화 기록", "description": "Day 1부터 지금까지의 변화 과정"},
        {"label": "문제 정의", "description": "누구의, 어떤 불편을, 어떻게 해결하는가"},
        {"label": "스킬 목록", "description": "만든 스킬의 이름과 상태"},
        {"label": "프로젝트 제목", "description": "한 줄로 요약한 프로젝트명"}
      ],
      "multiSelect": false
    },
    {
      "question": "GitHub에서 PR(Pull Request)이란?",
      "header": "Quiz 4-2",
      "options": [
        {"label": "코드를 삭제하는 요청", "description": "불필요한 코드를 정리"},
        {"label": "내 작업을 확인해주세요라는 검토 요청", "description": "운영진에게 보내는 제출 버튼"},
        {"label": "새 프로젝트를 만드는 명령", "description": "GitHub에 새 저장소 생성"},
        {"label": "다른 사람의 코드를 가져오는 것", "description": "외부 코드를 내 프로젝트에 복사"}
      ],
      "multiSelect": false
    }
  ]
})

정답 4-1: 2번. PRD의 핵심은 "문제 정의"다. 누구의, 어떤 불편을, 어떻게 해결하는가를 명확히 정의해야 나머지가 의미를 갖는다. 스킬 목록이나 변화 기록은 문제 정의를 뒷받침하는 보조 섹션이다.

정답 4-2: 2번. PR(Pull Request)은 "내 작업을 확인해주세요"라고 운영진에게 보내는 검토 요청이다. 제출 버튼을 누르는 것과 같다. 운영진이 확인 후 승인하면 반영된다.

Day 3 과제

Slack #day3 채널에 아래를 공유하세요:

1. Before/After: Clarify 전후 요구사항 비교 (Block 1에서 체험한 결과) 2. 가장 의외였던 질문: Claude가 던진 질문 중 "이건 생각 못했다" 싶었던 것 3. PRD PR 링크: 방금 제출한 GitHub PR URL

나만의 Clarify 스킬 템플릿

이 템플릿을 기반으로 .claude/skills/my-clarify/SKILL.md를 만든다.

<!-- CUSTOMIZE --> 주석이 있는 부분을 자신의 업무에 맞게 수정한다.

---

아래 내용을 .claude/skills/my-clarify/SKILL.md에 복사한 뒤 커스터마이즈한다:

---
name: my-clarify
description: <!-- CUSTOMIZE: 트리거 설명을 자신의 업무에 맞게 수정 --> 모호한 요구사항을 명확하게 만든다. "요구사항 정리", "뭘 원하는 건지", "clarify" 요청에 사용.
---

# My Clarify: 요구사항 명확화

모호하거나 애매한 요구사항을 가설 기반 질문으로 구체적인 실행 가능한 스펙으로 바꾼다.
**반드시 AskUserQuestion 도구를 사용**한다 — 일반 텍스트로 질문하지 않는다.

## 언제 사용하는가

<!-- CUSTOMIZE: 자신의 업무에서 모호한 요청이 오는 상황을 적는다 -->
- 애매한 업무 요청 ("그거 좀 정리해줘")
- 불완전한 문제 설명 ("이거 이상해")
- 구체적이지 않은 목표 ("좀 더 좋게 만들어줘")

## 핵심 원칙: 가설을 선택지로

열린 질문 대신, 그럴듯한 해석을 선택지로 제시한다.
각 선택지는 "사용자가 실제로 원하는 것"에 대한 검증 가능한 가설이다.

BAD: "어떤 형식으로 하고 싶으세요?" ← 열린 질문, 높은 인지 부하 GOOD: "PDF / 슬라이드 / 노션 페이지 / 이메일" ← 하나 고르기, 낮은 부하

## 프로토콜

### Phase 1: 원본 캡처 + 진단

원래 요구사항을 그대로 기록한다. 모호한 부분을 식별한다:
- 무엇이 불분명하거나 미지정인가?
- 어떤 가정이 필요한가?
- 어떤 결정이 해석에 맡겨져 있는가?

### Phase 2: 반복 질문 (AskUserQuestion)

AskUserQuestion으로 모호함을 해소한다. **관련 질문을 최대 4개까지 묶어서** 한 번에 물어본다.

<!-- CUSTOMIZE: 질문 개수를 조절한다. 업무가 단순하면 3-5개, 복잡하면 5-8개 -->
**상한: 5-8개 질문.** 핵심 모호함이 해소되거나, 사용자가 "됐어"라고 하거나, 상한에 도달하면 멈춘다.

<!-- CUSTOMIZE: 자신의 업무에 맞는 모호함 카테고리를 추가/수정한다 -->
**모호함 카테고리**:

| 카테고리 | 가설 예시 |
|----------|----------|
| **범위** | 전체 / 일부만 / 특정 대상 |
| **형식** | 문서 / 프레젠테이션 / 구두 보고 |
| **기한** | 오늘 중 / 이번 주 / 기한 없음 |
| **수준** | 초안 / 완성본 / 최종 검토용 |
| **대상** | 내부용 / 외부 공유용 / 상사 보고용 |
| **우선순위** | 반드시 / 있으면 좋고 / 나중에 |

### Phase 3: Before/After 요약

변환 결과를 보여준다:

요구사항 Clarify 결과

Before (원본)

"{원래 요구사항 그대로}"

After (구체화됨)

목표: [정확한 설명] 범위: [포함/제외 사항] 제약: [제한, 선호사항] 완료 기준: [언제 끝난 건지 아는 방법]

결정 사항:

## 규칙

1. **가설로 물어본다**: 모든 선택지는 그럴듯한 해석이다
2. **가정하지 않는다**: 추측 대신 질문한다
3. **의도를 보존한다**: 정제하되 방향을 바꾸지 않는다
4. **5-8개 질문이 한계다**: 그 이상은 피로감
5. **관련 질문은 묶는다**: AskUserQuestion 한 번에 최대 4개
6. **변화를 추적한다**: 반드시 Before/After를 보여준다

---

커스터마이즈 체크리스트

• [ ] description의 트리거 키워드를 자신의 업무에 맞게 수정했는가?
• [ ] "언제 사용하는가"에 자신의 실제 상황을 적었는가?
• [ ] 모호함 카테고리를 자신의 업무 도메인에 맞게 바꿨는가?
• [ ] 질문 개수 상한을 조절했는가?
• [ ] Before/After 포맷이 자신의 업무 산출물에 맞는가?