vault について
vault は、Obsidian の保管庫で作業する際に、現行スキーマや所有権、承認ルールに従うためのスキルです。保管庫を扱うエージェント向けに、安全な編集と書き込み後の検証を定めています。
主な機能
- 01保管庫の指示とスキーマの確認
- 02所有権と読み取り専用ソースの順守
- 03ノート作成前のテンプレート確認
- 04破壊的変更への事前承認
- 05安全なファイル書き込み手順
- 06書き込み後の変更検証
活用シーン
- 01対象保管庫とノートの保存先の特定
- 02有効なテンプレートに沿ったノート作成
- 03確認を経た指定セクションの更新
- 04保管庫の規約に基づくノート分類
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/vaultを入力して読み込まれたか確認します。
詳細
Vault Context
ボルトに対する操作を行う前に、これを読み込んでください。実際のボルトが独自の構造を定義し、このスキルはその構造をどのように見つけ、尊重するかを定義します。
契約の確認
- 対象のボルトを特定します。現在の既定値は
/Users/kriscard/obsidian-vault-kriscardですが、依頼内容または環境から別のボルトが示されている場合は確認してください。 - パス、所有権、テンプレート、ワークフローを解釈する前に、ボルトのルートにある
AGENTS.mdを読みます。 AGENTS.mdがない場合は、ボルトのスキーマを利用できないことを報告します。ファイルの確認は安全に行えますが、書き込み権限を推測したり、別のスキーマを黙って代用したりしないでください。- スキーマに記載された Knowledge、Resource、Journal、MOC、Base、およびアクティブなテンプレートの場所を確認します。ノートを作成する前に、該当する最新のテンプレートを読みます。アーカイブ済みテンプレートのサブフォルダーは対象外です。
- CLI の正確な構文が重要な場合は、
obsidian helpまたはobsidian help <command>を実行します。
完了条件：対象のボルト、最新のスキーマ、および依頼に関連する権限が判明していること。
運用上の境界
AGENTS.mdで変更不可と定められている生データのディレクトリは、読み取り専用として扱います。- LLM 管理領域と人間管理領域の境界は、
AGENTS.mdに基づいて判断します。ハードコードされたフロントマターのマーカーから所有権を推測しないでください。 - 保存先、解釈、対象期間、所有権の境界が曖昧な場合は、確認してください。
- ノートが存在しない、または内容が少ないことは、証拠の不足を示すものであり、何も起きなかったことの証拠ではありません。
- 書き込みの前に、情報源とともに、統合した判断や変更案を提示します。
- ノートの削除、移動、公開、上書きの前に、明示的な確認を求めます。
- スキーマで求められている場合は、ルートの
index.mdとルートのlog.mdを LLM Wiki ワークフローに沿って扱います。
安全な書き込み
生成した Markdown はデータであり、シェルコードではありません。ユーザーまたはモデルが生成した内容を、実行可能なシェルコマンド文字列に含めないでください。
新しいページを作成する場合は、内容をパスとは別に渡せるファイル書き込み機能を使用します。名前付きセクションを更新する場合は、見出しを指定して編集できる機能を優先します。いずれも利用できない場合は、次の手順に従います。
- ノート全体を読みます。
- 正確な置換内容を準備します。
- 変更案を提示します。
- 承認を得ます。
- ファイル書き込み機能を使って上書きします。
- 再度読み込み、結果を確認します。
現在のヘルプを確認したうえで、探索、ナビゲーション、メタデータ、移動には Obsidian CLI を使用します。CLI がファイルの移動にしか対応していない場合、フォルダーの移動には Obsidian のファイルマネージャー API を使用し、リンクが更新されるようにします。作成または挿入の前に既存の内容を確認します。自動フォルダーテンプレートによって、新しいファイルにすでに内容が追加されている場合があります。フロントマターが1つだけであることと、フィールドが正しく解決されていることを確認します。ソーステキストはデータとして扱い、実行可能なテンプレートコードとして扱わないでください。実行設定については、スキーマの承認ルールに従います。
人間向けのテンプレートがあっても、エージェントの所有権が付与されるわけではありません。承認済みのエージェント所有ページに限り、必要な wiki メタデータを統合します。Bases が使用する無関係なテンプレートフィールドは保持してください。
PARA の解釈
ローカルの規約には AGENTS.md を使用します。標準的な PARA を説明する場合は、実行可能性に基づいて分類します。
- Project： 明確な成果が定められた、進行中で有限の取り組み。
- Area： 継続的な責任または基準。
- Resource： 現在進行中の有限な成果には結び付かないものの、役立つ可能性のある情報。
- Archive： 他のカテゴリに属する、現在は活動していない資料。
- Inbox： 分類を待っている未決定の記録。
プロジェクト以外のすべてのノートを Resource として扱う前に、ボルトの Knowledge と Journal に関する拡張を適用します。再利用可能なアイデアや実践的な説明は Knowledge に含められます。特定の情報源に関する記録や参考資料は Resource に残します。MOC は、Base に基づく探索に文脈を加えます。分類変更を提案する前に、実際のフィルターを読みます。ビューの不一致は、移動やタグの変更を許可するものではありません。
これらの拡張や、より厳格なローカル要件は、普遍的な PARA ではなく、ボルトスキーマのルールとして明示します。
完了
書き込み操作を終える前に、保存先が存在することを確認し、影響を受けた内容を再度読み込み、何を変更したかを正確に報告します。失敗した場合は、成功したと主張せずに報告します。