inbox-triage

inbox-triage skill の概要

inbox-triage でできること

inbox-triage は、既存の個人用メール知識ベースを使って、構造化された受信トレイ確認を実行するためのメールワークフロー自動化スキルです。直近のメールを検索し、あなたの分類体系に沿ってメッセージを分類し、新規送信者を特定し、取るべき対応を提案し、返信案を作成し、トリアージで得た学習内容を ${WORKSPACE}/Email/ に書き戻します。

導入時に最も重要なのは、inbox-setup とセットで使う前提になっている点です。inbox-triage skill は、セットアップで作成される 7 ファイル構成の知識ベースを想定しています。具体的には、email-taxonomy.md、email-patterns.md、blocklist.md、tracker.md、任意の判断用ファイル、そして triage-log/ ディレクトリです。

向いているユーザーとワークフロー

このスキルは、1 日 1〜3 回の定期的なメールトリアージをしたい人や、毎回好みを説明し直さずに「受信トレイを確認して」と頼める安定したオンデマンド運用を求める人に向いています。特に、案件相談、進行中のやり取り、ニュースレター、コールドメール、フォローアップが混在する受信トレイを持つ創業者、コンサルタント、クリエイター、オペレーター、多忙なビジネスパーソンに強みがあります。

単なる要約ではなく、分類、推奨、下書き作成、ログ記録、記憶の更新まで含めた意思決定支援が目的なら、Workflow Automation 用の inbox-triage として適しています。

主な違い

実用面での大きな違いは、安全性を優先した自動化モデルです。このスキルは下書きだけを作成し、メールを送信することは明示的にありません。リポジトリには references/drafts_only_safety.md と scripts/draft_safety_validator.py が含まれており、後者はアクションログに送信系のツール呼び出しが含まれていないかを確認します。

また、決定論的に動く補助スクリプトも用意されています。kb_reader.py はトリアージ前に必須の知識ベースを検証し、search_window_calculator.py は実行頻度に応じた検索対象期間を計算します。

このスキルが適さないケース

inbox-setup を実行していない、または想定される ${WORKSPACE}/Email/ ファイルを作成していない場合、inbox-triage を単独のプロンプトとして導入するのは避けてください。また、完全自律でメールを送信したい場合、軽い単発のメール要約だけが目的の場合、あるいはユーザー固有の分類体系や返信スタイルを無視する仕組みを求めている場合にも向きません。

inbox-triage skill の使い方

inbox-triage のインストール前提

GitHub のスキルリポジトリから、次のコマンドでスキルをインストールします。

npx skills add alirezarezvani/claude-skills --skill inbox-triage

その後、エージェントが次のスキルパスにアクセスできることを確認します。

productivity/email/skills/inbox-triage

初回実行前に SKILL.md を確認し、続いて references/kb_file_contract.md、references/drafts_only_safety.md、references/triage_decision_framework.md を読んでください。検証の挙動を把握するには、scripts/kb_reader.py、scripts/search_window_calculator.py、scripts/draft_safety_validator.py を確認します。

利用前に必要な入力

このスキルには、${WORKSPACE}/Email/ を含むワークスペースが必要です。最低限必要なファイルは email-taxonomy.md、email-patterns.md、blocklist.md、tracker.md で、triage-log/ はディレクトリとして存在している必要があります。evaluation-framework.md と rate-card.md があると、案件、価格、VIP、受ける／見送る判断の精度が上がります。

KB が存在しない、または形式が不正な場合は、処理を停止し、先に /cs:inbox-setup を実行するようユーザーに伝えるのが想定された挙動です。この fail-fast の設計により、エージェントがトリアージルールを勝手に作り上げるリスクを防ぎます。

スキルをうまく呼び出すプロンプト

弱いプロンプトの例は「メールを確認して」です。

よりよい inbox-triage の利用プロンプトは、次のようになります。「通常どおり 1 日 2 回のペースで inbox-triage を実行してください。既存の ${WORKSPACE}/Email/ 知識ベースを使い、現在の検索ウィンドウだけを対象にし、新着メッセージを分類し、返信は下書きまでで送信はしないでください。必要に応じて tracker.md と blocklist.md を更新し、私の希望フォーマットでレポートしてください。」

オンデマンド実行では、次のように上書き条件を含めます。「朝の確認を逃したので、過去 24 時間を対象に inbox-triage を実行してください。案件メールはスキップしないでください。返信は下書きのみでお願いします。」

初回実行の実践的な進め方

最初は、監督付きのドライランから始めるのが安全です。エージェントに KB の検証、検索ウィンドウの計算、予定している分類カテゴリの一覧化、送信アクションを使わないことの確認を依頼します。そのうえで、メッセージの処理、下書き作成、トリアージレポートの作成に進ませます。

レポート後は、3 点を確認してください。誤分類されたメール、自分らしくない文体の下書き、そして tracker.md や blocklist.md に書き込まれた更新内容です。これらの修正は効果が大きく、今後の実行結果が知識ベースに依存するためです。

inbox-triage skill FAQ

inbox-triage はメールを送信しますか？

いいえ。中心となる安全ルールは「下書きのみ」です。このスキルは、ユーザーが確認するための返信下書きを作成する設計であり、メールを送信するものではありません。付属の validator は、トリアージのアクションログをスキャンし、Gmail や Outlook の送信呼び出しのような送信系操作が含まれていれば実行を失敗させることができます。

通常のメール用プロンプトより何が優れていますか？

汎用プロンプトでもメールの要約はできますが、安定した記憶、送信者ルール、実行頻度に応じた検索ウィンドウ、下書きだけに留める安全管理、再現性のある推奨フレームワークが不足しがちです。inbox-triage skill は、定義された KB 契約を読み、分類体系を使い、TAKE IT / WORTH CONSIDERING / PASS / FLAG FOR REVIEW の判断を適用し、結果をログに残します。

inbox-triage は初心者にも使いやすいですか？

セットアップ後であれば初心者にも扱いやすいスキルです。スキルインストーラーを実行でき、エージェントにメールツールとワークスペースファイルへのアクセスを許可できるなら、日々の呼び出しは簡単です。最初のハードルは、inbox-setup への依存と、正確な ${WORKSPACE}/Email/ ファイル構成です。

どのメール環境に対応できますか？

このスキルは、特定のメールプロバイダーに限定するのではなく、メールツールの挙動を前提に書かれています。安全性に関するリファレンスでは、Gmail や Outlook/Microsoft Graph の下書き作成型の操作に触れています。実際にうまく動くかどうかは、あなたのエージェント環境が、送信権限なしでメール検索、閲覧、下書き作成の権限を持てるかに依存します。

inbox-triage skill を改善する方法

KB ファイルを整えて inbox-triage の結果を改善する

inbox-triage を最も早く改善する方法は、email-taxonomy.md と email-patterns.md をより具体的にすることです。スキップすべきニュースレター、優先的に拾う VIP、検討すべき案件、当日中の返信が必要なスレッドの例を追加してください。「短く、温かく、感嘆符は使わない」「価格は聞かれたときだけ含める」といった文体ルールも追加すると効果的です。

案件トリアージが重要なら、evaluation-framework.md と rate-card.md を継続的に管理してください。これらのファイルがあると、曖昧な「要検討」判断が減り、下書きに具体的な次のアクション、価格に対する姿勢、確認質問を含めやすくなります。

よくある失敗パターンを修正する

下書きを作りすぎる場合は、PASS のシグナルと blocklist ルールを厳しめにします。重要なスレッドを見逃す場合は、進行中の会話を示すシグナルや VIP エントリを拡充します。下書きが一般的すぎる場合は、採用した返信例と却下した返信例を email-patterns.md に実例として追加します。

検索ウィンドウがずれている場合は、search_window_calculator.py が使う頻度設定を確認してください。1 日 1 回の場合は広めの重複期間を使い、1 日 2 回・3 回の場合は短めのウィンドウを使います。通常と異なるキャッチアップ作業では、対象時間を明示的に上書きしてください。

初回レポート後に反復改善する

各実行後に、どの推奨が正しかったか、どの下書きを編集して送信したか、どのメッセージはスキップすべきだったかを記録します。そのフィードバックを一度きりのチャット文脈として扱うのではなく、KB 更新に変換するようエージェントに依頼してください。

便利なフォローアッププロンプトの例です。「最後の inbox-triage レポートを確認してください。X のようなメールは PASS に分類されるよう taxonomy を更新し、送信者 Y を VIP に追加し、コールドメール向けの下書きスタイルをもっと短く調整してください。送信安全ルールは変更しないでください。」

安全性とログを強制できる状態に保つ

定期実行で使う場合は、下書きのみのルールをプロンプトとログの中で見える状態にしておきます。環境がアクションログに対応しているなら、draft_safety_validator.py を実行または確認してください。triage-log/ は整理しておきましょう。何を検索し、何を下書きし、何をスキップし、何を学習したかを追跡する監査証跡になるためです。