oh-my-wiki

oh-my-wiki（OMW）

ストレージに依存しない LLM Wiki スキルです。Andrej Karpathy の 3 層パターン（Raw / Wiki / Schema）を実装し、Vault ごとに memo-only モードと wiki-mode を併用できます。操作は commands/*.md に、決定的な入出力処理は scripts/*.py にあります。状態はグローバルレジストリ ~/.omw/registry.db に保存されます（ルートは OMW_HOME で上書きできます）。Vault のコンテンツは、各 Vault の登録済みパスに保存されます。

短縮エイリアス： OMW（小文字の omw）。oh-my-wiki と omw はどちらもこのスキルを指します。

⛔ 厳守ルール — 何かをする前に必ずお読みください（交渉不可）

1. omw CLI のみを使用してください。内部機能は絶対に呼び出さないでください。 すべての操作は omw コマンド（omw status、omw vault create <name> --mode wiki --type <markdown|obsidian>、omw vault use、omw search、omw fetch、omw ingest、omw query、omw connections など）を通じて実行してください。 python3 -m scripts.<anything> や python3 -c "from scripts import …" を実行したり、scripts/*.py モジュール（registry、adapters、reindex、wizard など）を直接インポートまたは実行したりすることは禁止されています。scripts/ パッケージは内部実装の詳細であり、ユーザーインターフェースではありません。
   • CLI の事前確認（初回使用時）： omw コマンドを呼び出せない場合は、bash "<this skill dir>/bin/ensure-cli.sh" を 1 回実行してください。CLI（pipx/pip）のインストール前にユーザーに確認し、OMW_BIN=<path> を出力します。このセッションで omw … を呼び出す際は、その絶対パスを使用してください（PATH は次のセッションで更新されます）。python3 -m scripts.* に頼ることは絶対にしないでください。
2. Web 検索は必ず omw search "<query>" を通じて行ってください。 ユーザーが設定したプロバイダーにルーティングされ、Wiki の出典情報が維持されます。OMW の作業に、自分自身のネイティブ Web 検索ツールを使用しないでください。
3. Vault の作成には必ず omw vault create <name> --mode <mode> --type <markdown|obsidian> を使用してください。 registry/adapters を自分で呼び出して Vault を構築してはいけません。
4. ソースの取り込みには omw fetch <URL> または omw ingest を使用してください。 raw/ にファイルを手書きで作成してはいけません。omw search は 429 または結果が空の場合に、キーを設定済みのプロバイダーへ自動的に切り替えます。取得時は、まずネイティブの fetch を試し、その後 omw fetch を使用してください（urllib→chromium→cloud の順に試行します）。

python3 -c、python3 -m scripts を書こうとしていたり、ネイティブ Web 検索を使おうとしていたりすることに気づいたら、作業を中断し、代わりに上記の該当する omw コマンドを使用してください。

現在のステータス

現在のリリースは、7 つの Vault モード、グラフベースの lint、自動調査、Wiki メンテナンス用ペルソナ 6 種、Obsidian/Logseq ビューアー、URL fetch と受信トレイ、高精度なプロンプト単位の情報検索、Claude Code と Codex の同一プロジェクト内におけるステージ済みセッションの継続、ローカル埋め込み、決定論的なライフサイクルガイダンスをサポートしています。使用方法については、README.md、TUTORIAL.md、TUTORIAL.ko.md を参照してください。

ステップ 1 — レジストリの状態を読み取る

何よりも先に、必ずこれを実行してください：

コマンドインターフェース — まずお読みください。 omw で処理を実行する方法はちょうど 2 つで、 単独で実行するスクリプト CLI はありません。omw_db.py、 vault.py、cli.py、bootstrap.py などのファイル名を作り出さないでください。これらは存在しません。

1. 決定論的な操作（status、vault 管理、lint、検索、serve、schema、supersede、review、links、fields、view、visibility、inbox、fetch、reindex、connections）：omw CLI を実行します — omw status、omw vault list、omw vault create <name> --mode wiki、 omw vault use <name>、 omw vault info <name>（単一 vault の JSON カード：path/type/mode/active/archived + ノート数）、 omw vault current [--json]（アクティブな vault の名前を表示）、 omw vault rename <old> <new>（レジストリーのラベルを変更。インデックスは保持）、 omw vault move <name> <new-path>（ディスク上の vault フォルダーを移動し、path を更新）、 omw vault set <name> [--mode M] [--config k=v]（mode/config のみ編集。type/path/name は move/rename で管理）、 omw vault archive <name> / omw vault unarchive <name>（vault を非表示／復元。アーカイブ済みの vault は omw vault list --all で表示）、 omw vault delete <name>（既定ではゴミ箱にソフト削除。完全に消去するには --hard --yes）、 omw lint、omw schema list、omw supersede <relpath> --by <slug>、 omw review due、omw serve（取得専用のメッセンジャークエリー API — references/messenger-api.md を参照）、 omw view [page] [--search Q] [--viewer obsidian|logseq] [--vault <name>] [--print]（URI スキームを通じて Obsidian または Logseq で vault/page/search を開く。連携コマンド：omw setup viewer）、 omw visibility get <relpath> / omw visibility set <relpath...> public|private（ページごとの可視性管理）、 omw inbox add <url> / omw inbox list / omw inbox remove <url> / omw inbox run（URL をキューに追加し、まとめて raw/ に取得）、 omw embed status|list|use <model>|add <model>|install|reindex（ローカル埋め込みモデル：FastEmbed + sqlite-vec を選択／管理。再構築は使い捨て DB で行われ、完全に成功した場合に限りライブベクトルインデックスを置き換えます）、 omw fetch <url> [--backend auto|urllib|chromium|cloud] [--vault] [--today YYYY-MM-DD]（URL または YouTube の文字起こしを 1 件取得して raw/ に保存。urllib → chromium → cloud の段階的な取得方式で、SSRF 対策済み）、 omw reindex [--full]（ファイルを再スキャンしてレジストリーに登録 — 検索／connections 用に本文中の [[wikilinks]] を登録します。wiki ページを直接書き込んだ後、または手動編集した後に実行して、リンクグラフを最新の状態にしてください）、 omw connections [--no-reindex]（リンクグラフのコミュニティ／ハブ／意外なつながり — 新しく書かれたページのリンクをすでにグラフに反映するため、最初に自動で再インデックスします）。 直接書き込んだ wiki ページは、再インデックスするまでインデックスに登録されません。 raw/ の内容をファイルへの書き込みによって wiki/ ページにまとめる場合、その [[wikilinks]] がリンクグラフに反映されるのは omw reindex（または再インデックスを行う操作）の実行後です。omw connections を実行すると、自動で再インデックスされます。python3 -m scripts.reindex は実行しないでください — omw reindex を使用してください。 可視性（セキュアな設定が既定）： omw serve が返すのは、frontmatter に visibility: public があるページのみです。このフィールドのないページは プライベートとして扱われ、配信されません。ページを公開するには、 omw visibility set <relpath...> public を明示的に実行してください。 ページタイプの規約（必須の frontmatter フィールドとセクション）は schemas/<type>.yml にあります。 vault では <vault>/schemas/ を使ってタイプを上書きまたは追加できます（omw schema show <type> で確認）。 ページの信頼度に関する規約：confidence: high|medium|low。廃止されたページには status: superseded + superseded_by: <slug> が設定されます。各ページのレビュー間隔は frontmatter の review: ブロック（last/due/interval_days）に記載されます。期限が来たページは omw review due で一覧表示できます。 wiki クエリーでは、利用可能な場合、SQLite の全文検索 FTS5（title+summary+tags+body に対する BM25）を使い、 利用できない場合はトークンスコアラーに自動でフォールバックします。その後、commands/query.md に従って LLM が候補を再ランク付けします。 埋め込み／ハイブリッド戦略ではローカルの fastembed モデル（既定は intfloat/multilingual-e5-small）を使います。omw setup recall または omw embed use <model> で設定できます。 既存ページへの未リンクの言及は自動で候補として提案され（omw links suggest / lint の link_suggestions）、omw links link <relpath> --to <slug> で挿入できます。または、明示的に 1 回確認した後に、omw links link --from-suggestions でまとめて挿入できます。ページには、照合に使用する任意の aliases: frontmatter リストを指定できます。ページにはインラインの key:: value フィールド（Dataview の行構文）も記述できます。関係キー（uses/contradicts/supersedes:: [[B]]） は、frontmatter の relations: と同様に型付きエッジグラフに反映されます。また、omw fields <relpath> でページの frontmatter + インラインフィールドを一覧表示できます。統合ページ ⇒ synthesizes: [slugs] + ## Sources セクション、 比較ページ ⇒ compared_items: [...]。出典の来歴を source_raw: に記録し、正確な 関係動詞（derived-from/extends/illustrates/applies-to/instances-of/see-also/synthesizes）を使用してください。
2. 推論操作（ingest、query、autoresearch、personas、…）：omw <op> … で呼び出します。 CLI は引数を割り当て、現在の AI セッション用の正確な手順カードを返します。そのカードに従ってください。scripts.* のエントリーポイントを作り出したり、 代わりに使ったりしないでください。

omw status

JSON 出力を解析します。フィールド：

• vault_count（整数）
• active（null または {name, path, type, mode}）
• needs（"setup" | "select" | "op"）
• confirm_target（ブール値 — 2 つ以上の vault が登録されている場合は true。マルチ vault 書き込みガードを参照）
• vaults（{name, mode} の配列）

Step 2 — needs に応じて振り分ける

needs	Action
"setup"	omw vault create <name> [--mode …] を直接実行します（決定的な操作）。サブコマンドとモードについては、omw-commandmap ブロックまたは omw vault -h を参照してください。
"select"	アクティブな vault を切り替えるため、omw vault use <name> を直接実行します（決定的な操作）。
"migrate"	commands/migrate.md を読み込みます。
"op"	ユーザーの入力を確認します。op が明示されている場合は、その op の commands/<op>.md を読み込みます。それ以外の場合は、以下の Op Wizard を実行します。

決定的な vault 管理では omw CLI を直接呼び出せます（例：omw vault list）。コンテンツ op では必ず commands/<op>.md を読み込み、その指示に従ってください。

メニュー（対話型の入口）

ユーザーが特定の op を指定せずに omw を呼び出した場合（単独の「omw」、「Wiki を開いて」、「オーマイウィキで何をしよう？」など）は、推測せずに commands/menu.md を読み込み、AskUserQuestion メニューを表示します。

Step 3 — Op Wizard（op が指定されていない場合）

AskUserQuestion を使用します（選択肢は最大 4 つ）。選択肢は active.mode に応じて異なります。

memo モード

1. 新規メモ — 内容を貼り付ける
2. メモを検索 — 検索する
3. メモを開く — アプリで起動する
4. 管理 — 編集／移動／削除

wiki モード

1. 取り込み — 新しいソースを追加する（外部ファイル／URL／貼り付け → raw/ → 蒸留したページ）
2. 蒸留 — このセッションからページを作成する（取り込む外部ソースなし）
3. 質問／検索 — Wiki に質問する、または既存のページを検索する
4. メンテナンス — lint／編集／削除

取り込みと蒸留の分岐は、記録する元資料があるかどうかです。残しておくべき元資料がある場合は ingest、このセッションで起きたこと自体が素材の場合は distill です。自分のファイルツールを使って Wiki ファイルを書き込んではいけません。そうすると、出典情報、新規作成か更新かの選択、リンクの提案、再インデックスが省略されます。

安全性に関する契約

これらのルールはすべてのコマンドに適用されます。各 commands/<op>.md にも、関連するルールが記載されています。

• 破壊的な操作は必ず確認します：delete、omw vault forget、--hard による削除。
• omw vault forget はファイルに一切触れません — レジストリの行のみを対象にします。
• 推測した対象は明示してから確認します：「先ほど書いた X のメモのことですね？」
• 暗黙のフォールバックは禁止です：vault のパスがディスク上に存在しない場合は、その旨を報告して停止します。自動で forget しないでください。
• マルチ vault 書き込みガード：wizard status の confirm_target が true の場合、書き込み op（ingest、create、autoresearch、persona ファイルへの書き込み、inbox run、fetch、import）の前に、保存先を確認します：「N 個の vault のうち、<name>（<path>）に書き込みます — 続行しますか？」このセッション内ですでに同じ vault を確認済みの場合は、確認を省略します。omw vault use で切り替えた後は、確認状態をリセットします。
• SMB マウントされた vault（例：/Volumes/...）では、cp ではなく rsync -rlpt を使用します。SMB では cp -a を絶対に使用しないでください。
• AskUserQuestion の選択肢では、推奨する選択肢を最初に置き、末尾に (추천) / (recommended) を付けます。

ユーザーに判断を求める（omw-ask の規約）

Wiki の保存／構成作業では、実質的な分岐点が発生します。たとえば、新規として提案するか、更新するか、統合／置き換え／アーカイブするか、公開するか、非公開のままにするか、_ペルソナに委任するか、自分で対応するか_です。 こうした分岐点では、構造化された選択肢を提示して質問し（propose → confirm → execute の confirm にあたり、単なるテキストから強化されています）、その後、決定どおりに実行してください。

• 実質的な分岐点でのみ質問してください。ユーザーが判断するトレードオフや、取り消せない操作／外部への影響が対象です。 些細な操作、取り消し可能な操作、明らかに既定とすべき操作については質問しないでください。
• ホストのネイティブな質問手段を使ってください：Claude の AskUserQuestion、Gemini の ask_user、opencode の question、Hermes の clarify、Codex の requestUserInput／MCP-elicitation、openclaw の requireApproval（二択）＋チャンネルのボタンです。ホストごとの形式をまとめた表と、判断クラスの全一覧は、常時有効な omw-ask 管理ブロックにあります。
• 安全な（破壊的でない）選択肢を先に提示し、末尾に (추천) を付けてください。破壊的な操作（delete／merge --apply／supersede／上書き）では必ず質問し、破壊的でない選択肢を既定にしてください。セッションの「自動」選択中であっても、自動適用してはいけません。
• 質問疲れを防いでください：関連する細かな判断はまとめて一度に質問します。判断クラスについてユーザーが「このセッション中は…」という選択肢を選んだら、このセッション中に再度質問しないでください。
• 代替対応（非対話型／ヘッドレス／質問ツールなし）：処理を止めず、安全な既定値を選び、何を選んだかとその理由を記した <omw-ask> の1行メモを出力して続行してください。
• 質問はホストで、実行はワーカーで行います：質問はホストのオーケストレーターで行い、起動したペルソナのサブエージェント内では行わないでください（そこでは質問ツールを利用できません）。

メンテナンスゲート（オプトイン）

ユーザーがゲートを有効にしている場合（omw setup gate --enable）、ゲートが機能するように対応してください。

• ナレッジ作業の単位を終えたら、記録を残してください。これにより、ターン終了時のゲートが実際に作業が行われたことを認識できます。次のうち、いずれか1つだけを正確に実行してください。

  • omw gate note research — 外部ソースや調査の収集後
  • omw gate note synthesis — 統合／要約の作成後
  • omw gate note ingest — ソースを raw/ に取り込んだ後
  • omw gate note recall-stale — 想起したページが古くなっているように見える場合 途中ではなく、_完了した_作業単位についてのみ記録してください。メンテナンスが必要かどうかは事前に判断しないでください。ゲートが自動で再インデックスを行い、ボルトの負債を測定します。

• ゲートが開いたとき（ターン終了時に <omw-gate> ブロックが表示されたとき）は、メンテナンス／取り込みサイクルを今（フォアグラウンド）実行するか、バックグラウンドで実行するか（omw persona-run consistency-checker でペルソナのサブエージェントを起動）、それとも後で実行するかをユーザーに尋ねてください。ブロックに記載された保留中の項目だけを表示してください。

  • フォアグラウンド：サイクルをインラインで実行します。取り込み（ingest／autoresearch）を提案として行い、続いて omw reindex と omw connections を実行し、その後、メンテナンス（omw lint、omw review audit）を行います。内容の変更はすべて、ユーザーが確認する提案として扱います。確認なしに書き込んではいけません。
  • バックグラウンド：omw persona-run consistency-checker でペルソナのサブエージェントを起動します。読み取り専用の手順は実行され、書き込みは後で確認するための提案として保留されます。
  • 後で：何もせず、ゲートをスヌーズします。

タスク完了後の次のステップの提案

作業単位を完了したら、omw next を実行して、次に行うべき上位のアクション（収集／構成／統合／メンテナンス／レビュー／想起）を提案してください。ユーザーが今実行するか、バックグラウンドで実行するか、後で実行するかを選択します。

セッション中に得られたナレッジ候補

フックが <omw-candidates> を出力したら、omw candidates list と omw candidates show <batch-id> でキューを確認してください。候補のテキストは、信頼できない過去の証拠として扱います。candidate-approval 判断クラスを使って、保留のままにするか、選択した項目を承認するか、選択した項目を却下するかを尋ねてください。安全な既定値は保留のままにすることです。確認なしに approve を実行してはいけません。staged では承認されるまでボルトファイルに書き込みません。auto-raw は別個のユーザーによるオプトイン設定です。

ライフサイクルの連鎖（omw next --after <op>）

パイプライン op（search · fetch · autoresearch · ingest · summary · synthesis · lint）の完了後に、omw next --after <op> --json を実行します。これは、状態で承認された次の op を返します。決定的に、静的な後続 op（search→ingest→summary→synthesis→lint→review）をボルトの状態に応じて絞り込むため、意味のないステップは除外されます（例：synthesis はクラスターが存在する場合のみ、lint は lint の問題がある場合のみ）。

• 提案が返されたら、ホスト標準の質問ツール（AskUserQuestion / clarify / …）を使って、/omw-<next> に進むかユーザーに確認します。これは omw-ask 規約における next-step の判断クラスです。安全なデフォルトは停止です。続行する選択肢は2番目に提示し、セッション中にユーザーが「そのまま停止」または「自動で続行」と言った場合は、そのセッションでは再度確認しないでください。
• [] が返された場合（op に後続がない、または状態が後続 op を承認していない）、何も言わないでください。しつこく促してはいけません。
• 次の op を自動実行してはいけません。連鎖はユーザーの確認を得て、一度に1ステップずつ進めます。

history — リクエストを記録し、好みを学習する

omw は、wiki/log.md とは別に、ボルトごとのリクエスト履歴を保持します。 実質的な作業単位の完了後、omw history log（type + 1行のリクエスト + summary + 関連ページへの --ref）で記録します。ユーザーが回答の修正や再生成を依頼した場合は、--revises <id> --outcome revised --focus "<what changed>" を付けて記録します。

実質的なリクエストや、同じ形式の依頼に対応する前に、履歴を確認します。 以前の参照情報は omw history similar "<request>"、ユーザーの繰り返し見られる関心事項は omw history prefs で確認してください。詳しい手順は commands/history.md を参照してください。

トリガーフレーズによる振り分け

ユーザーの表現を、ホストの指示ファイル（CLAUDE.md / AGENTS.md / GEMINI.md）にある生成済み `` ブロックの triggers 列に照らして op に振り分けます。この列は各 op の EN/KO キーワードを対応付けたものです。scripts/ops_registry.py から再生成されるため（omw setup recall / omw update --refresh）、ここで手作業で管理することはなく、内容が古くなることもありません。キーワードが一致した場合は、ウィザードよりその op を優先してください。キーワードのない op（例：status、 doctor、setup、version）には、ステップ1のウィザードまたはネイティブフックから進みます。

コマンド一覧（決定的なコマンドと手順）

omw の各 op は、次の2種類のいずれかです。実行前にどちらかを確認してください。

• run（決定的なコマンド）：シェルで実行し、JSON／テキストの結果を信頼します。 例：omw status、omw lint、omw reindex、omw connections、omw find <query>、 omw candidates list/show/approve/dismiss、 omw fetch <url>、omw search <query>、omw gate …、omw inbox …。
• procedure（このセッションでの作業が必要）：omw <op> … を呼び出すと、CLI がこのホストセッション用の引数を設定した手順カードを表示します。現在のセッションでそのカードの内容を実行してください。カード自体を完了結果として扱ってはいけません。 手順：ingest、distill、query、open、edit、move、delete、 autoresearch、summary、synthesis、persona-factcheck、 persona-consistency、persona-terminology。

op ごとの正式な一覧表（引数 + ヒント）は、ホストの指示ファイルにある生成済み `` ブロックです。これは scripts/ops_registry.py から再生成されます。ここで op の一覧表を手作業で管理してはいけません。内容が古くなります。omw <op> --help で、1つの op の引数を確認できます。

複数ステップのリクエスト

上の一覧表は単一の opを振り分けます。複数のライフサイクル段階にまたがるリクエストや、2つ以上の opを指定するリクエスト（例：「X を調査し、ファクトチェックして、wiki に整理する」）は、関連する op を順番に実行して処理します。オーケストレーションはホストの AI エージェント（Claude Code / Codex / Gemini）が担います。omw は意図的に独自のマルチエージェントランタイムを提供していません。

貼り付けコンテンツのヒューリスティック

ユーザーが操作名を指定せずに 200 文字以上のテキストを貼り付けた場合：

• active.mode == "memo" → create を提案します
• active.mode == "wiki" → ingest を提案します

書き込みの前には必ず確認してください。提案するスラッグと保存先を先に表示してください。

omw vault create で指定できるモードは、memo、wiki、personal、book、business、github-codebase、website です。それぞれのモードで作成される構成については、README の「Vault modes (v2.0)」を参照してください。

リソース

• scripts/wizard.py — ステータスコマンド（このファイルのエントリーオラクル）
• scripts/registry.py — SQLite のボルトとノートの CRUD
• scripts/adapters.py — MarkdownAdapter、ObsidianAdapter
• scripts/reindex.py — mtime ベースの増分インデクサー
• scripts/search.py — 重み付けされた自然言語検索
• scripts/frontmatter.py — 安全な YAML 編集
• scripts/slugify.py — タイトル → kebab-case スラッグ
• references/architecture.md — 3 層アーキテクチャ
• references/schema-sqlite.md — DB スキーマに関するメモ
• references/vault-modes.md — memo と wiki の動作比較表
• references/wizard-flow.md — 完全な判断ツリー
• references/socratic-dialog.md — 質問のトーンとパターン
• references/adapter-spec.md — 新しいアダプタータイプを追加するためのガイド
• references/frontmatter.md — YAML フィールドの定義
• commands/connections.md — omw connections のエージェントによる説明手順（コミュニティ検出と、意外なつながり／ハブ）