obsidian-bases

obsidian-basesスキルの概要

obsidian-basesが得意なこと

obsidian-bases は、データベースのようなノート表示に使う Obsidian の .base ファイルを、エージェントが作成・編集するのを助けるスキルです。特に、filters、formulas、summaries、table・cards・list・map といったビュー設定を含む、Bases 機能向けの正しく動く YAML が必要なときに役立ちます。

ナレッジベース運用に向くobsidian-bases

この obsidian-basesスキルは、vault をナレッジベース、プロジェクト管理、読書リスト、コンテンツダッシュボードとして運用している人に特に向いています。実際に解決したいのは単に「YAMLを書く」ことではなく、「自分のノートとメタデータを、Obsidian で実際に表示できる使いやすいビューに変える」ことです。

汎用プロンプトではなくこれを使う理由

違いは構造化された進め方にあります。このスキルは、filters で対象範囲を決め、必要に応じて formulas を加え、ビューを設定し、最後に YAML とプロパティ参照を検証するという明確なワークフローをエージェントに与えます。これにより、普通のプロンプトで起きがちな失敗、たとえば不正な .base 構文、壊れた formula 参照、vault のスキーマに合っていないビューを減らせます。

obsidian-basesスキルの使い方

導入時の前提と最初に読むべきファイル

スキル自体に特別な install コマンドはありません。これは kepano/obsidian-skills 内のガイダンス用スキルです。まず skills/obsidian-bases/SKILL.md を読み、その後 skills/obsidian-bases/references/FUNCTIONS_REFERENCE.md を確認してください。読む順番は、最初に workflow セクション、次に schema の例、formula が必要になったときだけ function reference を見るのが効率的です。

obsidian-basesスキルに必要な入力

obsidian-bases をうまく使うには、エージェントに次の情報を渡すと効果的です。

• base の目的。たとえば「進行中のプロジェクトを表示したい」
• サンプルのノートパスやフォルダ
• 関連する frontmatter のプロパティ、タグ、日付フィールド
• 希望するビュータイプ: table、cards、list、map
• 追加したい計算フィールド。たとえば期限超過状態や読了時間
• 表示面の希望。たとえばプロパティの並び順や summary に出したい項目

弱い入力例: 「タスク用の base を作って」

強い入力例: 「Projects/ 内のノート用に .base ファイルを作成し、status != done のノートだけを含め、title、status、due、formula の is_overdue を表示し、デフォルトは table view、さらにモバイル向けに cards view も追加して」

曖昧な要望を通るプロンプトに変える

実用的な obsidian-bases 用プロンプトでは、完全な .base ファイルに加えて検証ポイントまで求めるのが有効です。例:

「Using obsidian-bases, create a valid .base YAML file for notes in Areas/Research/ tagged #paper. Add filters for only unread items from 2024 onward, define formulas for age_days and is_recent, create a table view ordered by title, author, year, and formula.age_days, and explain any quoting needed to avoid YAML errors.」

この形が有効なのは、対象範囲、メタデータ、formulas、表示順を具体化したうえで、構文を意識した出力まで求めているからです。

実践的な進め方と出力チェック

次の順序で進めるのがおすすめです。

1. 最初は最小構成の .base を作ってもらう。
2. 複雑にする前に YAML 構文を確認する。
3. formula は一つずつ追加する。
4. 1つ目のビューが正しく表示されてから 2つ目のビューを加える。

このスキルで特に重要な品質チェック:

• YAML の特殊文字で解析が壊れそうな文字列は quoting する
• ビューで使うすべての formula.X が formulas 内で定義されていることを確認する
• プロパティ名が実際のノートと完全一致しているか確かめる
• テキストエディタ上だけでなく Obsidian でテストする

obsidian-basesスキル FAQ

obsidian-basesは初心者にも向いている？

はい。基本的な Obsidian のプロパティや frontmatter をすでに理解しているなら有用です。obsidian-basesスキルは安全な作成順序を示してくれるため、フォーマット全体をゼロから覚えるより取り組みやすくなります。ただし、vault 内のメタデータにばらつきがあると、完全な初心者にはまだ難しい場合があります。

AIに .base ファイルを直接頼むのと何が違う？

汎用的なプロンプトでも、それらしく見える YAML は出せますが、実際には表示できないことがあります。obsidian-basesスキルが優れているのは、実際の .base ワークフローに沿っている点です。つまり filters を先に、formulas を次に、views をその後に、最後に validation する流れです。formula を使う場面では function reference に当たるべきことも示してくれます。

obsidian-basesが向かないケースは？

本当の問題がメタデータ不足、ノート構造の不統一、あるいは「何を表示したいのか」自体が固まっていないことなら、obsidian-bases は適しません。また、Bases フォーマットの外にあるプラグイン固有のドキュメントの代わりにはなりません。vault のスキーマが散らかっているなら、まずそこを整えるべきです。

obsidian-basesはformulasやfunctionsにも役立つ？

はい。導入判断の観点でも、references/FUNCTIONS_REFERENCE.md はこのスキルの中でも特に価値の高いファイルです。日付計算、条件分岐による表示、型変換、リンク、アイコン、formula ベースのプロパティ内での HTML レンダリングが必要な場面で役立ちます。

obsidian-basesスキルを改善するには

出力を求める前にvaultのスキーマを整理する

最も効果が大きい改善ポイントは入力品質です。完全な base を依頼する前に、3〜5件のノートから実際のプロパティ名と値の例を列挙してください。あるノートでは due-date、別のノートでは due を使っているような状態だと、エージェントは filters や formulas を安定して設計できません。

よくあるobsidian-basesの失敗を防ぐ

典型的な失敗パターン:

• quoting されていない文字列による不正な YAML
• 定義前に使われる formula 参照
• 実在しないタグやプロパティを対象にした filters
• 最初のドラフトから複数ビューや summaries を一度に詰め込みすぎること

最初の依頼としては、対象を絞るのが有効です。1フォルダ、1フィルタ、1ビュー、1formula から始めてください。

動く最小構成から段階的に広げる

obsidian-bases を安定して使うなら、修正依頼はレイヤーごとに分けるのが効果的です。

• 1回目: 1つの filter と 1つの view を持つ、有効な .base
• 2回目: 計算フィールドを追加
• 3回目: 代替ビューと summaries を追加
• 最終段階: 前提条件や、スキーマの食い違いがありそうな点についてコメントしてもらう

こう進めると、どの追加要素が表示崩れの原因になったのかを切り分けやすくなり、信頼性が上がります。

リファレンスファイルを戦略的に使う

obsidian-bases の結果を改善したいなら、「高度な formulas を作って」と抽象的に頼まないことが大切です。やりたい処理を具体的に伝え、その処理を references/FUNCTIONS_REFERENCE.md にある既知の functions に対応づけてもらってください。そうすることで、出力がドキュメント化された function set に基づいたものになり、特に日付、boolean、リンク、表示フォーマットまわりで幻覚的な構文を減らせます。