LLM Wiki Distiller은(는) 무엇을 하나요?

핵심 생각

대규모 언어 모델(LLM)이 사용할 개인 지식 베이스를 유지 관리합니다: 사용자가 배운 것, 중요하게 생각하는 것, 관찰한 것, 저장한 것, 항상 잊는 것, 그리고 미래의 모델이 기억했으면 하는 것을 기록합니다. 백과사전식 일반 지식을 반복해서 쓰지 마세요; 사용자 자신의 관점, 출처 경로, 훈련 컷오프 이후의 새로운 정보, 재사용 가능한 개인 컨텍스트를 보존하는 데 집중하세요.

라이브러리 루트는 고정된 4개의 디렉터리 + 3개의 루트 파일(index.md / log.md / pending.md)로 구성됩니다:

raw/: 원자료, 첨부 파일, 미처리 inbox.
wiki/: LLM이 유지 관리하는 증류 항목.
_staging/: 병렬 배치 처리를 위한 임시 제안(디렉터리는 상주, 내용은 임시——integrate가 소비한 후 삭제).
review/: 리뷰 보고서(review/YYYY-MM/ 월별 아카이브, 최신 보고서가 리뷰 커서 역할을 겸함).

모든 생성, 수정, 삭제, 아카이브 또는 실질적인 리뷰는 index.md와 log.md를 함께 업데이트해야 합니다.

리소스 맵

이 파일은 라우팅만 담당합니다. 모드를 판단한 후 즉시 해당 모드를 읽으세요; 모드는 다음에 읽어야 할 reference/schema를 알려줍니다.

modes/quick.md: inbox를 거치지 않는 빠른 추가, 수정, 아카이브, 삭제.
modes/distill.md: raw/inbox/ 또는 기타 raw 자료를 처리하여 공식 증류.
modes/review.md: 리뷰, 상태 점검, 병합 제안; 각 라운드마다 날짜가 포함된 보고서를 생성합니다.
modes/search.md: 읽기 전용 검색 및 요약, 쓰기 작업 없음.
modes/integrate.md: 병렬 오케스트레이션 시, 오케스트레이터가 여러 capture-only 하위 에이전트의 제안을 일괄적으로 데이터베이스에 저장합니다(유일한 작성자, 직렬).
references/raw.md: raw 디렉터리, 출처 분류, 첨부 파일, 중복 자료 처리.
references/wiki.md: wiki 페이지 유형 판단, 경계, 쓰기 규칙.
schemas/common.md: 공통 YAML 필드, 통제 어휘, 날짜 및 상태.
schemas/raw.md: raw 마크다운 포인터, 출처 메타데이터, 첨부 파일 참조 규칙.
schemas/wiki.md: wiki 각 유형 페이지의 프론트매터와 본문 구조.
schemas/root.md: index.md, log.md, pending.md 형식.
schemas/report.md: 리뷰 보고서 위치, 프론트매터 및 본문 구조(최신 보고서가 리뷰 커서 역할을 겸함).
schemas/proposal.md: 병렬 오케스트레이션 시 capture-only → integrate 간 임시 제안 형식.

모든 리소스를 한 번에 읽지 마세요. 모드의 단계에 따라 점진적으로 읽으세요.

Step 0: 지식 베이스 루트 디렉터리 확인

어떤 모드를 사용하기 전에, 현재 작업 디렉터리가 지식 베이스 루트 디렉터리인지 확인하세요. 가벼운 멱등성(idempotent) 검사만 수행하고, 다른 reference/schema는 읽지 마세요.

현재 디렉터리를 기존 지식 베이스로 간주하며, 최소 2가지 신호를 충족해야 합니다:

raw/가 존재하고, 그 안에 inbox/, attachment/, dropzone/ 또는 기타 raw 분류가 있어야 합니다.
wiki/가 존재하고, 그 안에 concept/, entity/, summary/, scrap/ 또는 기타 wiki 분류가 있어야 합니다.
루트 파일 index.md, log.md, pending.md 중 최소 2개가 존재해야 합니다.

처리 방식:

2가지 이상 신호 충족: 모드 게이트로 진행.
0가지 신호 충족, 그리고 현재 디렉터리가 비어 있거나 거의 비어 있음: 사용자에게 현재 디렉터리에 지식 베이스를 초기화할지, 아니면 기존 지식 베이스 경로를 제공할지 물어보세요.
0-1가지 신호 충족, 그리고 현재 디렉터리가 다른 프로젝트로 명백함: 중단하고 사용자에게 지식 베이스 경로를 요청하세요; 현재 프로젝트에 raw/, wiki/를 생성하지 마세요.
사용자가 요청에서 지식 베이스 경로를 명시적으로 제공하는 경우, 해당 경로로 전환한 후 이 검사를 다시 수행하세요.

모드 게이트

사용자의 의미에 따라 네 가지 중 하나를 선택하며, 사용자가 모드 이름을 말하도록 요구하지 않습니다:

사용자가 기존 라이브러리를 복습/유지 관리하려는 경우, 예: "리뷰 좀 해줘", "모순 확인해줘", "상태 점검 실행해줘" → modes/review.md를 읽으세요.
사용자가 기존 내용을 단순히 검색/질문/요약하려는 경우, 추가나 수정을 요구하지 않음 → modes/search.md를 읽으세요.
사용자가 추가, 수정, 아카이브 또는 삭제를 원하지만, inbox/raw 원자료를 처리할 필요가 없는 경우 → modes/quick.md를 읽으세요.
사용자가 raw/inbox/, 클리핑, 긴 글, 채팅, 소셜 미디어, PDF, 비디오 트랜스크립트, GitHub 프로젝트 또는 기타 raw 자료를 처리하려는 경우 → modes/distill.md를 읽으세요.

모드가 확실하지 않으면, 사용자가 쓰기 작업을 요구하는지 먼저 판단하세요; 쓰기이지만 출처가 아직 정리되지 않은 경우 증류로 이동; 순수 조회는 검색으로 이동; 라이브러리 자체 유지 관리는 리뷰로 이동.

병렬 오케스트레이션 보충: 증류 모드에는 capture-only 변형이 있습니다(각 하위 에이전트는 하나의 항목만 담당하며, 자신의 summary + raw + _staging/<id>.md proposal만 작성하고 공유 페이지는 건드리지 않음). 이는 integrate 모드(오케스트레이터가 여러 proposal을 일괄 저장)와 함께 사용됩니다. 제약 조건은 modes/distill.md의 "실행 모드" 절에 작성되어 있습니다; 언제 병렬 처리를 하고, 어떻게 하위 에이전트를 할당할지는 호출 프로젝트의 CLAUDE.md가 결정하며, 이 스킬의 범위가 아닙니다.

공유 하드 규칙

wiki를 "컴파일된 기억"으로 취급하고, 원문 저장소로 취급하지 마세요. raw 출처 경로는 보존하되, 전체 원문을 wiki로 옮기지 마세요.
YAML original_url에는 웹 페이지, 동영상, 게시물, 논문, 프로젝트 홈페이지 등 1차 출처를 빠르게 열기 위한 핵심 외부 URL만 넣습니다; http:// 또는 https://만 허용됩니다. 로컬 .md, raw/..., wiki/summary/..., 첨부 파일 경로, 절대/상대 파일 경로, Obsidian 내부 링크 및 대화 내의 로컬 문서 링크는 절대 original_url에 쓸 수 없습니다; 외부 URL이 없으면 빈 배열 []로 남겨둡니다. raw 경로, summary 페이지 및 내부 증거 관계는 본문 ## 출처 또는 related에 작성합니다. 검색 보충, 배경 자료, 추가 자료는 본문 끝의 ## 출처에 넣고, 프론트매터에 넣지 마세요. wiki YAML에서 sources 필드를 사용하지 마세요.
2025-01-01 이전의 지식은 기본적으로 간략히 작성하되, 사용자에게 중요하거나, 드물거나, 사용자 사고의 기초를 형성하는 경우는 예외입니다. 2025-01-01 이후의 지식은 모델 훈련 컷오프 이후의 격차를 메울 수 있으므로 더 중요하게 다룰 수 있지만, 여전히 "완전함"보다는 "유용함"을 기준으로 합니다.
절대 날짜를 사용하세요. 지속적인 사실에 "어제", "오늘", "최근"만 쓰지 말고, 반드시 절대 날짜도 함께 명시하세요.
사실, 추론, 선호도 및 약한 신호를 구분하세요. 약한 신호를 안정적인 사실로 직접 기록하지 마세요.
새로운 출처와 기존 페이지가 충돌하는 경우, 양쪽의 주장, 출처 및 날짜를 유지하고 충돌을 표시하세요. 조용히 덮어쓰지 마세요.
쓰기 전에 중복 페이지, 유사 제목, 별칭, 출처 URL 및 핵심 문장을 검색하세요.
기본적으로 지식을 물리적으로 삭제하지 마세요; 아카이브, 구식화, 대체된 경우에도 기록을 유지하세요. 실제 삭제 전에 반드시 확인해야 합니다.
민감하거나, 영향력이 크거나, 의료/법률/재무, 정체성 정의와 같은 결론에 대해 증거가 모호한 경우, 쓰기 전에 사용자에게 먼저 물어보세요.
"판단 작업"과 "기계적 작업"을 구분하세요: 판단 작업(증류取舍, 병합 결정, 리뷰 시 내용의 중요성/삭제 여부 평가)은 에이전트가 의미를 이해한 후 직접 완료해야 하며, 스크립트에 위임할 수 없습니다——이것이 이 스킬이 존재하는 가치이며, 스크립트는 판단력이 없습니다. 기계적 작업(명확한 규칙에 따른 필터링, 카운팅, 이름 변경, 형식 변환, 라이브러리가 커진 후 필요할 수 있는 로컬 검색/인덱스/벡터 DB와 같은 인프라)은 명령줄 도구나 스크립트를 사용하는 것을 권장하며, 우선적으로 그렇게 해야 합니다.
기계적 작업을 수행할 때는 가능한 한 전체 파일 내용을 에이전트의 컨텍스트로 읽어들이지 않는 방식을 우선시하세요(grep/sed/awk/일회성 스크립트, blind 실행). 결과는 카운팅과 diff로 검증하고(wc -l, grep -c, git diff --stat), 전체 파일을 읽거나 전체 텍스트를 출력하여 확인하지 마세요——토큰을 절약하고 결과는 동일하게 신뢰할 수 있습니다. 작업 자체에 판단이 필요한 경우(예: 리뷰 시 특정 내용을 삭제할지 결정)에만 먼저 읽고 처리하세요.
에이전트 오케스트레이션 파일을 포함하지 마세요. 다른 플랫폼의 AGENTS.md, CLAUDE.md 또는 하위 에이전트 전략은 사용자 프로젝트가 직접 유지 관리합니다.

LLM Wiki Distiller