set-note-description

フロントマターの要約

指定されたノートの description プロパティを生成し、各ノートの YAML フロントマターに書き込みます。

まず、対象の Vault の指示を確認してください。定期ノートの場合、依頼された規模に対応する Vault 固有のロールアップワークフローがあれば、そちらを優先してください。子ノートからまとめた上位期間のノートには、利用可能であれば periodic-rollup を使用してください。このスキルは、ノート自体の内容に使用するか、より具体的なワークフローが利用できない場合の代替として使用してください。

ノートが指定されていない場合は、処理を進める前に、どのノートを要約するか尋ねてください。

---

Markdown ファイルの分析アシスタントとして動作してください。ノートを読み、見つけやすくするための説明文を生成してください。指定されたモードがあればそれに従い、なければ内容の種類に応じて適切に選択してください。

モードの選択

ユーザーがモードを指定した場合は、それを使用してください。指定がなければ、内容の種類に応じて選択してください。

次の場合は要約モードを使用します

• 一時的な内容：日次ログ、週次ロールアップ、日記、定期ノート
• 期間限定の記録：会議メモ、イベントの振り返り、旅行記録
• 探求的な思考：考察、ブレインストーミング、問題解決の過程
• 個人的な振り返り：感情の整理、回顧、学び

こうした文書では、価値の中心は 洞察や出来事 にあります。文書全体を読み返すのではなく、要点を凝縮した結論や記憶の手がかりが必要です。

次の場合はメタモードを使用します

• 参考資料：ガイド、ハウツー、ドキュメント、テンプレート
• 長期的に利用できるリソース：手順、チェックリスト、ポリシー、標準
• ナレッジベースの項目：概念の解説、トピックの概要
• 編集されたコレクション：リンク集、読書リスト、リソース集
• プロジェクト成果物：仕様書、設計書、ブリーフ（文書が構成上の役割を果たすもの）

こうした文書は、必要に応じて参照するものです。文書から何を結論づけたかを思い出すのではなく、問題の解決方法や疑問への答えを探します。

主な目的の評価

個々の文から目的を推測するのではなく、文書の 本質的な種類 を評価してください。手がかりが相反する場合は、文書の主な目的を優先してください。

• 日記、ログ、出来事の記録 → 要約
  何が起きたか、または 何が話し合われたか を振り返るためのものです。
• マニュアル、テンプレート、参考ガイド → メタ
  このツールを いつ使うべきか を把握するためのものです。
• 考えを巡らせたり、振り返ったりする人 → 要約
  その時点で得られた気づきをまとめます。
• 百科事典の項目、仕様書、プロジェクトブリーフ → メタ
  トピックやプロジェクトの範囲や要件を定める構成上の成果物です。
• 決定事項や会議の結論の一覧 → 要約
  文書を読み返さなくても、実際の結論 がわかるようにします。
• 編集されたコレクションやリンク集 → メタ
  個々のリンクを要約するよりも、コレクションの範囲を明確にすることが役立ちます。

---

エッジケース

ハイブリッド文書（例：再利用可能なプロセスを含む日次ログ）： 文書の 主な目的 を基準にします。付随的なプロセスのメモが含まれていても、日次ログは日次ログです。summary を使い、そのプロセスは注目項目として記載します。プロセスの価値が十分に高まったら、独立したメモに切り出します。

会議メモ： summary を使います。「第3四半期の計画会議のメモ。次の場合に使用……」ではなく、決定事項、アクションアイテム、重要な議論の要点に焦点を当てます。

書籍／記事のメモ：

• 主に抜粋や引用で、独自の考察が最小限の場合 → meta（「[Title] に関するメモ。[topics] を扱っています。[domains] について考える際に使用します。」）
• 本文について、個人的なコメント、洞察、議論が十分に含まれている場合 → summary（自分自身の要点を記録します）

仕様書、概要書、提案書： meta を使います。これらは構造を示す文書です。読者が知る必要があるのは、結論の要約ではなく、どのような問題領域を扱っているかです。

骨子やプレースホルダー： meta を使います。意図された用途を説明します：「API 認証ドキュメント用のプレースホルダー。認証フローを文書化する際に使用します。」

分類が難しいコンテンツ： summary を既定で使います。曖昧な内容を漠然と説明するより、実際に書かれていることを記録するほうが有用です。

---

Summary モード

内容に書かれていること、または起きたことを、1〜2文で要約します。要点を明確にしつつ、記憶をたどる手がかりとなる具体的な名前、出来事、細部も含めます。探索的な内容では、主なテーマを記録します。

簡潔で読みやすい表現にします。評価や枠付けの表現（「生産的な朝……」「〜に費やした一日……」）ではなく、対象そのものから書き始めます。冠詞や冗長な語句は単語レベルで削りますが、セミコロンで断片を詰め込むより、平易な文にします。「その後」「しかし」などの接続副詞や物語の展開（因果関係、解決）を避け、細部を網羅するのではなく本質を記録します。

定期的なメモの場合：

• 期間を示す前置きは省略します（ファイル名で分かるため）
• スリップボックス、追記、または二次セクションの比重は抑えます
• 実際の内容、活動、洞察に焦点を当てます

Summary の例

• "スケジュールに20〜30％の余裕を持たせることでAcme Corpの遅延を防げます。事前にSarahのチームと認識を合わせるほうが、技術的な計画を詳細に練るより時間を節約できます。"
• "Marcusのオンボーディングを任せるのに苦労しています。自分でやることを思いやりと同一視してしまうため、委任を信頼関係の構築として捉え直します。"
• "午前中はShopify統合に取り組み、午後はAWSの障害と家族の予定で時間を失いました。Kleppmannの読書を通じて、分散システムへの理解に不足があると気づきました。"

---

Meta モード

この文書が何であるか（種類、目的、範囲）と、いつ参照するかを説明します。What + When のパターンに従います。

[文書の種類／トピック] [範囲または焦点]。[明示的な条件] の場合に使用します。

参照する具体的な条件を記載します。「関連する場合に使用」は役に立ちません。「認証エラーのデバッグ時、またはバックエンドエンジニアのオンボーディング時に使用」なら検索しやすくなります。

meta モードで定期的なメモを扱う場合（まれですが、依頼されることがあります）は、検索の手がかりとなる分野、プロジェクト、テーマに焦点を当てます。

Meta の例

• "Vault のメタデータ規約と Base ファイル統合に関するガイド。フォルダー構成の設計、クエリのトラブルシューティング、またはナレッジシステムのオンボーディング時に使用します。"
• "タイムライン、コラボレーション、技術的負債に関するプロンプトを含む、プロジェクトの振り返り用テンプレート。プロジェクトを完了するときや、チームの振り返りを準備するときに使用します。"
• "進捗メモ付きの分散システムに関する読書リスト。次に読む技術書を選ぶときや、他の人にリソースを勧めるときに使用します。"
• "エラー処理と再試行ロジックを扱う、Shopify の在庫同期に関する仕様書。在庫機能の実装時や同期エラーのデバッグ時に使用します。"

---

出力

ノートの内容に合わせて長さを調整してください。目安としては、150～250文字程度（1～2文）を意識し、内容が単純または少ないノートでは大幅に短くしてください。文字数を埋めるために水増ししてはいけません。これは出発点として扱い、ノートの内容や、ユーザーが自身のシステムで説明文をどのように活用しているかに応じて調整してください。1024文字を大幅に下回るようにし、段落ほどの長さは避けてください。

Frontmatter の配置

YAML frontmatter のこの位置に description プロパティを追加または更新してください。

1. ID とルーティング（aliases、icon、publish、permalink、url）
2. コンテンツ／分類（tags、description）← ここに挿入
3. 人物／時間／関連情報（author、members、meeting time、related）
4. ステータス／来歴（reviewed、created、modified）

重要なルール

• 変更してよいのは description プロパティのみです。それ以外の内容は変更、エスケープ、再フォーマットしないでください
• 要約の値は二重引用符で囲んでください
• 既存の書式と Obsidian 固有の構文をすべてそのまま保持してください
• ファイルに書き込めない場合は、次だけを含む Markdown のコードブロックを出力してください：description: "your summary here"

定期ノートの扱い

定期ノートの場合：

• ファイル名にすでに期間が示されている場合は、期間を表す接頭辞を追加しないでください
• 「スリップボックス」や受信箱のセクションは、要約に与える比重を小さくしてください。これらは後で整理したり、別のノートにしたりする項目を集める場所です（例：スクラッチパッド、生のキャプチャ、外部リンク）。こうした内容が要約を偏らせないようにしてください
• その日の実際の内容、活動、気づきを中心にしてください

階層的なロールアップのパターン

子ノートから週次、四半期、年次の統合を行う場合は、環境のロールアップワークフローまたは periodic-rollup に従ってください。このワークフローが子ノートの選択、欠落ノートの処理、親ノートの統合を担います。その手順に、別個の要約作成を重ねないでください。