wiki-capture

Wiki Capture — 会話から Wiki ノートへ

現在の会話から知識を取り出し、永続的な Wiki ノートとして保存します。目的は、発言の要約ではなく、知識そのものという 要旨 を抽出することです。

執筆プロファイル： どのモードでも、自然言語の Markdown を新規作成または書き換える前に、llm-wiki/SKILL.md の Writing Profile Resolution セクションを読み、適用してください。フレームワークのスキーマ、出典、安全性、操作固有の要件が優先されます。 WRITING.md の設定は、新規作成または書き換えた自然言語の Markdown にのみ適用されます。ソースの内容と構造化レコードはそのまま維持してください。

このスキルには 3 つのモードがあります。

• フルモード（デフォルト） — 内容を分類し、適切なカテゴリに相互リンク付きの完成した Wiki ページを直接作成します。このドキュメントの続き（ステップ 1～7）に従ってください。
• クイックモード（--quick） — 手間をかけずに一時保存します。60 秒以内に _raw/ へ調査結果を保存します。マニフェスト、インデックス、ログ、QMD への書き込みは行いません。セッション中の記録やセッション終了時の Stop フックで使用します。以下を参照して終了してください。フルモードの手順は実行しないでください。
• 修正モード（--correction） — 不変の会話／ソースには手を加えず、1 つの修正事項を派生知識として記録します。以下のテンプレートを使用し、派生した利用先と追跡リンクのみを更新してください。

クイックモード（--quick）

/wiki-capture --quick として呼び出された場合、「quick capture」「capture this finding」「save this bug fix」「save this gotcha」「drop this to raw」「quick save to wiki」によって呼び出された場合、またはセッション終了時の Stop フックによって自動的に呼び出された場合に実行します。

速度に関する契約： インライン処理のみです。サブエージェントは使用しません。QMD は使用しません。マニフェスト／index.md／log.md／hot.md への書き込みは行いません。目標時間：60 秒未満。通常の Wiki ページへの昇格は、後で /wiki-ingest によって行います。

1. 設定を解決する（llm-wiki/SKILL.md の Config Resolution Protocol）：OBSIDIAN_VAULT_PATH と OBSIDIAN_RAW_DIR（デフォルト：$OBSIDIAN_VAULT_PATH/_raw）を取得します。$OBSIDIAN_RAW_DIR が存在することを確認し、存在しない場合は作成します。

   キャプチャ処理では、バリデーターのスキーマ入力を独自に再解釈しません。OBSIDIAN_ALLOWED_LIFECYCLES、OBSIDIAN_ALLOWED_RELATIONSHIP_TYPES、OBSIDIAN_REQUIRED_TRUST_FIELDS、または OBSIDIAN_SCHEMA_SOURCE が存在する場合は、下流の lint／信頼性チェック処理のためにその値を保持します。CLI の値は環境変数／設定の値より優先され、環境変数／設定の値はフレームワークのデフォルトより優先されます。明示的な空値または空白のみの値が指定された場合は、フェイルクローズします。デフォルトを使用するには、変数を省略してください。

2. 判定 — KEEP か SKIP か？ 抽出する前に、このセッションにキャプチャする価値があるか判断します。これにより、スキルを自動で安全に呼び出せるようにし、_raw/ への不要な書き込みを防ぎます。

   • SKIP（「このセッションにはキャプチャする価値のある内容がありません。」と出力して終了）とするのは、次のすべてに該当する場合です。会話が純粋に計画／質疑応答／説明のみで、実装がない。エラー、デバッグ、問題解決が見られない。意外な点や文書化されていない内容がない。すべての発見事項がドキュメントから明らかである。
   • 次のいずれかに該当する場合は、KEEP（続行）とします。調査によって修正方法または回避策が見つかった。自明ではないライブラリ／API／フレームワークの挙動（エッジケース、文書化されていない制約、時間のかかる落とし穴）が確認された。デバッグセッションで具体的な結論に至った。再利用可能なパターンが得られた。
   • Stop フック経由で呼び出された場合は、SKIP 寄りに判断してください。明確な根拠がある場合に限り KEEP とします。手動で呼び出された場合は、KEEP 寄りに判断してください。ユーザーが呼び出したのには理由があるためです。

3. 再利用可能な発見事項を探す — 自明ではないバグと根本原因、フレームワーク／ライブラリの落とし穴、予想外の API 挙動、調査して判明した回避策、環境／ツールチェーンの癖、デバッグで得られたパターンを対象とします。PM の更新情報、すでに CLAUDE.md に記載されている設定、結論の出ていないやり取り、ドキュメントから明らかな内容、挨拶は除外します。重要な発見事項がなければ、その旨を伝えて終了します。

4. トピックごとにまとめる — 発見事項ごとではなく、トピックのまとまりごとに _raw/ ファイルを 1 つ作成します。ファイル名にはケバブケースのスラッグを付けます（例：swift-actor-reentrancy、nextjs-hydration-mismatch）。

5. プロジェクトのコンテキストを推定する — リポジトリ名、ファイルパス、フレームワークへの言及、エラーメッセージから判断します。確実に推定できる範囲で最も具体的な名前を使い、それ以外は null とします。

6. raw ファイルを書き込む — 各まとまりについて、$OBSIDIAN_RAW_DIR/<ISO-date>-<slug>.md に書き込みます。frontmatter の完全な仕様、発見事項ブロックの本文構造、出典情報／確信度の調整については、references/RAW-FORMAT.md を読んでください。まとまりごとに異なるフィールドは、title、tags（分類体系から 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>)"）です。

7. 確認する — ステージングしたファイルを一覧表示し、昇格するにはユーザーに /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.
   

   クイックモードでは、意図的にマニフェスト、index.md、log.md、hot.md への書き込みや、QMD の更新を行いません。これらは /wiki-ingest による昇格処理で実行されます。ここで終了し、以下のフルモードの手順は実行しないでください。

---

訂正モード（--correction）

ユーザーまたはより強い権威者が、変更不可能な会話、ツールの結果、その他の生の情報源から導かれた主張を訂正した場合に、このモードを使用します。生の情報源は編集もコピーもしないでください。設定を解決し、Vault の AGENTS.md を読み、主張を所有する既存の派生ページがあれば更新します。なければ、その所有者の要件に準拠した最小限の訂正ページを作成します。

原子的な主張のペアを正確に1つ記録します。speaker_type は意味に基づくものであり、シリアル化されたメッセージの role とは独立して評価する必要があります（ツールの結果が role=user としてシリアル化されている場合があります）。生の会話記録からの抜粋は含めないでください。

correction_id: <stable-id>
source_locator: <immutable file:line or channel/thread/timestamp>
source_text_sha256: <64 lowercase hex chars>
serialized_role: <source role, if present>
speaker_type: user | assistant | teammate | tool_result | slack_member
original_claim:
  subject: <exact entity or capability>
  assertion: <single atomic value>
corrected_claim:
  subject: <same exact entity or capability>
  assertion: <single atomic value or null>
authority_class: contract | decision | code | test | deploy | runtime | db | narrative
verification_state: verified | inferred | unverified | contradicted
asserted_at: <ISO-8601 timestamp>
effective_at: <ISO-8601 timestamp or null>
as_of: <ISO-8601 timestamp>
supersedes: [<original-claim-id>]
consumer_propagation:
  kw: open | not_applicable | complete
  ob: open | not_applicable | complete
  requirements: open | not_applicable | complete
  code: open | not_applicable | complete
  tests: open | not_applicable | complete
  ai_memory: open | not_applicable | complete
corrected_at: <ISO-8601 timestamp>

派生情報を書き込む前に、不変の情報源から直接 source_pre_sha256 を計算し、source_text_sha256 と一致することを確認してください。訂正を書き込み、派生情報の利用先を更新した後、同じロケーターから source_post_sha256 を再計算してください。source_pre_sha256 == source_post_sha256 == source_text_sha256 を満たさない場合は処理を中止し、不変性違反を報告してください。訂正の書き込みが成功した場合も、この検証は必須です。

派生訂正を書き込んだ後、.manifest.json を通じて不変の情報源を作成または更新したページにリンクし、log.md には訂正 ID と影響を受けたページ数だけを追記し、原子的な訂正をすべての利用先に個別に反映してください。利用先の検証が完了した後に限り、その利用先を complete としてください。結果が混在している場合は、単一の集約ステータスにまとめないでください。秘密情報、生の抜粋、情報源のコピーを訂正記録に含めないでください。

---

フルモード

始める前に

1. 設定を解決する — llm-wiki/SKILL.md の Config Resolution Protocol に従います（インラインの @name による上書き → CWD から上位へたどって .env を検索 → グローバル設定 → セットアップのプロンプト）。これにより OBSIDIAN_VAULT_PATH と OBSIDIAN_LINK_FORMAT（デフォルト：wikilink）が設定されます。
2. $OBSIDIAN_VAULT_PATH/index.md を読み、既存の Wiki の内容を把握します（重複を避けてください）。
3. $OBSIDIAN_VAULT_PATH/hot.md が存在する場合は読みます。最近の活動に関する背景情報が記載されています。

ステップ 5 で内部リンクを書く際は、llm-wiki/SKILL.md の Link Format セクションに従い、OBSIDIAN_LINK_FORMAT の値を使用してください。

ステップ 1：保存する価値のある情報を特定する

会話を確認します。こう問いかけてください。このチャットの内容を忘れた状態で3か月後に見返したとき、どの知識が役立つでしょうか？

保存する価値があるもの：

• 決定事項と、その決定に至った理由
• 導き出された分析、フレームワーク、思考モデル
• 技術的な知見、パターン、手順
• トピックについて統合された理解
• 導き出すのに労力を要した概念の明確な説明
• 会話で取り上げた外部情報源から得られた重要な事実

対象外：

• 事務連絡、スケジュール調整、挨拶
• 結論に至らなかった探索的なやり取り
• すでに Wiki にある内容

重要な情報が得られなかった場合は、ユーザーに伝えて終了します。

ステップ 2：コンテンツの種類を分類する

5種類のうち1つを割り当てます。これは保存先フォルダーと文体を決めます。

種類	説明	保存先フォルダー
synthesis	複数の段階からなる分析、または推論を必要とする特定の質問への回答	synthesis/
concept	定義、フレームワーク、思考モデル（あるものが何であるか）	concepts/
source	会話で取り上げた外部文書、記事、リソースの要約	references/
decision	戦略、アーキテクチャ、設計に関する選択と、その根拠	synthesis/
session	複数のトピックにまたがる会話全体の要約	journal/

内容が特定のプロジェクトに明らかに属する場合（文脈またはユーザーの言及から判断）、projects/<project-name>/<category>/ の下に配置します。

Step 3: 宣言的な知識として書き換える

会話の要約は書かないでください。宣言的な現在形で、知識そのものを書いてください。

• 例： 「ユーザーが X について質問し、Claude が……と説明した」ではなく、
• 例： 「X は……によって機能します」
• 例： 「Y を使うことにした理由は……」ではなく、
• 例： 「[理由] のため、Y は Z より適しています。[根拠が明示されず、暗示されていた場合は ^[inferred]]」

llm-wiki に従って、出典マーカーを適用してください。

• 抽出済み — 会話で明示的に述べられている（マーカーなし）
• 推論済み — 会話から一般化または統合されている → ^[inferred]
• 曖昧 — 異論がある、不確か、または矛盾している → ^[ambiguous]

Step 4: スラッグとタイトルを生成する

内容に基づいて、明確で具体的なタイトルを導き出してください。次のルールに従ってスラッグを作成してください。

• 小文字を使い、単語をハイフンで区切る
• 50 文字以内
• スラッグに日付を含めない（frontmatter に created があります）

Step 5: Wiki ノートを書く

必須の frontmatter を含めて、指定されたパスにファイルを作成してください。

---
title: >-
  <Title>
category: <synthesis|concepts|references|journal|skills>
tags: [<2-5 domain tags from taxonomy>]
sources:
  - conversation:<ISO-date>
created: <obsidian-wiki memory now>
updated: <obsidian-wiki memory now>
summary: >-
  <1-2 sentences, ≤200 chars, answering "what knowledge does this page hold?">
provenance:
  extracted: 0.X
  inferred: 0.X
  ambiguous: 0.X
base_confidence: 0.42
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>
---

種類に応じた本文の構成：

synthesis / decision:

# Title

## Context
<What prompted this — the problem or question being addressed>

## Finding / Decision
<The core knowledge or conclusion>

## Reasoning
<Why this is the case or why this choice was made>

## Implications
<What follows from this — what to watch for, next steps, trade-offs>

## Related
<[[wikilinks]] to connected pages>

concept:

# Title

<Definition in one clear sentence.>

## What It Is
<Explanation of the concept>

## How It Works
<Mechanism or structure>

## When to Use
<Applicability, conditions, trade-offs>

## Related
<[[wikilinks]]>

source:

# Title

> Source: <title or URL>

## What It Covers
<What the source is about>

## Key Points
<Bulleted claims with provenance markers>

## Open Questions
<What it raises but doesn't answer — omit if none>

## Related
<[[wikilinks]]>

session:

# Title

*Session captured: <date>*

## Topics Covered
<Brief list>

## Key Takeaways
<The 3-5 most important things that emerged>

## Decisions Made
<Any explicit decisions, with rationale>

## Open Questions
<What remains unresolved>

## Related
<[[wikilinks]]>

すべてのノートから、既存の Wiki ページに少なくとも 2 つリンクしてください。書き込む前に index.md を検索してください。関連ページが 2 つ未満の場合は、参照する最も重要な概念について、最小限のスタブを作成してください。

Step 5b: オーナープロフィールと Todo インデックスを更新する

メモリーの価値は、そこに何を書き込むかで決まります。このステップによってメモリーを活用可能な状態に保ちます。これを行わないと、プロフィールは空のままで、セッションの要約にも注入する情報がありません。

その人に関する永続的な事実。 会話から、ユーザーの仕事の進め方に関する安定した情報（使用技術、慣習、制約、タイムゾーンなど）が明らかになった場合は、記録してください。

obsidian-wiki memory profile set <key> "<value>" --confidence 0.85 --source "session:<date>"

Step 1 と同じ KEEP/SKIP の基準を適用し、さらに重要な次のルールも適用してください。

• ユーザーが実際に伝えたことだけを記録してください。直接伝えられた情報、または明確な実演から分かる情報が対象です。取り込んだ文書から、その人に関する永続的な事実を推測してはいけません。それは文書の内容であり、プロフィールではなくページに記録するものです。
• 一時的ではなく、安定した情報を記録してください。 「Postgres を使っている」は事実です。「今日マイグレーションを実行した」は出来事であり、ログに記録するものです。
• 期限付きの事実は期限切れになります。 「今週末に試験がある」「20 日まで旅行中」などの情報は、今後数回のセッションでは役立ちますが、永続的な情報ではありません。--until YYYY-MM-DD（その情報が有効な最終日）を指定して記録してください。その日付を過ぎると、要約への注入は停止します。
• 確信度を適切に調整してください。 明言された情報は約 0.9、繰り返し実演された情報は約 0.75、1 回のセッションでの振る舞いから推測した情報は約 0.5 です。確信度が 0.5 未満の場合は、記録しないでください。
• 重複させず、修正してください。 profile set は既存のキーを置き換えるため、変更された事実の更新にも同じコマンドを使います。

未完了の作業。 会話で作業が未完了のまま残った場合は、次のセッションで続けられるよう記録してください。

obsidian-wiki memory todo add "<the open thread>" --origin "<page or project>"

未完了の作業を同じテキストで再追加すると、重複せずに更新されます。すでに存在するか分からない場合でも、安全に実行できます。会話で、すでに一覧にある作業が完了した場合は、その作業を完了として記録してください。

obsidian-wiki memory todo list --vault "$OBSIDIAN_VAULT_PATH"
obsidian-wiki memory todo done <id>

ユーザーが実際に完了していない作業を完了にしてはいけません。古くなった作業はツールが報告します。一覧を整理するのはあなたの役目ではありません。

クイックモードでは、このステップを実行し、Step 6 は省略してください。プロフィールと Todo への書き込みは低コストで、ロックされており、情報を記録することの主な目的です。

Step 6: トラッキングファイルを更新する

1 回のロック付き呼び出しで、3 つすべてを更新できます。

obsidian-wiki memory sync CAPTURE \
  type=<type> page="<path>" title="<title>" \
  --takeaways "<what this capture changes about the picture, if anything>"

index.md、log.md、hot.md を手動で編集してはいけません。.skills/llm-wiki/references/MEMORY.md を参照してください。今回の記録によって全体像が変わらない場合は --takeaways を省略してください。前回の takeaways は引き継がれます。

Step 7: ユーザーに確認する

保存したパスとタイトルを報告してください。

Saved to: projects/<name>/synthesis/<slug>.md
Title: <Title>
Type: synthesis

品質チェックリスト

• 内容が宣言的な知識として書き直されている（チャットの記録ではない）
• 種別が正しく分類され、保存先のパスが適切なフォルダーにある
• Frontmatter にタイトル、カテゴリ、タグ、ソース、概要、来歴がすべて記載されている
• 既存ページへの Wiki リンクが 2 つ以上ある
• index.md、log.md、hot.md が更新されている
• 保存先のパスをユーザーに確認済み

Vault への書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる唯一の情報源ではありません。$QMD_WIKI_COLLECTION が空または未設定の場合は、この手順を省略してください。このスキルが Vault の Markdown を書き込みまたは書き直した後にのみ実行してください。QMD の更新に失敗しても Vault の変更はロールバックせず、QMD の状態は別途報告してください。

$QMD_CLI が設定されている場合はそれを使用し、そうでない場合は qmd を使用してください。

${QMD_CLI:-qmd} update

出力にベクトルが必要、または埋め込みが古くなっている可能性があると表示された場合は、次を実行してください。

${QMD_CLI:-qmd} embed

次のいずれかでコレクションを検証してください。

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

または、特定のページパスが分かっている場合は、次を使用してください。

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

次のいずれかを記録してください。

• 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>