session-librarian

セッションライブラリアン

「Q3 の価格設定に関するセッションを探して、役立つものを残し、重複を整理して」のような平易な言葉での依頼に応じて、ユーザーのセッションライブラリを会話形式で管理します。過去のセッションをトピックから探し、決定事項を要約し、内容に合った名前に変更し、作業を並行するセッションに分割し、古くなったセッションのアーカイブまたは削除を提案します。

Perplexity Computer のプロンプト駆動型セッション管理（2026 年 8 月）に着想を得ています。エージェントはユーザー自身のセッションライブラリを開始、整理、クリーンアップし、何かに手を加える前には必ず計画を示します。

使用する場面

• 「X に関するセッションはありますか？」／「X について何を決めましたか？」
• 「これらのセッションに、内容が分かる名前を付けてください。」
• 「セッションライブラリを整理してください」／「古くなったものをアーカイブしてください。」
• 「このセッションを、Y に焦点を当てたフォローアップ用に分岐してください。」
• 「これをチケットごとにセッションを分けてください」（下記の「並行するワークストリーム」を参照）。

2 つの操作手段

タスク	操作手段
トピックからセッションを探す、内容を読む、決定事項を要約する	session_search ツール（メッセージストアに対する FTS5）
メタデータ（経過日数、ソース、コスト、トークン数、ワークスペース）で一覧表示／絞り込む	ターミナルから hermes sessions list ／ stats
名前を変更する	hermes sessions rename <session_id> <title...>
一括ソフト非表示（元に戻せます）	hermes sessions archive <filters>
削除（元に戻せません）	hermes sessions delete ／ hermes sessions prune <filters>
価値のあるセッションを削除する前にエクスポートする	hermes sessions export --session-id <id> --format md
新しい場所で作業を続ける	/branch（現在のセッションを分岐する）、または新しいセッションを開始して要約を引用する

手順

① 見つける。 トピックのキーワードを使って session_search(query=..., limit=5-10) を実行します。表現を変えて検索します（機能名、症状、プロジェクト名など）。メタデータを一括で調べる場合（「telegram から 60 日以上前のセッション」など）は、代わりに hermes sessions list --source telegram --limit 50 を使います。

② セッションごとに要約する。 通常、検索結果の bookend_start（目標）、一致箇所のウィンドウ、bookend_end（解決内容）で十分です。詳細な決定事項をユーザーが求めた場合にのみ、セッション全体を取得します（session_search(session_id=...)）。各セッションについて、リンク（@session: 形式）— 1 行の目標 — 1 行の結果、の形式で報告します。

③ 実行前に計画する（変更を加える場合は必須）。 まず計画表を提示します。どのセッションの名前を何に変更するか、どれをアーカイブするか、どれを削除候補とするか、その理由（残すセッションとの重複、古くなっている、空など）を記載します。ユーザーの承認を待ちます。例外として、ユーザーが明示的に指定した単一の名前変更は、そのまま実行できます。

④ 最も安全な方法で実行する。

• delete／prune より、元に戻せるソフト非表示の archive を優先します。
• 削除を伴うコマンドは、必ず最初に --dry-run を付けて実行し、その出力を提示します。その後、ユーザーの確認を得てから --yes を付けて再実行します。
• 有用な内容を含むものを削除する前に、バックアップとして hermes sessions export --format md を提案します。

⑤ 報告する。 名前を変更したもの、アーカイブしたセッション（件数と元に戻す方法。アーカイブ済みセッションは DB に残り、--include-archived を付けると一覧に表示されます）、エクスポートしたもの、スキップしたものとその理由を報告します。

並行するワークストリーム

「チケットごとにセッションを分けて、それぞれを調査し、結果を報告して」のような依頼では、ほかの進行中のセッションを操作しようとしてはいけません。各ワークストリームに 1 つずつタスクを割り当てて delegate_task を使います。各サブエージェントは自動的に独自のセッションで実行されます。その後、各サブエージェントの要約を統合します。各委任タスクのトランスクリプトも、後から session_search で検索できることを伝えます。

落とし穴

• この会話でドライランを実行し、明示的な確認を得るまでは、決して削除しないでください。 「整理しておいて」という継続的な指示は、削除の権限ではなく、提案する権限です。
• session_search が検索するのはコンテンツであり、メタデータではありません。 経過時間やコスト、ソースによるフィルターは CLI で行います。リクエストに両方が含まれる場合（「価格設定についての古いセッション」など）は、両方を組み合わせてください。
• /resume <title> では、タイトルが識別子になります。 タイトルを変更する場合は、短く、重複せず、プレフィックスとして使いやすいものにしてください。既存のタイトルと重複する場合は、ユーザーに警告してください。
• アーカイブは削除ではありません。 アーカイブすると、デフォルトの一覧にセッションが表示されなくなるだけです。どちらを実行したか伝えてください。
• プロファイルをまたぐセッションリンク（@session:<profile>/<id>）は、別のプロファイルからは読み取り専用です。管理コマンドは、現在のプロファイルの DB に対して実行されます。

検証

整理が終わったら、検出クエリと hermes sessions list を再実行して、ライブラリに計画どおり反映されていることを確認してください（残すセッションには新しいタイトルが設定され、アーカイブしたセッションはデフォルトの一覧から消えていること）。