inbox-setup

Inbox-Setup — メールトリアージのオンボーディング

inbox-triage と連携します。 このスキルは ${WORKSPACE}/Email/ に7ファイルのナレッジベースを書き込みます。inbox-triage は実行のたびにこのナレッジベースを読み込みます。ファイルの契約（名前、セクション、フィールド）は、2つのスキル間で正確に一致していなければなりません。詳しくは references/kb_file_contract.md を参照してください。

一度実行します（または、ビジネスや優先事項が変わったときに再実行します）。ユーザーにメールの傾向、ビジネスの背景、返信スタイル、優先事項について質問します。inbox-triage が受信トレイを効果的に処理するために必要な情報をすべて含む、構造化されたナレッジベースを ${WORKSPACE}/Email/ に生成します。

起動トリガー

• 「受信トレイを設定して」
• 「受信トレイのトリアージを設定して」
• 「メールシステムを設定して」
• 「メールのトリアージを設定して」
• 「メールのナレッジベースを作成して」
• 「メール管理を初期化して」
• 「受信トレイのトリアージを設定して」
• 「メールトリアージのオンボーディングをして」

質問の進め方

すべてのファイルを一度に生成してはいけません。 8つのセクションを1つずつ進めます。次に進む前に、各セクションのファイルを確定します。途中でユーザーが離脱した場合でも（例：インタビューの途中で終了した場合）、部分的なナレッジベースを利用できる状態で作成します。

全体を通して、質問を掘り下げる進め方を徹底します。

• 1ターンにつき質問は1つ。 複数の質問をまとめてはいけません。セクションをまたぐ場合も同様です。
• すべての質問に「質問する理由」を添えます。ユーザーが適切に回答できるようにします。
• 可能な限り回答形式を指定します。 自由回答より選択式を優先します。
• 依存関係に沿った順序で進めます。 Q2はQ1に依存し、後続のセクションは先行セクションに依存します。

8つのセクションの進め方については、references/grill_me_section_walk.md を参照してください。

ナレッジベースの契約 — 作成するファイル

${WORKSPACE}/Email/ に、次のファイルだけを作成します。

ファイル	用途	必須？
email-taxonomy.md	分類体系＋レポート設定	はい
email-patterns.md	返信時の文体、トーン、テンプレート、厳守ルール	はい
evaluation-framework.md	案件メールの意思決定ツリー	ユーザーが売り込みや案件を受け取る場合のみ
rate-card.md	料金、条件、交渉方針	ユーザーに料金設定がある場合のみ
blocklist.md	自動スキップする送信者＋学習した辞退パターン	はい（初期データを設定し、時間とともに増やします）
tracker.md	対応中のフォローアップ、期限超過の項目、締め切り	はい（ほぼ空の状態で開始します）
triage-log/	実行ごとのログを保存するディレクトリ	はい（空の状態で作成します）

この契約は inbox-triage が期待するものと同一です。完全な仕様については、references/kb_file_contract.md を参照してください。

停止条件（インタビュー完了）

8つのセクション全体で、質問は合計約25～31問です（スキップ条件によって異なります）。すべての追加確認を含め、上限は35問です。セクション1で案件メールのカテゴリが見つからなかった場合、セクション4（評価フレームワーク）は完全にスキップされ、質問数が6問減り、料金表ファイルも作成されません。セクション8の確認と引き継ぎメッセージの後、聞き取りは終了します。決して再開してはいけません。 後から設定を変更するには、ユーザーがスキルを再実行します（既存ファイルを検出し、ファイルごとに置き換え／統合／スキップを確認します）。質問を1つずつ行うルールはセクション間にも適用されます。S{n}からS{n+1}に移る場合も、質問をまとめてはいけません。

セクション 1：全体像

質問を1つずつ、率直に6つお聞きします。

• S1.Q1: 「どのようなお仕事をされていますか？役割と事業内容を1〜2文で教えてください。質問の理由： メールの傾向を想定するうえで、背景が重要です。個人クリエイターの受信トレイは、企業のプロダクトマネージャーのものとはまったく異なります。」
• S1.Q2: 「受信トレイの大半を占めるのは何ですか？上位1〜2つを選んでください：営業メール／クライアントの仕事／社内チーム／ニュースレター／カスタマーサポート／財務関連／その他。質問の理由： 主なカテゴリをもとに分類体系を決めます。」
• S1.Q3: 「おおよその割合を教えてください。例：「業務上の問い合わせが60％、業務運営が20％、不要なメールが20％」。質問の理由： 割合から、トリアージにどこへ注力すべきかがわかります。」
• S1.Q4: 「トリアージの対象にするメールアドレスを教えてください。質問の理由： 複数ある場合は、アドレスごとに分類体系を設定します。」
• S1.Q5: 「実行頻度はどれですか？1日1回／1日2回／1日3回／必要なときだけ。質問の理由： トリアージのデフォルト検索期間を決めます（1日2回の場合は、重複期間を9時間にします）。」
• S1.Q6: 「メールの管理を手伝う人はいますか？アシスタント、VA、チームメンバーなど。それともお一人ですか？質問の理由： 委任された受信トレイでは、ペルソナの扱い方が異なります。」

アクション： 頭の中で全体像を組み立てます。まだファイルは作成しないでください。機会に関するメールがカテゴリに含まれるかを記録してください（S4のスキップ判定に影響します）。

セクション 2：メールカテゴリ

セクション1の内容をもとに、テンプレートのカテゴリをすべて並べるのではなく、5〜7個のカテゴリを提案し、その一部を事前に推奨します。

• 新しい機会
• 対応中のやり取り
• 対応が必要
• 財務関連
• 重要／個人的なメール
• 情報提供
• 無視／優先度低

次に、回答を明確に引き出す質問を3つ、1つずつお聞きします。

• S2.Q1: 「こちらが提案する分類体系です：[list]。実際の受信トレイに合っていますか？はい／おおむね合っている／いいえ。質問の理由： 「いいえ」の場合、ほかのセクションに進む前に分類体系を作り直す必要があります。」
• S2.Q2: 「不足しているカテゴリはありますか？あれば列挙してください。（なければ省略してください。）質問の理由： カテゴリが不足すると、後の処理で未分類メールが生じ、トリアージの品質が下がります。」
• S2.Q3: 「メール1通あたりの対応に最も時間がかかるカテゴリはどれですか？質問の理由： 返信文の下書き作成に最も注力すべきカテゴリがわかります。」

アクション： カテゴリ、シグナル（各カテゴリのトリガーフレーズ／送信者のパターン／件名のマーカー）、カテゴリごとのデフォルトの対応を記載した email-taxonomy.md を作成します。

セクション 3：返信のスタイルと文体

率直な質問を6つと、重要なサンプルの依頼をお聞きします。

• S3.Q1: 「文体はどれですか？フォーマル／カジュアル／その中間。質問の理由： まずデフォルトの文体を調整し、次にサンプルを見て整えます。」
• S3.Q2: 「コミュニケーション上、特に避けたいことを3つ教えてください。嫌いなフレーズや、使わない書き出しなどです。質問の理由： これらは下書きで使用禁止の語句として扱います。」
• S3.Q3: 「いつも使うフレーズや結びの言葉を、思いつく限り挙げてください。質問の理由： これらは文体を特徴づける要素です。」
• S3.Q4: 「状況によってペルソナを使い分けますか？たとえば、アシスタントがあなたとして返信する場合などです。質問の理由： ペルソナの文脈によって、代名詞や署名の扱いが変わります。」
• S3.Q5: 「典型的な返信の長さはどれくらいですか？一文／短い段落／長め。質問の理由： 長さは、文体のシグナルのなかでも特に間違いやすい要素です。」
• S3.Q6: 「厳守すべきルールはありますか？絶対にしないこと／必ずすることなど。（例：絵文字は使わない、24時間以内に必ず返信する、背景情報なしに電話には応じない。）質問の理由： こうした厳守ルールは、すべての下書きで必須事項として徹底します。」

S3.SAMPLES（最も重要で、品質の高い入力）

受信トレイから、実際に送信したメールを3〜5通貼り付けてください。

質問の理由： 自分の文体に関する自己評価は、信頼性に欠けることがあります。実際のサンプルが最良の手がかりです。サンプルを分析し、上記の情報を補う文体のパターンを見つけます。scripts/voice_sample_analyzer.py を使うと、パターンを決定論的に抽出できます。

ユーザーが事業を営んでいる場合は、メディアキット、料金表、標準的な営業文、繰り返し使う返信についても尋ねてください。

アクション： トーンの説明（良い例／避ける例を含む）、ペルソナのルール、テンプレート、署名、厳守ルールを記載した email-patterns.md を作成します。サンプル抽出の手順については、references/voice_calibration.md を参照してください。

セクション 4：評価フレームワーク（条件付き）

スキップ条件： セクション 1 で、案件メールが受信トレイの主要カテゴリとして見つかった場合にのみ、このセクションを実行します。それ以外の場合は、セクション 5 に進みます。

掘り下げる質問を6つ、1つずつ聞きます。

• S4.Q1：「何かを提案されたとき、最初に確認することは何ですか？直感的な判断基準を教えてください。質問の理由： それが意思決定ツリーの起点になります。」
• S4.Q2：「即座に断る理由になるものを3つ挙げてください。質問の理由： これらが自動で「見送り」とする判断基準になります。」
• S4.Q3：「すぐに興味を持つ理由になるものを3つ挙げてください。質問の理由： これらが「引き受ける」とする判断基準になります。」
• S4.Q4：「標準的な料金／条件を教えてください。毎回交渉する場合は「固定料金なし」としてください。質問の理由： 料金表があれば作成し、なければ省略します。」
• S4.Q5：「交渉に対する姿勢はどれですか？強硬／柔軟／状況による。質問の理由： 代替案を提示する際のドラフトのトーンに反映します。」
• S4.Q6：「必ず対応する VIP の送信者や組織を教えてください。名前またはドメインを挙げてください。質問の理由： VIP リストに登録された対象は、通常の「見送り」フィルターを回避します。」

アクション： evaluation-framework.md（意思決定ツリー＋推奨カテゴリ＋VIP リスト）を生成します。料金がある場合は rate-card.md も生成します。

セクション 5：ブロックリストとパターン

掘り下げる質問を3つ、1つずつ聞きます。

• S5.Q1：「常に無視する送信者やドメインを挙げてください。（なければ省略してください。）質問の理由： 自動ブロックリストは、実行ごとの時間を最も節約できます。」
• S5.Q2：「必ず削除するメールに共通するパターンはありますか？たとえば、特定のマーケターからの「配信停止」リンク、リクルーターからのコールドメール、ニュースレターなどです。質問の理由： パターンを使えば、完全一致のリストをメンテナンスせずに、トリアージで類似メールを自動的にスキップできます。」
• S5.Q3：「時間を無駄にしている特定の企業、リクルーター、ニュースレターを挙げてください。質問の理由： これらをブロックリストの初期項目にします。トリアージでは、判断を上書きするたびに項目が追加されます。」

アクション： blocklist.md を生成します（以降、トリアージによって自動的にメンテナンスされます）。

セクション 6：現在の状況

掘り下げる質問を3つ、1つずつ聞きます。

• S6.Q1：「追跡中の進行中のスレッドを、それぞれ1行の概要とともに挙げてください。（なければ省略してください。）質問の理由： これらをトラッカーの項目に登録し、トリアージが既存の状況を把握できるようにします。」
• S6.Q2：「返信が遅れているものはありますか？返信すべきだったのに、まだ返信していないものを教えてください。質問の理由： 解決するまで、トリアージの実行ごとに優先事項としてフラグを付けます。」
• S6.Q3：「期限のある、時間的制約のある項目を日付とともに挙げてください。質問の理由： トラッカーで期限を管理し、適切なタイミングで期限超過として表示します。」

アクション： 進行中のフォローアップ表、期限超過セクション、解決済みセクション（空）、更新ログ（空）を含む tracker.md を生成します。また、空の triage-log/ ディレクトリも作成します。

セクション 7：レポートの設定

掘り下げる質問を3つ、1つずつ聞きます。

• S7.Q1：「レポートの配信形式を選んでください：自分宛てのメールの下書き／ワークスペース内のファイル／チャットでの要約のみ。質問の理由： トリアージレポートは、実行ごとにここに配信されます。」
• S7.Q2：「詳細度を選んでください：30秒で確認できる要約／詳細な内訳／両方（まず要約し、リクエストに応じて詳細を表示）。質問の理由： レポートの長さに影響します。」
• S7.Q3：「必ず最初に表示したいものはありますか？たとえば、期限超過の支払い、VIP からのメッセージなどです。質問の理由： カスタムの「レポート冒頭」ルールにより、標準セクションより上に、重要な項目を表示できます。」

アクション： これらの設定を email-taxonomy.md の「Report Preferences」セクションに保存します。

セクション 8：確認と引き継ぎ

作成したファイルをすべて列挙し、それぞれを1文で要約します。その後、次のように伝えます。

トリアージシステムの準備ができました。inbox-triage スキルを実行して、受信トレイを処理してください。初回の実行では監督が必要です。システムは、編集や判断の上書きから学習します。

業務内容、料金、優先事項に変更があったときは、いつでもこのセットアップを再実行するよう伝えてください。

最終的な引き継ぎの前に、scripts/kb_validator.py --workspace ${WORKSPACE} を実行して、7ファイルの要件を満たしていることを確認します。

プライバシーの境界

パスワード、完全な口座番号、SSN、その他の機密性の高い認証情報をナレッジベースファイルに保存してはいけません。 面談中にユーザーが自発的にそのような情報を伝えた場合は、受け取ったことを伝えますが、保存はしません。該当する KB ファイルでは、その箇所を [stored separately by user] に置き換えます。

再実行時の動作

既存のセットアップに対して再実行する場合：

1. ${WORKSPACE}/Email/ を検出します
2. 既存ファイルごとに、置換／マージ／スキップのいずれかを尋ねます
3. ユーザーが更新を選んだファイルに対応するセクションのみを順に進めます
4. ユーザーが保持したファイルに対応するセクションはスキップします

エラー処理

状況	動作
ワークスペースにアクセスできない	停止します。ファイルの保存先をユーザーに伝え、許可またはパスを尋ねます
ユーザーがサンプルの共有を拒否する	自己紹介を利用します。調整には繰り返しが必要な場合があることを patterns ファイルに記載します
面談の途中でユーザーが「これはスキップ」と言う	その意向に従い、ファイル内の該当箇所に [needs follow-up] と記載します
機密情報を自発的に伝えられる	受け取ったことを伝えますが、保存はしません。ファイルには [stored separately by user] と記載します
既存のセットアップに対して再実行する	既存ファイルを検出し、ファイルごとに「置換、マージ、スキップ」のいずれかを尋ねます
料金や商談の機会がない	セクション 4 全体をスキップし、空のファイルは作成しません

移植性

• Claude Code CLI： ネイティブ対応 — Markdown ファイルをファイルシステムに直接書き込みます。
• Claude.ai web： プロジェクトファイル／アーティファクトで動作します。代替手順を記載します。ファイルをアーティファクトとして生成してユーザーにワークスペースへの保存を指示するか、利用可能な場合は接続されたファイルシステムを使用します。

ツール

スクリプト	役割
scripts/kb_validator.py	7 ファイルの KB 出力を検証します（必須ファイルの有無、対応するセクションを実行した場合のみ条件付きファイルが存在すること、ヘッダーと構造が正しいこと）。
scripts/section_progress_tracker.py	~/.inbox_setup_sessions/<session>.json に保存する JSON ベースの進行状態です。現在のセクション、回答済みの質問、確定済みファイルを追跡します。
scripts/voice_sample_analyzer.py	貼り付けられた送信済みメールのサンプルから、書き出しのパターン（書き出しのフレーズ、結びの言葉、長さの分布、文体の指標）を抽出します。

参考資料

• references/kb_file_contract.md — 7 ファイルの正式な仕様（書き込み側の視点。対応するものが inbox-triage/references/ にあります）
• references/grill_me_section_walk.md — 8 セクションを順に進めるルール、スキップのロジック、セクションごとの確定
• references/voice_calibration.md — サンプルに基づく文体抽出の考え方とアンチパターン

避けるべきアンチパターン

• セクションを順に進めず、すべてのファイルを一度に生成する
• 質問をすべて一括で尋ねる
• 特定のプロバイダーを前提にする（Gmail のみを想定する）
• 機密性の高い認証情報をナレッジベースに保存する
• 「この質問が重要な理由」の説明を省略する
• 文体の分析に使うメールサンプルの依頼を省略する（最も質の高い入力情報です）
• 再実行時に、同意を得ずに既存ファイルを上書きする
• 該当しない場合に rate-card.md または evaluation-framework.md の作成を強制する

---

バージョン： 1.0.0 ソース仕様： megaprompts/06-inbox-setup-megaprompt.md（メンテナーのローカル草案仕様 — gitignore 対象であり、公開リポジトリには含まれていません） ビルドパターン： パス B（直接変換）。inbox-triage と連携しています。