需要把对话、调试发现或修正沉淀为 Obsidian…

当用户说“save this”“/wiki-capture”等，或会话结束需自动保存发现时，把当前对话提炼为永久、结构化、可交叉链接的 wiki 笔记，并支持快速暂存与修正模式。

适用场景

解决思路

1. 在任何模式起草或重写自然语言 Markdown 前，读取并应用 `llm-wiki/SKILL.md` 中的 `Writing Profile Resolution` 部分；框架 schema、provenance、safety、operation-specific requirements 优先；`WRITING.md` 偏好仅适用于新起草或重写自然语言 Markdown，保留源内容和结构化记录。
2. 选择模式：默认 Full mode；当调用 `/wiki-capture --quick`，或说“quick capture”“capture this finding”“save this bug fix”“save this gotcha”“drop this to raw”“quick save to wiki”，或由 session-end Stop hook 自动触发时进入 Quick Mode；当调用 `--correction` 时进入 Correction Mode。
3. Quick Mode 遵守速度契约：仅内联执行；不使用 subagents；不使用 QMD；不写 manifest、`index.md`、`log.md`、`hot.md`；目标 <60 秒；后续通过 `/wiki-ingest` 提升。
4. Quick Mode 步骤 1：按 `llm-wiki/SKILL.md` 的 Config Resolution Protocol 解析配置，获取 `OBSIDIAN_VAULT_PATH` 和 `OBSIDIAN_RAW_DIR`（默认 `$OBSIDIAN_VAULT_PATH/_raw`）；确保 `$OBSIDIAN_RAW_DIR` 存在，不存在则创建。
5. Capture 不独立重新解释 validator schema 输入；当 `OBSIDIAN_ALLOWED_LIFECYCLES`、`OBSIDIAN_ALLOWED_RELATIONSHIP_TYPES`、`OBSIDIAN_REQUIRED_TRUST_FIELDS` 或 `OBSIDIAN_SCHEMA_SOURCE` 存在时，保留给下游 lint/trust consumer：CLI 值优先于环境/配置值，环境/配置值优先于框架默认值，显式空白或仅空白值 fail closed；省略变量则使用默认值。
6. Quick Mode 步骤 2：提取前做 KEEP/SKIP 门控；若会话纯对话（规划、Q&A、解释）且无实现、无错误/调试/问题解决、无意外或未文档化内容、所有发现都显然来自文档，则 SKIP 并输出“Nothing worth capturing in this session.”。
7. 若有任一情况则 KEEP：通过调查找到修复或 workaround；确认非显而易见库/API/框架行为（边缘情况、未文档化约束、耗时 gotcha）；调试会话达到具体结论；出现可复用模式。
8. 由 Stop hook 调用时倾向 SKIP，仅在明确证据时 KEEP；手动调用时倾向 KEEP。
9. Quick Mode 步骤 3：扫描可复用发现：非显而易见的 bug 和根因、框架/库 gotcha、意外 API 行为、调查出的 workaround、环境/工具链怪癖、调试模式；跳过 PM 更新、已在 `CLAUDE.md` 的配置、无结论来回、文档中显然内容、寒暄；没有实质发现就说明并停止。
10. Quick Mode 步骤 4：按主题聚类，每个主题簇一个 `_raw/` 文件，不是每个发现一个文件；文件名用 kebab-case slug，如 `swift-actor-reentrancy`、`nextjs-hydration-mismatch`。
11. Quick Mode 步骤 5：从仓库名、文件路径、框架提及、错误消息推断项目上下文；使用能可靠推断的最具体名称；否则用 `null`。
12. Quick Mode 步骤 6：为每个簇写 `$OBSIDIAN_RAW_DIR/<ISO-date>-<slug>.md`；读取 `references/RAW-FORMAT.md` 获取完整 frontmatter 规范、finding-block 正文结构、provenance/confidence 校准。
13. Quick Mode 每个簇字段：`title`；`tags`（taxonomy 中 2–4 个）；`summary`（≤200 字符）；`project`（推断或 `null`）；`base_confidence`（0.6 讨论过 → 0.75 已应用修复 → 0.9 测试确认）；`provenance.extracted`/`provenance.inferred`（和为 1.0）；`lifecycle_changed`（今天）；`sources`（格式 `<project> session (<YYYY-MM-DD>)`）。
14. Quick Mode 步骤 7：确认，列出 staged 文件并告诉用户运行 `/wiki-ingest` 提升；示例输出：`Staged to _raw/:`、` _raw/2026-05-27-swift-actor-reentrancy.md — “Actor reentrancy causes deadlock in async forEach”`、`Run /wiki-ingest to promote these to full wiki pages.`。
15. Quick Mode 明确不写 manifest、`index.md`、`log.md`、`hot.md`，不刷新 QMD；提升由 `/wiki-ingest` 处理；到此停止，不运行 Full mode 步骤。
16. Correction Mode：当用户或更强权威纠正来自不可变对话、工具结果或其他原始源的 claim 时使用；绝不编辑或复制原始源；解析配置，读取 vault `AGENTS.md`，若已有派生页面拥有该 claim 则更新之，否则创建符合 owner 要求的最小派生修正页面。
17. Correction Mode 记录恰好一个原子 claim pair；`speaker_type` 是语义字段，必须独立于序列化消息 `role` 评估（工具结果可能序列化为 `role=user`）；不要包含原始 transcript 摘录。
18. Correction Mode 使用字段：`correction_id`、`source_locator`、`source_text_sha256`、`serialized_role`、`speaker_type`、`original_claim.subject`、`original_claim.assertion`、`corrected_claim.subject`、`corrected_claim.assertion`、`authority_class`、`verification_state`、`asserted_at`、`effective_at`、`as_of`、`supersedes`、`consumer_propagation.kw`、`consumer_propagation.ob`、`consumer_propagation.requirements`、`consumer_propagation.code`、`consumer_propagation.tests`、`consumer_propagation.ai_memory`、`corrected_at`；`consumer_propagation` 值为 `open | not_applicable | complete`。
19. Correction Mode 在任何派生写入前，直接从不可变源计算 `source_pre_sha256`，要求其等于 `source_text_sha256`。
20. Correction Mode 写入 correction 并更新派生消费者后，从同一 locator 重新计算 `source_post_sha256`。
21. Correction Mode 除非 `source_pre_sha256 == source_post_sha256 == source_text_sha256`，否则中止并报告 immutability violation；即使 correction 写入成功，此验证也是强制。
22. Correction Mode 写完派生 correction 后，通过 `.manifest.json` 将不可变源链接到创建/更新页面；只将 correction ID 和受影响页面计数追加到 `log.md`；将原子 correction 独立传播到每个 consumer。
23. Correction Mode 仅在验证该 consumer 后标记其为 `complete`；不要将混合结果折叠成单一聚合状态；确保 secrets、raw excerpts、source copies 不出现在 correction record 中。
24. Full mode 之前：按 Config Resolution Protocol 解析配置（内联 `@name` override → 向上遍历 CWD 找 `.env` → 全局配置 → 提示 setup），获取 `OBSIDIAN_VAULT_PATH` 和 `OBSIDIAN_LINK_FORMAT`（默认 `wikilink`）。
25. Full mode 之前：读取 `$OBSIDIAN_VAULT_PATH/index.md` 了解现有 wiki 内容，避免重复。
26. Full mode 之前：如存在，读取 `$OBSIDIAN_VAULT_PATH/hot.md` 获取最近活动上下文。
27. 在 Step 5 写内部链接时，使用 `llm-wiki/SKILL.md` 的 Link Format 部分和 `OBSIDIAN_LINK_FORMAT` 值。
28. Full mode Step 1：扫描对话，判断 3 个月后无记忆时哪些知识有价值；值得保留：做出的决定及原因、分析/框架/心智模型、技术发现/模式/流程、综合理解、费力得到的清晰概念解释、对话中讨论的外部来源关键事实。
29. Full mode Step 1 跳过：物流、日程、寒暄；未得到结论的探索性来回；已在 wiki 中的内容；没有实质发现就告知用户并停止。
30. Full mode Step 2：分类为五种类型之一，决定目标文件夹和语气：`synthesis`（多步分析或需要推理的问题答案）→ `synthesis/`；`concept`（定义、框架、心智模型，某物是什么）→ `concepts/`；`source`（外部文档/文章/资源摘要）→ `references/`；`decision`（战略/架构/设计选择及理由）→ `synthesis/`；`session`（对话跨多主题时的完整讨论摘要）→ `journal/`。
31. Full mode Step 2：如果内容明显属于特定项目（从上下文或用户提及检测），放到 `projects/<project-name>/<category>/`。
32. Full mode Step 3：不要把对话写成摘要；用陈述性现在时写知识本身。不要写“The user asked about X and Claude explained that...”，要写“X works by...”；不要写“We decided to use Y because...”，要写“Y is preferred over Z because [reason]. [^[inferred] if the rationale was implied, not stated explicitly]”。
33. Full mode Step 3：按 `llm-wiki` 应用 provenance 标记：Extracted 明确陈述（无标记）；Inferred 从对话泛化/综合 → `^[inferred]`；Ambiguous 有争议/不确定/矛盾 → `^[ambiguous]`。
34. Full mode Step 4：生成清晰描述性标题；slug 化：小写、单词用连字符分隔、最多 50 字符、避免在 slug 中放日期（`created` 在 frontmatter 中）。
35. Full mode Step 5：在目标路径创建文件，带必需 frontmatter：`title`、`category`（`synthesis|concepts|references|journal|skills`）、`tags`（taxonomy 中 2–5 个领域标签）、`sources`（`conversation:<ISO-date>`）、`created`、`updated`、`summary`（1–2 句，≤200 字符，回答此页承载什么知识）、`provenance`（`extracted`/`inferred`/`ambiguous`）、`base_confidence`（如 0.42）、`lifecycle`（`draft`）、`lifecycle_changed`（今天 ISO 日期）。
36. Full mode Step 5：若类型为 `synthesis`/`decision`，正文结构：`# Title`、`## Context`（问题或问题背景）、`## Finding / Decision`（核心知识或结论）、`## Reasoning`（为什么）、`## Implications`（后续影响、注意点、下一步、权衡）、`## Related`（[[wikilinks]] 到相关页面）。
37. Full mode Step 5：若类型为 `concept`，正文结构：`# Title`、一句话定义、`## What It Is`、`## How It Works`、`## When to Use`、`## Related`。
38. Full mode Step 5：若类型为 `source`，正文结构：`# Title`、`> Source: <title or URL>`、`## What It Covers`、`## Key Points`（带 provenance 标记的项目符号 claim）、`## Open Questions`（没有则省略）、`## Related`。
39. Full mode Step 5：若类型为 `session`，正文结构：`# Title`、`*Session captured: <date>*`、`## Topics Covered`（简短列表）、`## Key Takeaways`（3–5 个最重要内容）、`## Decisions Made`（明确决定及理由）、`## Open Questions`（未解决内容）、`## Related`。
40. Full mode Step 5：每个 note 必须链接至少 2 个现有 wiki 页面；写前搜索 `index.md`；如果相关页面少于 2 个，为最重要的引用概念创建最小 stubs。
41. Full mode Step 6：更新 `index.md`，在对应分类 section 下添加新页面。
42. Full mode Step 6：更新 `log.md`，追加 `- [TIMESTAMP] CAPTURE type=<type> page="<path>" title="<title>"`。
43. Full mode Step 6：更新 `hot.md` 的 Recent Activity 为刚捕获内容；若 note 引入值得标记的内容，更新 Key Takeaways；更新 `updated` 时间戳。
44. Full mode Step 7：向用户确认保存路径和标题，如 `Saved to: projects/<name>/synthesis/<slug>.md`、`Title: <Title>`、`Type: synthesis`。
45. Full mode 质量检查：内容重写为陈述性知识而不是聊天 transcript；类型分类正确；目标路径在正确文件夹；frontmatter 完整含 title、category、tags、sources、summary、provenance；至少 2 个 wikilinks 到现有页面；`index.md`、`log.md`、`hot.md` 已更新；已向用户确认保存路径。
46. QMD Refresh：QMD 是搜索索引不是 source of truth；若 `$QMD_WIKI_COLLECTION` 为空或未设置则跳过；仅在本技能写入或重写 vault markdown 后运行；若 QMD 刷新失败，不回滚 vault 更改；单独报告 QMD 状态。
47. QMD Refresh：若设置了 `$QMD_CLI` 用它，否则用 `qmd`；运行 `${QMD_CLI:-qmd} update`。
48. QMD Refresh：如果输出说需要 vectors 或 embeddings 可能过期，运行 `${QMD_CLI:-qmd} embed`。
49. QMD Refresh：用 `${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"` 验证 collection；或当知道具体页面路径时用 `${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5`。
50. QMD Refresh：记录状态之一：`QMD refreshed: update + embed + verified`、`QMD refreshed: update only + verified`、`QMD skipped: QMD_WIKI_COLLECTION unset`、`QMD skipped: qmd CLI unavailable`、`QMD failed: <short error summary>`。

适用边界 · 注意事项

• 纯闲聊、规划、问答、解释，且没有实现、错误调试、具体结论、未文档化发现或可复用模式时，Quick Mode 应 SKIP，不要强行捕获。
• 内容已存在于 wiki 或 `CLAUDE.md`，或只是物流、日程、寒暄、无结论的探索性来回时，不应保存。
• 不要用它编辑、复制或改写不可变原始对话/工具结果/原始源；Correction Mode 只创建/更新派生修正记录并传播到消费者。