mcpField
O
obsidian-bases

obsidian-bases

github.com/agricidaniel生産性16.0k499 回インストール1 週間前に更新
リポジトリ

obsidian-bases について

obsidian-bases は、Obsidian Bases の設計や構文に関する質問への回答と、依頼された `.base` 編集を扱うスキルです。簡潔な YAML リファレンスを備え、編集はプレビューと検査を経てトランザクションで適用します。

主な機能

  1. 01読み取り専用の設計・構文ガイド
  2. 02簡潔な `.base` YAML リファレンス
  3. 03フィルター、数式、ビューの案内
  4. 04レビュー済みトランザクションによる編集

活用シーン

  1. 01ノート群のフィルター設計
  2. 02数式とビューのレイアウト作成
  3. 03依頼された `.base` 変更のレビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/agricidaniel/claude-obsidian --skill obsidian-bases

インストール後、Claude Code で/obsidian-basesを入力して読み込まれたか確認します。

詳細

Obsidian Bases

コンパクトなワークフローおよび代替構文のリファレンスとして使用します。詳細な項目やバージョンに依存する項目・関数については、別途インストールした kepano/obsidian-skills の obsidian-bases スキルを優先し、その後に最新の公式 Bases 構文を参照してください。

設計や構文に関する質問には、読み取り専用で回答してください。.base の編集を依頼された場合は、ユーザーの Vault を特定し、内容を確認したうえで一度のトランザクションで処理してください。ファイルを直接書き換えてはいけません。

インストール済み製品のルートは、Vault や現在の作業ディレクトリではなく、このスキル自体の場所を基準に特定してください。

PRODUCT_ROOT=/absolute/path/to/installed/claude-obsidian
CORE="$PRODUCT_ROOT/scripts/claude-obsidian.py"
test -f "$CORE"

このファイル内の ../wiki/references/ へのリンクはすべて、選択した Vault の wiki/ ディレクトリではなく、$PRODUCT_ROOT 配下にあるこのスキル自体のディレクトリを基準として解決されます。

ワークフロー

  1. 代表的なノートのプロパティと、既存の .base ファイルがあればそれを確認します。

  2. 対象のノートを選択するための、必要最小限のフィルターを定義します。

  3. 計算が必要な値に限って数式を追加します。

  4. ビューと表示順を選択します。ユーザーの Obsidian のバージョンやインストール済みプラグインで、ビューの種類やオプションがサポートされているとは限りません。

  5. YAML、式の引用符、プロパティ名、数式の参照、および null の扱いを検証します。

  6. 変更を加える前に、ファイル全体と想定される結果セットをプレビューします。

  7. 編集を依頼された場合は、 operation-transactions.md を読み、.base ファイルを wiki/ 配下に置き、operation_type: base を指定した claude-obsidian.transaction.v1 バンドルを1つ作成します。内容を確認し、レビュー後にのみ APPROVAL_SHA256 を返された approval_sha256 の値に設定して、一度だけ適用します。

    python3 "$CORE" transaction inspect "$BUNDLE" --vault "$VAULT"
    python3 "$CORE" transaction apply "$BUNDLE" --vault "$VAULT" \
      --approved-plan-sha256 "$APPROVAL_SHA256"
    
  8. 静的検証と Obsidian でのネイティブ描画の検証は、別々に記録します。アプリケーションの動作をローカルで確認できない場合は、適合性確認の手順に従ってください。実際に確認していない出力を、テスト済みと表記してはいけません。

バージョンの範囲

2026-10-17 に公式ビューのドキュメントに基づいて確認済みです。テーブルとカードには 1.9 以降、リストには 1.10 以降、ネイティブのカンバンには 1.14 以降が必要です。マップには Maps プラグインが必要です。これらは文書化された最低バージョンであり、このパッケージのオフラインテストで実行したバージョンではありません。古いアプリでは、通常のテーブルを代替手段として残してください。既存の不明なビューのフィールドは保持してください。

簡易スキーマ

.base ファイルは YAML 形式です。一般的なトップレベルキーは filters、formulas、properties、summaries、views です。

filters:
  and:
    - file.inFolder("wiki")
    - 'status != "archived"'

formulas:
  status_label: 'if(status == "mature", "Ready", "Review")'

properties:
  status:
    displayName: "Status"

views:
  - type: table
    name: "Wiki pages"
    order:
      - file.name
      - type
      - status
      - updated
      - formula.status_label

グローバルフィルターはすべてのビューに適用されます。ビューごとに独自の filters を定義することもできます。再帰的なフィルターオブジェクトでは、各階層で and、or、not のいずれかを使用します。

filters:
  or:
    - file.hasTag("concept")
    - and:
        - file.hasTag("source")
        - 'status == "active"'

ノートのプロパティは名前で参照します。ファイルのメタデータは file.name、file.path、file.folder、file.ext、file.ctime、file.mtime、file.tags を使用し、計算済みプロパティは formula.<name> を使用します。

数式と YAML のルール

  • 演算子、コロン、または文字列の引用符が入れ子になっている式は、引用符で囲みます。
  • null になり得るプロパティは if() で保護します。
  • 日付の減算については、現在の情報源の説明に矛盾があります。以下の日付のセクションにある例は、互換性が未検証の候補として扱い、出力を前提にする前にユーザーがサポートしているアプリのバージョンでテストしてください。
  • ビューまたはプロパティ表示の設定で参照する前に、すべての formula.<name> を定義します。
  • from や where など、Dataview 専用のキーを Base に移植してはいけません。
  • 選択したノートに存在しないプロパティを、結果の列が空になることを説明せずに追加してはいけません。

日付の計算にはネイティブ環境での検証が必要です

2026-10-17 に確認した Help 構文では、 日付の差をミリ秒単位で表す方法が引き続き説明されています。公式の 1.9.3 変更履歴 では Duration が説明されており、固定された上流のスキルでも Duration フィールドが使われています。 レビュー対象のコミットにおける API 型定義 の記録済み抜粋には Duration の定義が含まれていないため、どちらの解釈の根拠としても引用していません。 今回の更新では、ネイティブアプリでの観察によってこの不一致は解消されていません。

以下の既存のミリ秒表現は、互換性が保証されたものではなく、個別のテスト候補です。

formulas:
  age_days: '((now() - file.ctime) / 86400000).round(0)'
  days_until: 'if(due_date, ((date(due_date) - today()) / 86400000).round(0), "")'

1 日、複数か月、負の値、値がない場合を用いて、直接の減算/除算、Duration の day フィールド、明示的な number(date) の減算を比較してください。native-conformance.md を使って、アプリのバージョン、タイムゾーン、式、実際の値と型、エラーを記録してください。この確認が済むまでは、既存の数式を書き換えたり、候補のいずれかが正しいと断言したりしないでください。

追加のビュー

カードとリストの例:

views:
  - type: cards
    name: "Reading list"
    order:
      - file.name
      - author
      - status
  - type: list
    name: "Quick list"
    order:
      - file.name
      - status

Obsidian 1.14 以降では、既存の書き込み可能なノートプロパティでカンバンをグループ化できます。

filters:
  and:
    - file.inFolder("wiki")
    - 'file.ext == "md"'
views:
  - type: kanban
    name: "Page status"
    groupBy:
      property: note.status
      direction: ASC
    groupOrder:
      - seed
      - developing
      - mature
      - evergreen
      - null
    order:
      - file.name
      - status

groupOrder では、表示順にグループを指定します。groupOrder がない場合は、groupBy の並び順ですべてのグループが表示され、空のリストの場合はすべてのグループが非表示になります。null を指定すると、グループ化された値を持たないページも含まれます。空のグループを追加してもノートは作成されません。ネイティブのカード移動ではノートプロパティが変更されることがあり、file.folder によるグループ化ではファイルが移動することがあります。エージェントは、ボルトを変更する際には引き続きレビュー済みのトランザクションを使う必要があります。数式やその他の読み取り専用のファイルプロパティは、編集可能なステータスボードには適していません。カンバンビューを参照してください。

Markdown ノートに Base または名前付きビューを埋め込みます。

![[Dashboard.base]]
![[Dashboard.base#Wiki pages]]

編集を適用した後は、操作 ID、変更された正確なパス、実施した検証、Obsidian でのレンダリングがまだ必要な箇所を報告してください。Git にコミットしないでください。

コメント