kb-interview

name	kb-interview
version	1.0.0
category	knowledge
description	사내 업무 지식을 사용자 인터뷰(grill)로 끌어내 wiki에 기록한다 — 모델 기본 지식·웹에 없는 신선한 시장·거래처·경쟁 정보를 집요하게 질문해 빈 곳·모순·모호함을 없애고, 불확실성이 해소된 뒤에만 날짜·출처·확신도를 단 wiki 페이지로 남긴다. Use when: '경쟁사 정리하자', '시장 세분 문서로 만들자', 머릿속에만 있는 업무 지식을 굳히고 싶을 때, 위키가 빈 도메인을 채울 때. NOT for: 이미 자료가 충분한 단순 받아쓰기, 한 건 분석 중 부수적으로 안 사실의 즉시 기록(그건 일반 wiki write-back 반사).
metadata	{"deneb":{"emoji":"🎤","tags":["인터뷰","지식추출","문서화","엘리시테이션","백과","grill","interview","knowledge"],"triggers":["지식 인터뷰","인터뷰로 정리","경쟁사 정리","시장 세분","머릿속에만"],"related_skills":["email-analysis"]}}
user-invocable	true

지식 인터뷰 → 문서화 (kb-interview)

사용자 머릿속의 업무 지식을 **집요한 질문(grill)**으로 끌어내 wiki 페이지로 만든다. 목표는 받아쓰기가 아니라 불확실성 제거 — 빈 칸·모순·모호한 답이 사라질 때까지 질문하고, 그 다음에야 문서를 쓴다.

이 지식의 성격 — 관측이 아니라 청취

기존 위키는 대부분 관측된 지식이다: 메일·데이터만 봐도 아는 프로젝트·거래·인물 정보라 에이전트가 분석 중 write-back으로 자동으로 쌓는다. 이 스킬이 만드는 건 청취된 지식 — 시장·경쟁·세분 판단처럼 사용자 머릿속에만 있고 메일·데이터·웹·모델 어디에도 없는 것. 누가 적어주지 않으면 시스템에 영원히 안 들어온다. 그래서:

• 생성·유지의 유일 경로다. write-back 반사는 이 문서를 절대 못 만든다(데이터가 침묵) — 오직 인터뷰로만 태어나고 자란다.
• 위키가 비면 "미확인"이 아니라 "물어볼 것". 이 주제로 검색해 비면 데이터·모델로 지어내지 말고 사용자에게 인터뷰해 채운다.
• 스스로 안 낡지도 안 고쳐지지도 않는다. 관측 문서는 데이터가 갱신하지만 이건 아니다 → 작성일을 박고 주기적으로 "아직 유효?"를 되묻는다(변하면 supersedes).
• 표시해 구분하라. 출처(사용자 인터뷰)·확신도와 구분 태그(예: 사용자지식)를 달아 자동 관측 페이지와 섞이지 않게 한다 — write-back이 덮어쓰지 않도록.

When to Use

• 사용자가 "경쟁사/시장 세분/… 정리하자"처럼 한 토픽을 문서로 굳히고 싶을 때
• 위키가 빈 도메인을 채워야 하는데, 그 지식이 사용자 머릿속에만 있을 때
• 모델 기본 지식·웹 검색으로는 못 얻는 신선한 사내·시장 정보일 때

쓰지 않는 경우: 이미 자료가 충분해 인터뷰가 불필요(→ 그냥 정리), 한 건 분석 중 부수적으로 안 사실(→ 일반 wiki write-back 반사가 처리).

핵심 원칙

1. 불확실성을 지도화하라. 토픽의 doc 타입에 맞는 커버리지 체크리스트 (references/coverage-checklists.md)를 먼저 read — 그게 "아직 모르는 것"의 목록이다.
2. 한 번에 가장 값진 질문만. 2~4개씩 묶어 묻되, 답에 따라 다음 질문을 재조정한다. 20개를 쏟지 마라 — 흐름이 끊기고 사용자가 지친다.
3. 모호하면 파고들어라. "좀 비싸"→"얼마? 우리 대비 몇 %?", "큰 회사"→"매출·인원 규모?". 숫자·이름·날짜·예시·출처를 요구한다. 두루뭉술한 답을 그대로 적지 마라.
4. 모순을 잡아라. 새 답이 이전 답과 충돌하면 즉시 들춰서 해소한다.
5. 지어내지 마라. 사용자가 모르면 그 칸은 명시적 unknown으로 남긴다. 특히 이 지식은 모델 가중치·웹에 없어 추측을 검증할 데가 없다 — 메우면 그대로 오류가 된다.
6. 진행을 보여줘라. 가끔 "채워진 것 / 아직 비는 것"을 짧게 요약해 사용자가 끝을 보게 한다.
7. 신선도를 박아라. 신생·급변 시장이라 신선도가 사실의 일부다 — 모든 항목에 작성일·출처·확신도를 단다. 바뀐 사실은 덮어쓰지 말고 wiki supersedes로 새 버전을 잇는다.

선택지 칩 (객관식은 탭으로 묻는다)

객관식 질문(분류·예/아니오·후보 목록)은 choices 펜스로 내라. 네이티브 앱이 각 줄을 탭형 칩으로 렌더하고, 탭하면 그 줄이 그대로 답으로 전송된다(한 줄 = 한 선택지).

```choices
모듈·케이블 따로
모듈·케이블 합쳐 하나로
```

• 객관식·짧은 후보엔 칩, 서술형(단계·수치·자유설명)엔 일반 질문. 한 턴에 칩 질문은 하나만 — 여러 객관식을 동시에 칩으로 쏟지 마라.
• 칩 줄은 그대로 전송되니 사용자가 답으로 말할 문구로 쓴다. ✏️ 직접 입력 칩은 앱이 자동으로 붙여 사용자가 보기에 없는 답을 바로 타이핑하니, 기타·직접 입력 줄을 따로 넣지 마라.

절차

1. 스코프 확정 — 무슨 doc 타입인지, 대상 범위가 어디까지인지 한 줄로 합의한다. (예: "경쟁사 — A사 단독? 경쟁 구도 전체?")
2. 체크리스트 로드 — references/coverage-checklists.md에서 해당 타입의 질문 은행을 read. 해당 타입이 없으면 generic 체크리스트를 쓴다.
3. 그릴 루프 — 비어있는 항목 중 가장 중요한 것부터 질문 → 답 기록 → 모호/모순 검사 → 체크리스트 갱신 → 반복. 사용자가 "모름/나중에"라고 하면 그 항목을 unknown으로 표시.
4. 불확실성 게이트 — 아래 셋이 모두 충족되기 전엔 문서를 쓰지 않는다: (a) 필수 항목을 모두 커버(또는 명시적 unknown), (b) 미해소 모순 없음, (c) 추정은 확인됨.
5. 초안 + 확인 — 해당 템플릿(templates/<type>.md) 구조로 초안을 보여주고 "이대로 맞나? 빠진 것?"을 묻는다. 고칠 게 없을 때까지 다듬는다.
6. 기록 — 확정 내용을 wiki 페이지로 남긴다: wiki(action="write")(또는 knowledge(op="record"))로 title·category(업무/시스템 등)·tags(사용자지식 + 시장·경쟁사명 등)·related를 달고, 본문 머리에 작성일·출처·확신도를 명시한다. 기존 항목 갱신이면 새 내용으로 쓰고 옛 페이지를 supersedes로 잇는다(신생 시장이라 자주 바뀐다).

doc 타입 & 기록 (사실→wiki, 절차→skill)

용도로 가른다 — 출처·그릴은 같지만(둘 다 청취된 지식) 산출물이 다르다: 참조해 답하는 사실은 wiki 페이지, **따라 수행하는 절차(SOP)**는 procedural skill.

타입	용도	가이드	산출
경쟁사	참조	templates/competitor.md	wiki write — tags [경쟁사, <시장>]
시장 세분	참조	templates/market-segment.md	wiki write — tags [시장세분, <시장>]
거래처	참조	checklists(partner)	wiki write — tags [거래처, <상호>]
업무 SOP	수행	templates/sop-skill.md + checklists(process)	skill → skills/operations/<slug>/SKILL.md
그 외 사실	참조	checklists(generic)	wiki write

★ SkillsBench: 사전학습에 없는 기관 특유 절차 스킬이 최고 ROI(+40~52pp, 의료·제조). 단 실제 단계·필드를 인코딩해야 효과가 난다 — 추측으로 채우면 역효과(−1pp). SOP일수록 그릴이 필수다(추측 금지·unknown 표시·근거 요구).

기록 위치 (wiki 단일 store)

• 산출물은 wiki 페이지다 — 별도 백과·오버레이 없음. 단일 store라 검색·백업·supersedes가 한 곳에서 된다. (자동주입에 기대지 않고 에이전트가 knowledge/wiki로 검색해 꺼낸다.)
• 본문 머리에 작성일 · 출처(직접/전언/공개) · 확신도를 명시한다 — 신생 시장이라 신선도가 사실의 일부다.
• 갱신은 덮어쓰기가 아니라 supersedes — 옛 사실의 변천이 추적된다.
• 이 지식은 모델·웹에 없으니, 검색이 비면 **"미확인"**이라 답하고 인터뷰로 채운다(추측 금지).

Pitfalls

• 질문 폭격 → 사용자 피로. 2~4개로 묶고 답을 보고 다음을 정하라.
• 모호한 답을 그대로 기록 → stale·무용. 반드시 구체화한 뒤 적어라.
• unknown을 그럴듯하게 메움 → 신뢰 붕괴 (모델·웹이 검증 못 함). 모르면 "미확인"으로 남겨라.
• 작성일·출처 없이 기록 → 신선도 못 따져 곧 무용. 머리에 꼭 달아라.
• 게이트 무시하고 성급히 작성 → 반쪽 문서. 셋(커버·무모순·추정확인) 충족 전엔 쓰지 마라.