| 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 반사가 처리).
핵심 원칙
- 불확실성을 지도화하라. 토픽의 doc 타입에 맞는 커버리지 체크리스트
(
references/coverage-checklists.md)를 먼저 read — 그게 "아직 모르는 것"의 목록이다.
- 한 번에 가장 값진 질문만. 2~4개씩 묶어 묻되, 답에 따라 다음 질문을 재조정한다.
20개를 쏟지 마라 — 흐름이 끊기고 사용자가 지친다.
- 모호하면 파고들어라. "좀 비싸"→"얼마? 우리 대비 몇 %?", "큰 회사"→"매출·인원 규모?".
숫자·이름·날짜·예시·출처를 요구한다. 두루뭉술한 답을 그대로 적지 마라.
- 모순을 잡아라. 새 답이 이전 답과 충돌하면 즉시 들춰서 해소한다.
- 지어내지 마라. 사용자가 모르면 그 칸은 명시적 unknown으로 남긴다. 특히 이
지식은 모델 가중치·웹에 없어 추측을 검증할 데가 없다 — 메우면 그대로 오류가 된다.
- 진행을 보여줘라. 가끔 "채워진 것 / 아직 비는 것"을 짧게 요약해 사용자가 끝을 보게 한다.
- 신선도를 박아라. 신생·급변 시장이라 신선도가 사실의 일부다 — 모든 항목에
작성일·출처·확신도를 단다. 바뀐 사실은 덮어쓰지 말고 wiki supersedes로 새 버전을 잇는다.
선택지 칩 (객관식은 탭으로 묻는다)
객관식 질문(분류·예/아니오·후보 목록)은 choices 펜스로 내라. 네이티브 앱이 각 줄을
탭형 칩으로 렌더하고, 탭하면 그 줄이 그대로 답으로 전송된다(한 줄 = 한 선택지).
```choices
모듈·케이블 따로
모듈·케이블 합쳐 하나로
```
- 객관식·짧은 후보엔 칩, 서술형(단계·수치·자유설명)엔 일반 질문. 한 턴에 칩 질문은
하나만 — 여러 객관식을 동시에 칩으로 쏟지 마라.
- 칩 줄은 그대로 전송되니 사용자가 답으로 말할 문구로 쓴다.
✏️ 직접 입력 칩은 앱이
자동으로 붙여 사용자가 보기에 없는 답을 바로 타이핑하니, 기타·직접 입력 줄을 따로 넣지 마라.
절차
- 스코프 확정 — 무슨 doc 타입인지, 대상 범위가 어디까지인지 한 줄로 합의한다.
(예: "경쟁사 — A사 단독? 경쟁 구도 전체?")
- 체크리스트 로드 —
references/coverage-checklists.md에서 해당 타입의 질문 은행을 read.
해당 타입이 없으면 generic 체크리스트를 쓴다.
- 그릴 루프 — 비어있는 항목 중 가장 중요한 것부터 질문 → 답 기록 → 모호/모순 검사 →
체크리스트 갱신 → 반복. 사용자가 "모름/나중에"라고 하면 그 항목을 unknown으로 표시.
- 불확실성 게이트 — 아래 셋이 모두 충족되기 전엔 문서를 쓰지 않는다:
(a) 필수 항목을 모두 커버(또는 명시적 unknown), (b) 미해소 모순 없음, (c) 추정은 확인됨.
- 초안 + 확인 — 해당 템플릿(
templates/<type>.md) 구조로 초안을 보여주고
"이대로 맞나? 빠진 것?"을 묻는다. 고칠 게 없을 때까지 다듬는다.
- 기록 — 확정 내용을 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을 그럴듯하게 메움 → 신뢰 붕괴 (모델·웹이 검증 못 함). 모르면 "미확인"으로 남겨라.
- 작성일·출처 없이 기록 → 신선도 못 따져 곧 무용. 머리에 꼭 달아라.
- 게이트 무시하고 성급히 작성 → 반쪽 문서. 셋(커버·무모순·추정확인) 충족 전엔 쓰지 마라.
