claude-obsidian 스킬 뜯어보기 (6): save

이 스킬이 하는 일

save는 대화에서 가치 있는 내용을 추출해 위키 페이지로 저장하는 스킬이다. Claude와 대화하면서 얻은 인사이트, 분석 결과, 의사결정이 채팅 히스토리 속에 묻히지 않도록 영구적인 위키 노트로 변환한다. SKILL.md의 첫 문단이 이 철학을 요약한다.

Good answers and insights shouldn't disappear into chat history.
This skill takes what was just discussed and files it as a permanent wiki page.
 
The wiki compounds. Save often.

"The wiki compounds"라는 한 줄이 핵심이다. wiki-ingest가 외부 소스를 위키에 넣는 "입력 파이프라인"이라면, save는 대화 자체를 소스로 취급하는 "내부 파이프라인"이다. 인제스트가 문서를 합성하고, 쿼리가 지식을 꺼내 쓰고, save가 그 과정에서 생긴 새로운 지식을 다시 위키에 넣는다. 이 순환이 지식의 복리 성장을 만든다.

이 글에서는 스킬 본체인 SKILL.md와 커맨드 정의인 commands/save.md 두 파일에 담긴 16개 개념을 코드 레벨에서 분석한다.

파일 구조

claude-obsidian/
├── skills/save/
│   └── SKILL.md        # 스킬 본체 — 노트 타입, 워크플로우, 작성 스타일
└── commands/
    └── save.md         # 커맨드 정의 — /save 변형, vault 체크, 중복 확인

wiki-query와 마찬가지로 2파일 구성이다. SKILL.md가 "어떤 내용을 어떤 형식으로 저장할 것인가"를 정의하고, commands/save.md가 "사용자가 어떤 형태로 트리거할 수 있는가"를 정의한다. 레퍼런스 파일이 별도로 없는 것은, 저장 대상이 외부 문서가 아니라 현재 대화이기 때문에 복잡한 파싱 파이프라인이 필요 없기 때문이다.

SKILL.md 뜯어보기

SKILL.md의 프론트매터부터 살펴보겠습니다.

---
name: save
description: >
  Save the current conversation, answer, or insight into the Obsidian wiki vault
  as a structured note. Analyzes the chat, determines the right note type, creates
  frontmatter, files it in the correct wiki folder, and updates index, log, and
  hot cache.
  Triggers on: "save this", "save that answer", "/save", "file this",
  "save to wiki", "save this session", "file this conversation", "keep this",
  "save this analysis", "add this to the wiki".
allowed-tools: Read Write Edit Glob Grep
---

allowed-tools에 WebFetch가 없다는 점이 wiki-ingest와의 결정적 차이다. save 스킬은 외부 리소스를 가져올 필요가 없다. 대화 내용은 이미 컨텍스트에 있기 때문에, 파일시스템 읽기/쓰기만으로 충분하다.

트리거 키워드도 다양하게 정의되어 있다: save this, file this, keep this, add this to the wiki 등. 자연어 변형을 폭넓게 커버해서 사용자가 정확한 명령어를 외울 필요가 없다.

Conversation Filing

save 스킬의 근본적인 역할은 대화를 위키 노트로 변환하는 것이다. SKILL.md가 이를 "conversation filing"이라고 표현한다.

Good answers and insights shouldn't disappear into chat history.
This skill takes what was just discussed and files it as a permanent wiki page.

여기서 "filing"이라는 단어 선택이 의도적이다. 단순히 "저장"이 아니라 "분류하여 정리한다"는 의미다. 대화 내용을 그대로 복사하는 게 아니라, 타입을 결정하고, 폴더를 선택하고, 프론트매터를 생성하고, 인덱스를 갱신하는 전체 프로세스가 "filing"이다.

Note Type Decision Tree --- 5가지 타입

save 스킬의 첫 번째 핵심 결정은 노트 타입이다. SKILL.md는 5가지 타입을 정의한다.

| Type | Folder | Use when |
|------|--------|---------|
| synthesis | wiki/questions/ | Multi-step analysis, comparison, or answer to a specific question |
| concept | wiki/concepts/ | Explaining or defining an idea, pattern, or framework |
| source | wiki/sources/ | Summary of external material discussed in the session |
| decision | wiki/meta/ | Architectural, project, or strategic decision that was made |
| session | wiki/meta/ | Full session summary: captures everything discussed |

설계 포인트가 세 가지 있다.

1. 타입과 폴더가 1:1 매핑되지 않는다. decision과 session은 둘 다 wiki/meta/에 들어간다. 메타 정보라는 공통 성격으로 묶인 것이다. 반면 synthesis는 wiki/questions/에 배치되는데, 질문에 대한 분석 결과이기 때문이다.
2. 기본값이 synthesis다. "When in doubt, use synthesis"라고 명시한다. 대화에서 나오는 대부분의 가치 있는 내용은 질문에 대한 분석이나 비교이기 때문이다.
3. 사용자 오버라이드가 우선한다. "If the user specifies a type, use that"이 테이블 바로 아래에 온다. 스킬의 자동 판단보다 사용자의 명시적 지정이 우선한다.

If the user specifies a type, use that. If not, pick the best fit
based on the content. When in doubt, use `synthesis`.

이 결정 트리는 commands/save.md의 /save concept [name], /save decision [name] 같은 명시적 타입 지정 커맨드와 연동된다. 커맨드에서 타입을 지정하면 이 테이블의 자동 판단을 건너뛴다.

Declarative Present Tense Style

save 스킬이 생성하는 위키 노트의 문체 규칙이 명시되어 있다.

- Declarative, present tense. Write the knowledge, not the conversation.
- Not: "The user asked about X and Claude explained..."
- Yes: "X works by doing Y. The key insight is Z."

"Write the knowledge, not the conversation"이 핵심 원칙이다. 대화를 기록하는 것이 아니라, 대화에서 추출한 지식 자체를 기록한다. 이 문체 규칙이 없으면 save 스킬은 채팅 로그 아카이버로 전락한다.

구체적인 나쁜 예와 좋은 예가 주어진 것도 중요하다. "The user asked about X and Claude explained..."는 대화 기록이고, "X works by doing Y"는 지식이다. 미래의 독자(혹은 미래의 Claude 세션)가 이 노트를 읽을 때, 과거 대화의 맥락을 알 필요 없이 내용을 이해할 수 있어야 한다.

Comprehensive Cold-Reading

선언적 현재형 문체와 짝을 이루는 원칙이 cold-reading 충분성이다.

- Include all relevant context. Future sessions should be able to
  read this page cold.

"Read this page cold"는 이전 대화의 맥락 없이, 이 페이지만 읽고도 내용을 완전히 이해할 수 있어야 한다는 뜻이다. 이것이 save 스킬이 단순 복사가 아닌 이유다. 대화에서는 암묵적인 컨텍스트(이전 질문, 공유된 코드, 진행 중인 작업)가 많지만, 위키 노트에는 그 모든 것이 명시적으로 들어가야 한다.

이 원칙은 wiki-query의 동작과 직결된다. wiki-query가 위키 페이지를 읽어서 답변할 때, 해당 페이지가 cold-reading에 충분하지 않으면 정확한 답변을 할 수 없다. save 스킬이 노트를 잘 만들어야 query 스킬이 제대로 작동한다.

Automated Wikilinks

save 스킬은 저장하는 노트에 위키링크를 자동으로 삽입한다.

- Link every mentioned concept, entity, or wiki page with wikilinks.
- Cite sources where applicable: `(Source: [[Page]])`.

"Link every mentioned concept, entity, or wiki page"라는 규칙은 철저하다. 대화에서 언급된 모든 개념, 엔티티, 위키 페이지를 [[wikilink]] 형태로 연결해야 한다. 이것이 Obsidian의 그래프 뷰에서 지식 네트워크가 자연스럽게 형성되는 메커니즘이다.

소스 인용도 (Source: [[Page]]) 형식으로 표준화되어 있다. 대화에서 특정 소스를 참조했다면, 저장되는 노트에 그 출처가 wikilink로 남는다. 이후 해당 소스 페이지에서 백링크를 통해 이 노트를 역추적할 수 있다.

Frontmatter with Type-Specific Fields

save 스킬은 타입에 따라 다른 프론트매터 필드를 생성한다. 기본 템플릿은 이렇다.

---
type: <synthesis|concept|source|decision|session>
title: "Note Title"
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags:
  - <relevant-tag>
status: developing
related:
  - "[[Any Wiki Page Mentioned]]"
sources:
  - "[[.raw/source-if-applicable.md]]"
---

기본 필드는 7개다: type, title, created, updated, tags, status, related, sources. 여기에 타입별 추가 필드가 붙는다.

question 타입(synthesis)의 추가 필드:

question: "The original query as asked."
answer_quality: solid

decision 타입의 추가 필드:

decision_date: YYYY-MM-DD
status: active

설계 포인트가 두 가지 있다.

1. status: developing이 기본값이다. 새로 저장된 노트는 항상 "developing" 상태에서 시작한다. 위키 전체의 status 라이프사이클(developing → solid → verified)과 일관된다. save 스킬이 만든 노트가 곧바로 "verified"가 되지 않는다는 것은, 지식이 시간을 두고 검증되어야 한다는 설계 철학의 반영이다.
2. related 필드가 wikilink 형태다. "[[Any Wiki Page Mentioned]]"처럼 따옴표로 감싼 wikilink다. 이것은 wiki 스킬의 quoted-wikilinks-in-yaml 패턴과 동일하다. YAML에서 대괄호가 배열로 해석되지 않도록 따옴표가 필수다.

Save vs Skip Heuristics

save 스킬은 무엇을 저장할지, 무엇을 건너뛸지 명확한 기준을 제시한다.

저장해야 하는 것:

Save:
- Non-obvious insights or synthesis
- Decisions with rationale
- Analyses that took significant effort
- Comparisons that are likely to be referenced again
- Research findings

건너뛰어야 하는 것:

Skip:
- Mechanical Q&A (lookup questions with obvious answers)
- Setup steps already documented elsewhere
- Temporary debugging sessions with no lasting insight
- Anything already in the wiki

이 휴리스틱의 핵심 기준은 **"비자명성(non-obvious)"**과 **"재참조 가능성"**이다. 구글링으로 바로 나오는 답변은 저장할 가치가 없다. 반면 여러 소스를 교차 분석한 결과, 의사결정의 근거, 나중에 다시 참조할 비교 분석은 저장 대상이다.

"Temporary debugging sessions with no lasting insight"도 흥미로운 기준이다. 디버깅 세션 자체가 아니라, 그 세션에서 지속적인 인사이트가 나왔는지가 판단 기준이다. "이 버그는 이렇게 고쳤다"는 skip이지만, "이 버그의 근본 원인은 아키텍처의 이러한 결함이다"는 save 대상이다.

Duplicate Prevention

save 스킬은 중복 생성을 방지하는 규칙을 갖고 있다.

If it's already in the wiki, update the existing page instead of
creating a duplicate.

이 한 줄이 Save vs Skip 섹션의 마지막에 온다. "Anything already in the wiki"가 Skip 목록에 있으면서, 동시에 "update the existing page"라는 대안을 제시한다. 단순히 건너뛰는 것이 아니라, 기존 페이지를 갱신하라는 것이다.

이 규칙은 commands/save.md의 중복 확인 로직과 연동된다. 커맨드 레벨에서 같은 이름의 페이지가 있는지 먼저 확인하고, 있으면 업데이트를 제안한다.

Related Pages Linking

워크플로우의 6단계에서 관련 페이지 수집이 일어난다.

6. **Collect links**: identify any wiki pages mentioned in the conversation.
   Add them to `related` in frontmatter.

이것은 본문의 wikilink(Automated Wikilinks)와 별개의 메커니즘이다. 본문에서는 인라인 wikilink로 개념을 연결하고, 프론트매터의 related 필드에는 이 노트와 관련된 모든 페이지의 목록을 별도로 기록한다. 이중 연결이 의도적인 것은, 프론트매터의 related 필드가 Obsidian의 Dataview 쿼리나 Bases에서 구조화된 데이터로 활용되기 때문이다.

Index and Log Updates

save 워크플로우의 7~9단계는 3개 파일을 연쇄적으로 갱신한다.

7. **Update** `wiki/index.md`. Add the new entry at the top of the relevant section.
8. **Append** to `wiki/log.md`. New entry at the TOP:
   ## [YYYY-MM-DD] save | Note Title
   - Type: [note type]
   - Location: wiki/[folder]/Note Title.md
   - From: conversation on [brief topic description]
9. **Update** `wiki/hot.md` to reflect the new addition.

세 파일의 역할이 각각 다르다.

• index.md: 전체 위키의 카탈로그. 새 노트를 "relevant section의 최상단"에 추가한다.
• log.md: 시간순 작업 로그. 날짜, 스킬명(save), 노트 타입, 위치, 원본 대화 주제를 기록한다. wiki-ingest도 같은 log.md에 기록하므로, 인제스트와 세이브 이력이 한 곳에 합쳐진다.
• hot.md: 최근 컨텍스트 캐시. wiki-query의 Quick 모드가 이 파일을 먼저 읽기 때문에, 방금 저장한 내용이 즉시 조회 가능해진다.

log.md의 포맷이 구체적으로 명시되어 있다는 점이 중요하다. ## [YYYY-MM-DD] save | Note Title 형태로, 어떤 스킬이 어떤 노트를 만들었는지 한눈에 파악할 수 있다. From: conversation on [brief topic description]은 이 노트가 어떤 대화에서 나왔는지 역추적할 수 있게 한다.

워크플로우의 마지막 10단계는 사용자 확인이다.

10. **Confirm**: "Saved as [[Note Title]] in wiki/[folder]/."

wikilink 형태로 확인 메시지를 보여주므로, Obsidian에서 바로 클릭하여 해당 노트로 이동할 수 있다.

commands/save.md 뜯어보기

commands/save.md는 /save 커맨드의 사용자 인터페이스를 정의한다. SKILL.md가 "어떻게 처리할 것인가"라면, 이 파일은 "어떻게 호출할 것인가"다.

---
description: Save the current conversation or a specific insight
  into the wiki vault as a structured note.
---

본문은 짧다.

Read the `save` skill. Then run the save workflow for this conversation.

이 한 줄이 실행 흐름을 정의한다. 커맨드가 트리거되면 먼저 SKILL.md를 읽고, 그 워크플로우를 실행한다. 커맨드 파일 자체는 라우터 역할만 하고, 실제 로직은 SKILL.md에 있다.

/save 커맨드 변형 (name, session, type)

커맨드 파일은 5가지 사용법을 정의한다.

Usage:
- `/save` — analyze the full conversation and save the most valuable content
- `/save [name]` — save with a specific note title (skip the naming question)
- `/save session` — save a complete session summary
- `/save concept [name]` — explicitly save as a concept page
- `/save decision [name]` — explicitly save as a decision record

각 변형의 역할을 분석하면 다음과 같다.

1. /save (인자 없음): 대화 전체를 분석해서 가장 가치 있는 내용을 자동 추출한다. 이름도 Claude가 제안한다. SKILL.md 워크플로우 2단계의 "What should I call this note?" 질문이 이 경우에 작동한다.
2. /save [name]: 노트 이름을 미리 지정한다. 이름 질문을 건너뛰므로 한 단계가 줄어든다.
3. /save session: 전체 세션 요약을 저장한다. SKILL.md의 session 타입이 강제 선택된다. 긴 대화에서 모든 논의를 하나의 노트로 남기고 싶을 때 사용한다.
4. /save concept [name]: 타입을 concept으로 명시한다. SKILL.md의 "If the user specifies a type, use that" 규칙이 적용되어, 자동 타입 판단을 건너뛴다.
5. /save decision [name]: 타입을 decision으로 명시한다. 아키텍처 결정, 프로젝트 전략 결정을 기록할 때 사용한다.

이 변형 구조의 설계 원칙은 점진적 구체화다. /save만으로도 동작하고, 이름이나 타입을 추가하면 더 정확하게 동작한다. 사용자가 모든 옵션을 알 필요 없이, 가장 간단한 형태부터 시작할 수 있다.

Vault Existence Check

save 커맨드에는 vault가 존재하지 않을 때의 가드가 있다.

If no vault is set up yet, say: "No wiki vault found.
Run /wiki first to set one up."

이것은 스킬 간 의존성을 처리하는 패턴이다. save 스킬은 wiki 스킬이 만든 vault 구조(wiki/index.md, wiki/log.md, wiki/hot.md 등)에 의존한다. vault가 없으면 저장할 곳이 없으므로, /wiki 스킬로 먼저 설정하라고 안내한다.

이 가드는 사용자 경험 측면에서도 중요하다. vault 없이 /save를 실행하면 파일 쓰기가 실패하면서 에러가 발생할 수 있다. 그 전에 친절한 메시지로 다음 행동을 안내하는 것이 방어적 설계다.

커맨드 파일의 마지막 규칙은 save 전 중복 확인이다.

Check if a page with the same name already exists. If it does,
offer to update it instead of creating a duplicate.

SKILL.md의 "update the existing page instead of creating a duplicate"와 같은 원칙을 커맨드 레벨에서 재확인한다. 실행 순서상 커맨드가 먼저 트리거되므로, 이 체크가 SKILL.md의 워크플로우보다 먼저 돌아간다. 같은 이름의 페이지가 이미 있으면 "업데이트할까요?"라고 물어본다.

이 이중 방어(SKILL.md의 skip 규칙 + commands/save.md의 사전 체크)는 위키에 중복 페이지가 쌓이는 것을 방지한다. 지식 베이스에서 같은 주제의 페이지가 2개 이상 존재하면 어떤 것이 최신인지 알 수 없게 되므로, 중복 방지는 위키 품질 유지의 핵심이다.

다른 스킬과의 연결점

save 스킬은 wiki 생태계의 모든 스킬과 연결된다.

• wiki (오케스트레이터): save의 트리거 키워드를 감지하면 이 스킬로 라우팅한다. vault scaffold 구조(wiki/questions/, wiki/concepts/, wiki/meta/)를 save가 그대로 사용한다.
• wiki-ingest: 둘 다 index.md, log.md, hot.md를 갱신한다. 차이점은 ingest의 입력이 외부 소스이고, save의 입력이 현재 대화라는 것이다. log.md에서 ingest | Note Title과 save | Note Title로 구분된다.
• wiki-query: save가 만든 노트를 query가 조회한다. save가 hot.md를 갱신하면, query의 Quick 모드에서 즉시 접근 가능하다. save의 cold-reading 원칙이 지켜져야 query가 정확한 답변을 생성할 수 있다.
• wiki-lint: save가 만든 노트가 lint의 점검 대상이 된다. 프론트매터 필수 필드 누락, 고아 페이지, wikilink 미연결 등을 lint가 잡아낸다.
• obsidian-markdown: save가 생성하는 wikilink([[Page]]), 프론트매터(YAML), 태그 문법이 모두 obsidian-markdown 스킬이 정의한 규약을 따른다.

save 스킬은 작지만, 위키의 지식 순환을 완성하는 마지막 고리다. 외부 소스 인제스트, 질의 응답, 대화 저장이 순환하면서 위키가 자라난다.