claude-obsidian 스킬 뜯어보기 (3): wiki-ingest

이 스킬이 하는 일

wiki-ingest는 소스 문서를 읽고 위키에 통합하는 스킬이다. .raw/ 폴더에 들어온 파일, URL, 이미지를 받아서 소스 요약, 엔티티 페이지, 개념 페이지, 도메인 페이지를 생성하거나 갱신하고, 교차 참조를 엮고, 모순을 플래깅한다. SKILL.md의 첫 줄이 핵심을 요약한다.

Read the source. Write the wiki. Cross-reference everything.
A single source typically touches 8-15 wiki pages.

소스 1개가 8-15개 위키 페이지를 건드린다는 것은 단순 복사가 아니라 구조화된 지식 분해가 일어난다는 뜻이다. 엔티티는 wiki/entities/에, 개념은 wiki/concepts/에, 도메인 연결은 wiki/domains/에, 요약은 wiki/sources/에 각각 분산 배치된다.

이 글에서는 스킬 본체인 SKILL.md와 병렬 배치 에이전트인 agents/wiki-ingest.md 두 파일을 뜯어보기하며, 22개 개념을 코드 레벨에서 분석한다.

파일 구조

claude-obsidian/
├── skills/wiki-ingest/
│   └── SKILL.md            # 스킬 본체 — 워크플로우, 델타 트래킹, 모순 처리
└── agents/
    └── wiki-ingest.md      # 병렬 배치 에이전트 — 다중 소스 동시 처리

wiki 스킬이 9개 파일에 93개 개념을 담은 것에 비하면 파일 수는 적다. 그러나 이 두 파일이 담당하는 로직의 밀도가 높다. SKILL.md가 "무엇을 어떻게 처리할 것인가"를, agents/wiki-ingest.md가 "여러 소스를 어떻게 병렬로 돌릴 것인가"를 각각 정의한다.

SKILL.md 뜯어보기

SKILL.md는 인제스트 스킬의 본체다. 프론트매터부터 보겠습니다.

---
name: wiki-ingest
description: "Ingest sources into the Obsidian wiki vault. Reads a source,
  extracts entities and concepts, creates or updates wiki pages,
  cross-references, and logs the operation. Supports files, URLs,
  and batch mode."
allowed-tools: Read Write Edit Glob Grep Bash WebFetch
---

allowed-tools에 WebFetch가 포함되어 있다는 점을 주목해야 한다. URL 인제스트 시 웹 페이지를 직접 가져오기 위한 것이다. 나머지 도구들은 파일시스템 조작에 쓰인다.

트리거 키워드도 description에 명시되어 있습니다: ingest, process this source, add this to the wiki, read and file this, batch ingest, ingest all of these, ingest this url. 이 중 하나라도 사용자 입력에 포함되면 wiki 오케스트레이터가 이 스킬로 라우팅한다.

Source Ingestion Workflow

단일 소스 인제스트의 전체 흐름은 11단계로 구성된다.

1. **Read** the source completely. Do not skim.
2. **Discuss** key takeaways with the user. Ask: "What should I emphasize?
   How granular?" Skip this if the user says "just ingest it."
3. **Create** source summary in `wiki/sources/`.
4. **Create or update** entity pages for every person, org, product,
   and repo mentioned. One page per entity.
5. **Create or update** concept pages for significant ideas and frameworks.
6. **Update** relevant domain page(s) and their `_index.md` sub-indexes.
7. **Update** `wiki/overview.md` if the big picture changed.
8. **Update** `wiki/index.md`. Add entries for all new pages.
9. **Update** `wiki/hot.md` with this ingest's context.
10. **Append** to `wiki/log.md` (new entries at the TOP).
11. **Check for contradictions.**

핵심은 1단계의 "Do not skim"과 2단계의 대화형 확인이다. Claude가 소스를 대충 훑고 요약하는 것을 명시적으로 금지한다. 2단계에서는 사용자에게 강조점과 세분화 수준을 물어보는데, "just ingest it"이라고 하면 건너뛸 수 있다. 이 설계는 자동화와 인간 개입 사이의 균형을 조절하는 장치다.

3~6단계가 실제 위키 페이지 생성/갱신이다. 소스 하나에서 엔티티, 개념, 도메인 페이지가 동시에 만들어지기 때문에 "1 소스 = 8-15 페이지"라는 수치가 나온다.

10단계의 로그 형식도 정해져 있습니다.

## [YYYY-MM-DD] ingest | Source Title
- Source: `.raw/articles/filename.md`
- Summary: [[Source Title]]
- Pages created: [[Page 1]], [[Page 2]]
- Pages updated: [[Page 3]], [[Page 4]]
- Key insight: One sentence on what is new.

새 엔트리가 파일 상단(TOP)에 추가된다는 점이 중요하다. 가장 최근 인제스트가 가장 먼저 보인다.

Delta Tracking — .manifest.json + Hash Deduplication

SKILL.md에서 가장 엔지니어링 밀도가 높은 섹션이다. 같은 소스를 두 번 인제스트하지 않기 위한 매커니즘이다.

{
  "sources": {
    ".raw/articles/article-slug-2026-04-08.md": {
      "hash": "abc123",
      "ingested_at": "2026-04-08",
      "pages_created": ["wiki/sources/article-slug.md",
                        "wiki/entities/Person.md"],
      "pages_updated": ["wiki/index.md"]
    }
  }
}

매니페스트는 .raw/.manifest.json에 위치한다. 소스 파일 경로를 키로, 해시값과 인제스트 시각, 생성/갱신된 페이지 목록을 값으로 저장한다.

인제스트 전 체크 로직은 다음과 같습니다.

1. Compute a hash: `md5sum [file] | cut -d' ' -f1`
   (or `sha256sum` on Linux).
2. Check if the path exists in `.manifest.json` with the same hash.
3. If hash matches, skip. Report:
   "Already ingested (unchanged). Use `force` to re-ingest."
4. If missing or hash differs, proceed with ingest.

md5sum으로 파일 해시를 계산하고, 매니페스트에 저장된 해시와 비교한다. 해시가 같으면 스킵이다. 이것이 Hash Based Deduplication의 전체 구현이다. 단순하지만 효과적인 전략이다 — 파일 내용이 바뀌지 않았으면 재처리할 이유가 없다.

강제 재인제스트가 필요한 경우도 고려한다. 사용자가 "force ingest" 또는 "re-ingest"라고 말하면 델타 체크를 건너뛴다.

인제스트 후에는 매니페스트를 갱신합니다.

1. Record {hash, ingested_at, pages_created, pages_updated}
   in `.manifest.json`.
2. Write the updated manifest back.

매니페스트에 pages_created와 pages_updated를 기록하는 것이 단순한 "처리 완료" 플래그와 다른 점이다. 나중에 어떤 소스가 어떤 위키 페이지에 영향을 미쳤는지 역추적할 수 있다. 이것은 사실상 소스-페이지 간 리니지(lineage) 기록이다.

URL Ingestion

파일뿐 아니라 URL도 인제스트할 수 있다. 트리거는 https://로 시작하는 입력이다.

1. **Fetch** the page using WebFetch.
2. **Clean** (optional): if `defuddle` is available
   (`which defuddle 2>/dev/null`), run `defuddle [url]`
   to strip ads, nav, and clutter.
   Typically saves 40-60% tokens.
3. **Derive slug** from the URL path (last segment, lowercased,
   spaces→hyphens, strip query strings).
4. **Save** to `.raw/articles/[slug]-[YYYY-MM-DD].md`
5. Proceed with **Single Source Ingest** starting at step 2.

2단계에서 defuddle이라는 CLI 도구를 사용한다. 광고, 네비게이션, 사이드바 등 불필요한 요소를 제거하여 토큰을 40-60% 절약하는 도구다. which defuddle 2>/dev/null로 설치 여부를 확인하고, 없으면 WebFetch 원본 출력을 그대로 사용한다. defuddle은 claude-obsidian의 별도 스킬로도 등록되어 있으며, 시리즈 7편에서 다룰 예정이다.

4단계에서 가져온 웹 페이지를 .raw/articles/에 저장한다는 점이 중요하다. URL 인제스트도 결국 파일 인제스트로 귀결된다. 저장된 파일에는 source_url과 fetched 날짜가 프론트매터에 기록된다.

---
source_url: [url]
fetched: [YYYY-MM-DD]
---

5단계에서 Single Source Ingest의 2단계부터 진행한다는 점도 확인해야 한다. 1단계(Read)는 이미 WebFetch에서 처리했으므로 건너뛰고, 사용자 확인 단계부터 시작한다.

Image Vision Ingestion

이미지 파일도 인제스트 대상이다. 트리거는 .png, .jpg, .jpeg, .gif, .webp, .svg, .avif 확장자다.

1. **Read** the image file using the Read tool.
   Claude can process images natively.
2. **Describe** the image contents: extract all text (OCR),
   identify key concepts, entities, diagrams, and data
   visible in the image.
3. **Save** the description to `.raw/images/[slug]-[YYYY-MM-DD].md`
4. Copy the image to `_attachments/images/[slug].[ext]`
   if it's not already in the vault.
5. Proceed with **Single Source Ingest** on the saved description file.

1단계에서 Claude의 멀티모달 능력을 직접 활용한다. Claude가 이미지를 네이티브로 처리할 수 있기 때문에 별도의 OCR 라이브러리가 필요 없다. 2단계에서 이미지에서 텍스트, 개념, 엔티티, 다이어그램, 데이터를 추출한다.

3단계에서 추출 결과를 .raw/images/에 마크다운 파일로 저장한다. 프론트매터에 source_type: image와 original_file이 기록된다. URL 인제스트와 마찬가지로, 이미지 인제스트도 결국 파일 인제스트로 정규화된다. 패턴이 일관적이다.

---
source_type: image
original_file: [original path]
fetched: YYYY-MM-DD
---
# Image: [slug]
 
[Full description of image contents, transcribed text,
 entities visible, etc.]

4단계에서 원본 이미지를 _attachments/images/에 복사한다. Obsidian에서 이미지를 볼트 내에서 참조할 수 있도록 하기 위함이다.

SKILL.md에 명시된 유스케이스는 다음과 같습니다: 화이트보드 사진, 스크린샷, 다이어그램, 인포그래픽, 문서 스캔.

Single Source vs Batch Ingest

단일 소스 인제스트와 배치 인제스트의 차이는 교차 참조 타이밍과 인덱스 갱신 횟수에 있다.

단일 소스에서는 11단계를 순차적으로 밟으며 인덱스, 핫 캐시, 로그를 매번 갱신한다.

배치 인제스트의 절차는 다릅니다.

1. List all files to process. Confirm with user before starting.
2. Process each source following the single ingest flow.
   Defer cross-referencing between sources until step 3.
3. After all sources: do a cross-reference pass.
   Look for connections between the newly ingested sources.
4. Update index, hot cache, and log once at the end
   (not per-source).
5. Report: "Processed N sources. Created X pages, updated Y pages.
   Here are the key connections I found."

핵심 차이점 두 가지:

1. 교차 참조 지연(Deferred Cross-referencing): 단일 인제스트에서는 각 소스가 처리될 때마다 기존 페이지와 교차 참조를 맺지만, 배치에서는 모든 소스 처리가 끝난 후 한꺼번에 교차 참조 패스를 돌린다. 이렇게 하면 소스 A와 소스 B 사이의 연결도 잡을 수 있다.

2. 인덱스 갱신 1회(Bulk Index Update): 단일 인제스트는 매번 index.md, hot.md, log.md를 갱신하지만, 배치에서는 마지막에 한 번만 갱신한다. 불필요한 파일 I/O를 줄이는 최적화다.

추가로 배치 인제스트는 "less interactive"하다고 명시하고 있다. 30개 이상의 소스를 처리할 때는 10개마다 사용자에게 체크인하도록 한다. 이것은 컨텍스트 윈도우 관리와 사용자 제어권 유지를 위한 설계다.

Cross-referencing

교차 참조는 인제스트의 핵심 산출물 중 하나다. 단일 인제스트에서는 3~6단계에서 엔티티와 개념 페이지를 생성/갱신하면서 위키링크([[Page Name]])로 연결한다. 배치 인제스트에서는 추가로 3단계의 "cross-reference pass"에서 새로 인제스트된 소스들 사이의 연결을 탐색한다.

wiki 오케스트레이터(1편)에서 설명한 "지식이 복리로 쌓인다(Knowledge compounds like interest)"가 실현되는 것이 바로 이 교차 참조 단계다. 소스가 늘어날수록 연결이 기하급수적으로 풍부해진다.

Contradiction Flagging

인제스트 워크플로우 11단계의 마지막이 모순 체크다. 새 소스의 주장이 기존 위키 페이지와 충돌하면, 양쪽 모두에 callout을 추가한다.

기존 페이지에 추가되는 callout:

> [!contradiction] Conflict with [[New Source]]
> [[Existing Page]] claims X. [[New Source]] says Y.
> Needs resolution. Check dates, context, and primary sources.

새 소스 요약에 추가되는 callout:

> [!contradiction] Contradicts [[Existing Page]]
> This source says Y, but existing wiki says X.
> See [[Existing Page]] for details.

설계 원칙은 명확하다: "Do not silently overwrite old claims. Flag and let the user decide." 새 정보가 들어왔다고 기존 정보를 조용히 덮어쓰지 않는다. 양쪽에 플래그를 달고 사용자가 판단하도록 한다. 이것은 LLM 기반 지식 관리에서 특히 중요한 원칙이다 — LLM이 어떤 정보가 "더 정확한지"를 자의적으로 판단하지 않게 한다.

SKILL.md에는 [!contradiction] callout이 커스텀 callout이라는 주석도 포함되어 있습니다.

> [!note] Custom callout dependency
> The `[!contradiction]` callout type used below is a
> **custom callout** defined in
> `.obsidian/snippets/vault-colors.css`
> (auto-installed by `/wiki` scaffold).

vault-colors.css가 적용되어 있으면 적갈색 배경에 경고 삼각형 아이콘으로 렌더링된다. CSS가 없어도 Obsidian의 기본 callout 스타일로 동작하므로 기능 자체는 문제없다.

Context Window Discipline

인제스트 과정에서 토큰 예산을 관리하는 규칙이다. 이 섹션은 짧지만 실전에서 가장 중요한 부분일 수 있다.

- Read `wiki/hot.md` first. If it contains the relevant context,
  don't re-read full pages.
- Read `wiki/index.md` to find existing pages
  before creating new ones.
- Read only 3-5 existing pages per ingest.
  If you need 10+, you are reading too broadly.
- Use PATCH for surgical edits. Never re-read an entire file
  just to update one field.
- Keep wiki pages short. 100-300 lines max.
  If a page grows beyond 300 lines, split it.

규칙을 하나씩 봅시다.

1. Hot Cache 우선: hot.md를 먼저 읽는다. 최근 문맥이 여기에 요약되어 있으므로, 전체 페이지를 다시 읽을 필요가 없는 경우가 많다. 1편에서 다룬 "~500단어 최근 문맥 요약"이 여기서 비용 절감 효과를 낸다.

2. 인덱스 먼저: 새 페이지를 만들기 전에 index.md를 읽어서 이미 존재하는 페이지가 있는지 확인한다. 중복 페이지 생성 방지.

3. 3-5 페이지 제한: 인제스트 한 번에 기존 페이지를 10개 이상 읽어야 한다면 너무 넓게 읽고 있다는 신호다. 이것은 Claude의 컨텍스트 윈도우를 효율적으로 사용하기 위한 하드 가이드라인이다.

4. PATCH 사용: 한 필드를 업데이트하려고 파일 전체를 다시 읽지 않는다. Edit 도구로 외과적 수정.

5. 페이지 크기 제한: 100-300줄 최대. 300줄을 넘으면 분할한다. 이 규칙은 인제스트뿐 아니라 위키 전체에 적용되는 위생 규칙이다.

agents/wiki-ingest.md 뜯어보기

agents 디렉토리의 wiki-ingest.md는 SKILL.md와 다른 역할을 한다. SKILL.md가 "인제스트 프로세스가 무엇인가"를 정의한다면, 이 에이전트 파일은 "여러 소스를 어떻게 병렬로 처리할 것인가"를 정의한다.

Parallel Batch Agent

프론트매터부터 확인합니다.

---
name: wiki-ingest
description: >
  Parallel batch ingestion agent for the Obsidian wiki vault.
  Dispatched when multiple sources need to be ingested
  simultaneously. Processes one source fully (read, extract,
  file entities and concepts, update index) then reports
  what was created and updated.
model: sonnet
maxTurns: 30
tools: Read, Write, Edit, Glob, Grep
---

SKILL.md와의 핵심 차이가 여기 있다.

• model: sonnet: 에이전트는 Sonnet 모델을 사용한다. 메인 스킬이 더 큰 모델에서 돌아가는 반면, 병렬 에이전트는 비용과 속도를 위해 더 작은 모델을 선택한다.
• maxTurns: 30: 에이전트 하나가 최대 30턴까지 동작할 수 있다. 소스 하나를 완전히 처리하기에 충분한 예산이다.
• tools에서 WebFetch와 Bash가 빠져 있다: 에이전트는 이미 .raw/에 저장된 파일을 처리하는 것이 목적이다. URL을 직접 가져올 필요가 없다.

사용 시나리오는 프론트매터의 example 블록에 명시되어 있습니다.

Context: User drops 5 transcript files into .raw/ and says
  "ingest all of these"
→ "I'll dispatch parallel agents to process all 5 sources
   simultaneously."
 
Context: User says "process everything in .raw/ that hasn't
  been ingested yet"
→ "I'll use wiki-ingest agents to handle each source
   in parallel."

오케스트레이터는 배치 인제스트를 받으면 소스 개수만큼 에이전트를 디스패치한다. 각 에이전트는 할당받은 소스 하나를 끝까지 처리하고 보고한다. 오케스트레이터는 모든 에이전트의 보고를 모아서 인덱스, 핫 캐시, 로그를 한 번에 갱신한다.

페이지 관리 (Source, Entity, Concept, Domain)

에이전트의 처리 프로세스는 10단계로 구성된다. SKILL.md의 11단계와 겹치는 부분이 있지만, 에이전트 특유의 제약 사항이 추가되어 있다.

1. Read the source file completely.
2. Read `wiki/index.md` to understand existing wiki pages
   and avoid duplication.
3. Read `wiki/hot.md` for recent context.
4. Create a source summary page in `wiki/sources/`.
   Use proper frontmatter.
5. For each significant person, org, product, or repo mentioned:
   check the index. Create or update the entity page
   in `wiki/entities/`.
6. For each significant concept, idea, or framework:
   check the index. Create or update the concept page
   in `wiki/concepts/`.
7. Update relevant domain pages.
   Add a brief mention and wikilink to new pages.
8. Update `wiki/entities/_index.md` and `wiki/concepts/_index.md`.
9. Check for contradictions with existing pages.
   Add `> [!contradiction]` callouts where needed.
10. Return a summary of what you created and updated.

각 단계가 담당하는 개념을 정리합니다.

• 2단계 — Index Cross-Reference Prevention: index.md를 먼저 읽어서 이미 존재하는 페이지를 파악한다. 중복 페이지 생성을 원천 차단하는 장치다.
• 3단계 — Hot Cache Reading: hot.md에서 최근 문맥을 파악한다. SKILL.md의 Context Window Discipline과 동일한 원칙이 에이전트 레벨에서도 적용된다.
• 4단계 — Source Summary Creation: wiki/sources/에 소스 요약 페이지를 생성한다. 프론트매터 스키마는 wiki 스킬의 references/frontmatter.md를 따른다.
• 5단계 — Entity Page Management: 사람, 조직, 제품, 리포지토리 각각에 대해 wiki/entities/에 개별 페이지를 생성하거나 갱신한다. "One page per entity" — 엔티티당 하나의 페이지라는 원칙.
• 6단계 — Concept Page Management: 아이디어, 패턴, 프레임워크에 대해 wiki/concepts/에 페이지를 생성하거나 갱신한다.
• 7단계 — Domain Page Updates: 관련 도메인 페이지에 새 페이지의 위키링크를 추가한다.
• 8단계 — Domain Index Updates: wiki/entities/_index.md와 wiki/concepts/_index.md 서브 인덱스를 갱신한다.
• 9단계 — Contradiction Detection and Flagging: SKILL.md에서 정의한 [!contradiction] callout을 에이전트 레벨에서도 동일하게 적용한다.

에이전트의 1-3단계(Read source, Read index, Read hot cache)가 SKILL.md의 Context Window Discipline을 정확히 따르고 있다는 점이 주목할 만하다. "hot.md 먼저 읽고, index.md로 중복 확인" 패턴이 에이전트에게도 내재화되어 있다.

Non-Modifying Constraints

에이전트가 하지 말아야 할 일을 명시적으로 정의한 섹션이다. 이것이 오케스트레이터와 에이전트 사이의 책임 분리를 정의한다.

- Modify anything in `.raw/`
- Update `wiki/index.md` or `wiki/log.md`
  (the orchestrator does this after all agents finish)
- Update `wiki/hot.md`
  (the orchestrator does this at the end)
- Create duplicate pages

SKILL.md에도 ".raw/ 수정 금지" 규칙이 있지만, 에이전트에는 추가 제약이 있다.

• index.md 수정 금지: 에이전트가 각자 인덱스를 수정하면 병렬 처리 시 충돌이 발생한다. 그래서 인덱스 갱신은 오케스트레이터가 모든 에이전트가 완료된 후 한 번에 처리한다.
• log.md 수정 금지: 같은 이유. 로그도 오케스트레이터가 일괄 추가한다.
• hot.md 수정 금지: 핫 캐시도 마찬가지. 오케스트레이터가 마지막에 한 번 갱신한다.

이 제약은 병렬 처리에서 발생할 수 있는 쓰기 충돌(write conflict)을 구조적으로 방지하는 설계다. 에이전트는 wiki/sources/, wiki/entities/, wiki/concepts/, wiki/domains/ 등 각자의 영역에만 쓰기 작업을 하고, 공유 자원(index.md, log.md, hot.md)은 오케스트레이터에게 위임한다.

SKILL.md의 "What Not to Do" 섹션과 비교하면 차이가 선명합니다.

- Do not modify anything in `.raw/`.
- Do not create duplicate pages.
  Always check the index and search before creating.
- Do not skip the log entry.
  Every ingest must be recorded.
- Do not skip the hot cache update.
  It is what keeps future sessions fast.

SKILL.md는 "로그와 핫 캐시를 반드시 갱신하라"고 하지만, 에이전트는 "로그와 핫 캐시를 갱신하지 마라"고 한다. 모순처럼 보이지만, 역할이 다르기 때문이다. SKILL.md는 단일 인제스트 전체 프로세스를 기술하고, 에이전트는 그중 일부(소스 처리 + 페이지 생성)만 담당한다.

Structured Report Output

에이전트가 처리를 완료하면 구조화된 보고서를 반환한다.

Source: [title]
Created: [[Page 1]], [[Page 2]], [[Page 3]]
Updated: [[Page 4]], [[Page 5]]
Contradictions: [[Page 6]] conflicts with [[Page 7]] on [topic]
Key insight: [one sentence on the most important new information]

다섯 개 필드로 구성된 고정 형식이다.

• Source: 처리한 소스의 제목.
• Created: 새로 생성한 위키 페이지 목록. 위키링크 형식.
• Updated: 기존에 있던 페이지 중 갱신한 목록.
• Contradictions: 모순이 발견된 경우 어떤 페이지 사이에서 어떤 주제로 충돌하는지 기록.
• Key insight: 가장 중요한 새 정보를 한 문장으로 요약.

이 보고서가 오케스트레이터로 전달되면, 오케스트레이터는 모든 에이전트의 보고서를 취합하여 index.md, log.md, hot.md를 일괄 갱신한다. SKILL.md 배치 인제스트의 5단계 보고("Processed N sources. Created X pages, updated Y pages.")가 이 보고서들의 합산 결과다.

다른 스킬과의 연결점

wiki-ingest는 단독으로 동작하지 않는다. claude-obsidian 플러그인의 다른 스킬들과 밀접하게 연결되어 있다.

• wiki (1편): 오케스트레이터. 사용자 입력에서 인제스트 의도를 감지하면 wiki-ingest로 라우팅한다. 인제스트가 끝나면 index.md, log.md, hot.md 갱신을 담당한다.
• wiki-query (4편 예정): 인제스트된 위키 페이지를 기반으로 질문에 답한다. 인제스트가 교차 참조와 핫 캐시를 잘 구축해놓아야 쿼리 성능이 올라간다.
• wiki-lint (5편 예정): 인제스트 후 위키의 건강 상태를 점검한다. 고아 페이지, 모순 미해결, 오래된 페이지 등을 잡아낸다. SKILL.md에서 "lint the wiki every 10-15 ingests"를 권장하는 이유다.
• defuddle (7편 예정): URL 인제스트의 2단계에서 사용된다. 웹 페이지의 불필요한 요소를 제거하여 토큰을 절약한다.
• save (6편 예정): 인제스트와 유사하지만, 대화 내용을 위키 노트로 저장하는 스킬이다. 인제스트가 외부 소스를 처리한다면, save는 Claude와의 대화 자체를 지식으로 축적한다.

wiki-ingest가 만드는 것은 단순한 문서 사본이 아니다. 엔티티로 분해하고, 개념으로 추상화하고, 도메인으로 분류하고, 교차 참조로 엮고, 모순을 표시하는 — 구조화된 지식 그래프다. 이 그래프가 풍부할수록 쿼리 품질이 올라가고, 린트가 잡아야 할 문제가 줄어들고, 위키 전체의 가치가 복리로 증가한다.