process-inbox

Inbox の処理

キャプチャを分類します。ここでソースの知識を統合しないでください。選択したソースを関連付けられた LLM Wiki の知識にする場合は ingest を、会話の内容を統合する場合は create-note を使用します。

1. 範囲を確認する

../vault/SKILL.md と最新の AGENTS.md を読み、Inbox のパスを特定して、ノートの一覧を表示します。 件数を報告します。空の場合は終了します。

スキーマ上、一般的なキャプチャと区別されている場合は、ネストされた生ソースの Inbox も含めるかどうかを尋ねます。

完了条件：処理順と対象範囲が確定していること。

2. ノートを1件ずつ処理する

各ノートについて：

1. 分類できるだけの内容とメタデータを読む；
2. ファイル名と簡潔な要約を提示する；
3. 最新のスキーマにおける PARA と知識の慣例を適用する：
   • 成果が明確な、期間の限られた進行中の取り組み → Project；
   • 継続的な責任または標準 → Area；
   • 再利用可能な説明、手法、原則、未解決の問い → Knowledge；
   • 日付のある個人記録または学習記録 → 最新の慣例に従って Journal；
   • 特定のソースに関する記録、参考資料、スクリプト → Resource；
   • 明示的に中断された作業、またはユーザーがアーカイブを希望する記録 → Archive；
   • 不明確 → Inbox に残す； 年数、長さ、完成度ではなく目的で分類し、移動時に内容を保持する；
4. 具体的な移動先を1つ提案し、根拠を説明する；
5. ユーザーの判断を待つ。

ユーザーが選択できる作成済みの選択肢は、最大4つまで提示します：

1. 提案した移動先に移動する；
2. 別の移動先を選ぶ；
3. このノートをスキップする；
4. 処理を終了する。

削除の依頼は、カスタム回答経由またはその後の会話で受け付ける場合があります。実行の直前に、削除について個別に確認します。

ノートが統合に値する外部ソースの場合は、ingest を提示します。先に通常の参考資料として移動しないでください。

3. 実行して確認する

現在の Obsidian CLI のヘルプで、移動／削除の構文を確認します。承認された操作ごとに、移動元と移動先の状態を確認します。失敗した場合は、その項目の処理を止め、処理済み件数に加算せずに報告します。

4. 報告する

Projects、Areas、Resources、Knowledge、Journal、Archives、スキップ、削除、ingest に引き渡し、失敗、残件の件数を報告します。すべての移動と削除について、個別に承認を得たことを明記します。