sales-kickoff

Sales Kickoff

27 個のスキルで構成される sales-skills コレクションへの入口兼ルーターです。現在の営業タスクを兄弟スキルのうちちょうど 1 つに振り分けるか、該当するものがないとはっきり伝え、次のセッションをゼロからではなく、前回の続きとして開始できるようにします。このスキルが存在する理由はルーティングです。それ以外のすべては、そのためにあります。

このコレクションは 2 つの高度で構成されています。CRO の高度から全体の枠組み（営業手法、ICP、市場規模、セグメント、ティア、組織構造、ノルマ、カバレッジ、報酬体系）を決める 9 つの計画スキルと、その決定によって定まった枠組みの中で実行する 18 のスキルです。ルーティングの前に、セッションがどちらの高度にあるかを特定してください。同じ言葉でも、高度によって該当するスキルは異なります。

別のコンテキストですでにコレクション内のスキルを日常的に使っている場合でも、プロジェクト開始時には必ずこのスキルを実行してください。新しいプロジェクトは新しいコンテキストであり、兄弟スキルに日頃から慣れていても、キックオフ時の確認の代わりにはなりません。同じプロジェクトの後続セッションでは、要約とルーティングをやり直すために再実行します。再度ヒアリングするためではありません。

このコレクションは 2 つの営業形態を対象としています。B2B SaaS のアウトバウンド営業と AE 主導の営業、そして歩合の比重が高い高額商材の B2C（不動産、保険、太陽光発電、自動車）です。B2B と B2C でアドバイスが異なる場合は、各兄弟スキルの対象範囲に従い、両者の違いを平準化せずにルーティングへ反映してください。

1. 質問する前に検出する

環境から導き出せる事実については、ユーザーに答えてもらう必要はありません。まず検出してください。それをしなければ、質問数の上限は意味をなしません。

1. 1 つのシグナルだけで、コールドスタートかウォームスタートかを判断します。プロジェクト内にコンテキストファイル sales-context.md が存在するかどうかです。存在する場合はウォームスタート、存在しない場合はコールドスタートです。ユーザーにどちらかを尋ねてはいけません。
2. リポジトリの Git 履歴を読める場合は、最近のログを読み、コミット頻度、直近の変更内容、作業が停滞していたかどうかからプロジェクトの段階と進捗ペースを推測します。
3. 既存ファイル（README、エージェント向け指示ファイル、ICP やペルソナのドキュメント、プレイブック、ノルマ・報酬・テリトリー計画、.github/）をすべて確認し、すでに書かれていることを再度尋ねないようにします。
4. 利用中のハーネスでコネクターや連携機能を利用できる場合は、利用可能なもの（CRM エクスポート、シーケンサー、通話録音、カレンダー、議事録）を検出し、その有無をルーティングやルーティンに反映します。特定の製品を想定せず、利用可能な機能について説明してください。
5. 読み取り可能なバージョンメタデータがコレクションに含まれている場合は、前回のセッションからの変更点を確認します。含まれていない場合（一般的なケース）は、何も言わずに処理を続けてください。バージョンを理由に処理を中断したり、警告したり、質問したりしてはいけません。

2. インタビュー — 上限付き、回答しやすく

コールドスタートの場合：

• 質問は最大5〜7問にします。
• 1つのメッセージにつき質問は1つにします。
• 可能な限り、複数の選択肢を提示します。
• 検出で答えが見つからなかった項目にだけ質問を使います。ファイル一覧や git log ですでに答えが得られている質問は省略します。

質問をプレーンテキストで表示するのではなく、対話型の質問メカニズム（AskUserQuestion、askuser、Jev、またはハーネスが提供する任意の意思決定・質問ツールなど）を使用してください。テキストのみのプロンプトでは、ユーザーは自由形式で回答せざるを得ず、構造化された選択肢を活用できません。この推奨を、特定のモデルやハーネスに結び付けないでください。メカニズムの名称は一般的なものにしてください。

1. 「どのような営業モデルで取り組んでいますか？」—（a）B2Bのアウトバウンド主導（SDR／BDRによる見込み客開拓）、（b）B2BのインバウンドまたはフルサイクルAE、（c）高額商材のB2C／コミッション比率が高い営業、（d）混合。
2. 「どの役割に就いていますか？」—（a）SDR／BDR、（b）AE、（c）計画を策定する営業マネージャー、イネーブルメント担当、または営業リーダーシップ（営業担当VP／CRO）、（d）営業を担当する創業者、（e）営業職の採用担当、（f）営業職の面接を受ける人。面接、評価シート、または立ち上がり計画に関する依頼では、早い段階で必ず質問してください。（e）と（f）の選択肢で、採用とキャリア形成のどちらのルートかを1問で判断できます。また、（c）または（d）は、セッションが計画レベルであることを示す一般的なサインです。
3. 「このセッションの目標は何ですか？プロジェクトの目標と同じですか？」コールドスタートとウォームスタートの両方で質問してください。プロジェクトの目標で今日の目標を代用することはできません。
4. 「今、ファネルのどの部分が最も課題になっていますか？」—（a）商談を獲得できない、（b）商談が進展しない、（c）商談がセールスサイクルの途中で停滞する、（d）交渉またはクロージングで失注する、（e）チームの一貫性とコーチング、（f）個々の商談ではなく、営業モデル、ICP、セグメント、組織、ノルマ、報酬プランなど、ファネルの上流にある計画。
5. 「厳しい制約はありますか？また、結果を出す必要がある期限はありますか？」—（a）ノルマの期限または四半期末：日付を提示、（b）ドメインまたは送信者レピュテーションの問題、（c）規制対象のアウトリーチ（電話勧誘拒否、同意、地域ごとのメール関連法）、（d）CRMまたは通話録音へのアクセスがない、（e）なし。
6. 「このセッションで一度限りの成果を得たいですか、それとも継続的に価値が積み重なる資産を作りたいですか？また、取り組みに割ける時間の上限はどれくらいですか？」—（a）一度限り、数時間のみ、（b）一度限り、1週間の作業なら可能、（c）継続的な成果、今後は毎週数時間、（d）継続的な成果、人員の確保やマネージャーの承認も可能。
7. 「すでに決まっていることと、まだ検討中のことは何ですか？」—ICP、オファー、価格の下限、チャネル、ツールについて、それぞれ1行で回答してください。決定済みの項目は、再検討の対象から外します。

質問5と6は、プロジェクトの説明ではなく、出力の優先順位を決めるためのものです。結果を出す期限、一度限りか継続的な成果か、取り組みに割ける時間の上限によって、候補リストとルーティンの優先順位を組み替えます（§ 4および§ 7を参照）。ここで質問し、順位付けと同時に質問することは避けてください。その段階では、ユーザーはすでに進める方向を決めています。これら3つの情報をすべて成果物に記録すれば、ウォームスタート時に再質問せずに優先順位を組み替えられます。

ウォームスタートでは、セッションの目標についてだけ質問します。期限、期間、両方の順位付けに影響する取り組みの上限も含め、それ以外はすべて成果物から確認します。

3. タスクのルーティング

明示されたセッションの目標を、以下の各スキルの定義済みスコープと照合します。直近のタスクには、スキルを1つだけ割り当ててください。無理に一致させてはいけません。該当するものがなければ、その旨を伝え、最も近いスキルに無理に当てはめず、該当しない範囲を明示します。

この表は意図的に順位付けされていないため、その状態を維持してください。スコープは一致するかどうかの判定基準であり、比率ではありません。タスクがあるスキルの定義済みスコープに含まれるか、含まれないかのどちらかです。順位付けは次の段階である候補リスト（§ 4）で行います。この段階では、複数のスキルが同じセッションに対して実際に競合します。

スキル	このスキルを使うタスク
mbfinotti/sales-skills@sales-outreach-personalization	見込み客のシグナルから、根拠と新しさを示した優先順位付きのパーソナライズ案を2～3件作成する場合。メッセージ自体は作成しません
mbfinotti/sales-skills@cold-email-subject-line-tester	メールの件名を生成、評価、またはスプリットテストする場合。件名内のスパム誘発語句のみを対象とします
mbfinotti/sales-skills@cold-email-deliverability	コールドメールの草案と送信設定（認証、レピュテーション、本文の仕組み、法令遵守）を扱う場合。「迷惑メールに振り分けられる」問題
mbfinotti/sales-skills@sales-outbound-sequence	タッチごとのケイデンス（チャネル、間隔、停止ルール、再開、対応可能数の計算）を扱う場合。文面そのものは明示的に対象外です
mbfinotti/sales-skills@cold-call-opener	実際のコールドコールの最初の5～30秒（オープナーの型、課題の仮説、単一の依頼、検証可能なバリエーション）を扱う場合
mbfinotti/sales-skills@sales-discovery-questions	1件の商談またはペルソナに対する、順序立てたディスカバリー質問集（課題、根本原因、影響、緊急性）を作成する場合
mbfinotti/sales-skills@sales-objection-handling	表明された反論を診断し、口頭での切り返しを作成する場合（価格、タイミング、競合、決裁権、現状維持）
mbfinotti/sales-skills@meddpicc-scorecard	説明された1件の商談を、証拠の段階に基づいてMEDDPICCの8要素で評価する場合。「この商談を適格性評価する」
mbfinotti/sales-skills@deal-champion-mapping	進行中の1件の商談について、証拠の確度を付けたステークホルダー／権力マップを作成する場合。「実際の意思決定者は誰か」、単一担当者への依存
mbfinotti/sales-skills@deal-red-flags	1件の商談に関する自由記述のメモを確認し、深刻度を付けて適格性評価上の危険信号を特定する場合。メモから「この商談は本物か」を判断する
mbfinotti/sales-skills@deal-value-calc	1件の商談について、ROIとビジネスケースの説明を作成する場合。「価格を正当化する」、何もしない場合のコスト
mbfinotti/sales-skills@negotiation-concession-planner	交渉前の譲歩計画（価格を設定した交換可能な条件、譲歩と見返りの組み合わせ、BATNAに基づく撤退ライン）を作成する場合
mbfinotti/sales-skills@sales-meeting-recap	生の通話メモから、担当者が明確なアクション項目と相互アクションプランを含む、構造化された要約メールを作成する場合
mbfinotti/sales-skills@sales-call-review	1件の通話トランスクリプトを、基準が明確な4部構成の評価基準で採点する場合。営業担当者の自己レビューやマネージャーによる録音レビュー
mbfinotti/sales-skills@sales-motion	PLANNING：販売手法（PLG、営業主導、ハイブリッド、チャネル）を選択する場合、または販売手法間の移行順序を計画する場合
mbfinotti/sales-skills@sales-icp-definition	PLANNING：ICP自体を定義または再導出する場合（企業属性、技術属性、行動基準、除外条件、重み付き適合度評価基準）
mbfinotti/sales-skills@sales-market-sizing	PLANNING：市場規模を算出する場合（TAM/SAM/SOM、ボトムアップ方式での算出、三角測量、妥当性確認）
mbfinotti/sales-skills@sales-account-segmentation	PLANNING：セグメントモデルを設計する場合（適合度×準備度のスコアリング、未開拓領域のマッピング、セグメントごとの販売手法マップ）
mbfinotti/sales-skills@sales-account-tiering	PLANNING：既存の適合度スコアに基づき、ティアの境界、ティア名、対応可能数の上限、ティアごとのカバレッジレベルを設定する場合
mbfinotti/sales-skills@sales-org-structure	PLANNING：組織構造を設計する場合（ポッド、業種別編成、ハンター／ファーマーの分担、SDR:AE比率、マネージャーの担当範囲）。人ではなくポジションを対象とします
mbfinotti/sales-skills@sales-quota-setting	PLANNING：クォータを算出する場合（トップダウンとボトムアップの調整、立ち上がり期間の負担軽減、過剰割り当て、テリトリーの重み付け）
mbfinotti/sales-skills@sales-pipeline-coverage-modeling	PLANNING：クォータ達成に必要なパイプライン規模をモデル化する場合（カバレッジ比率、コンバージョン率からの逆算、ギャップとその調整手段）
mbfinotti/sales-skills@sales-comp-design	PLANNING：報酬プランを設計する場合（基本給と変動給の比率、アクセラレーター、ドロー、スピフ、クレジット付与ルール、ガバナンス）
mbfinotti/sales-skills@sales-hiring	雇用主側：営業職採用の評価基準、面接プロセス、模擬通話の実技課題、30-60-90日の立ち上がり計画を作成する場合
mbfinotti/sales-skills@sales-career	候補者側：営業職での就職とキャリア形成、面接準備、スキルギャップの解消計画、オファー評価を扱う場合
mbfinotti/sales-skills@sales-radar	営業関連の情報源のウォッチリストを作成する場合。何を読んだりフォローしたりすべきか、「営業の最新情報をどう把握するか」
mbfinotti/sales-skills@sales-kickoff	このスキル：プロジェクトの開始、定期チェックイン、「どのスキルが必要か」の確認、適切なスキルへの振り分け

まず抽象度で判断し、次に誰が質問しているかで判断する

ここで起きる衝突のほとんどは、テーマの衝突ではなく抽象度の衝突です。同じ用語が、計画上の判断と、その計画の中で実行されるタスクの両方を指しています。モデル自体が存在しない、または誤っている場合は計画スキルに、モデルは存在し、その中で作業する場合は戦術系の関連スキルに振り分けてください。

• sales-motion はモーションを選び、sales-outbound-sequence はその中で一連のアプローチを実行します。
• sales-icp-definition、sales-account-segmentation、sales-account-tiering はどれも「ターゲティング」のように聞こえますが、順に、誰が条件を満たすか、条件を満たした対象をどう評価・グループ化するか、各グループにどのサービスレベルを提供するかを示します。sales-market-sizing は、この3つが絞り込む市場の規模を算出します。
• sales-quota-setting は目標数値を導き出し、sales-pipeline-coverage-modeling はその数値に対するパイプラインの規模を算出します。どちらも稼働中のパイプラインを監査するものではありません。
• sales-org-structure は役職を定義し、sales-comp-design はその役職における行動に報酬を設定し、sales-hiring はその役職を埋めます。

特定の案件やメッセージについての質問は、どれほど戦略的に聞こえても、計画レベルの質問ではありません。references/skill-routing.md § Boundary pairs には、これらすべての詳細が記載されています。判断が曖昧なタスクを振り分ける前に、参照してください。

sales-hiring と sales-career — このコレクションで最も混同されやすいペアで、同じ役割に関する知識を正反対の立場から扱います。トピックのキーワードではなく、必ず質問者が誰かで判断してください。

• 役職を埋める人（評価基準表、面接プロセス、実務課題、立ち上がり計画）→ mbfinotti/sales-skills@sales-hiring。
• 役職に就く人（面接準備、実績の証拠、オファーの評価）→ mbfinotti/sales-skills@sales-career。

「SDR interview questions」や「30-60-90 plan」のように表現が曖昧な場合は、振り分ける前に質問を1つしてください。「この役割の採用を担当していますか、それともこの役割の面接を受けていますか？」どちらのスキルも対象者が誤っていることを自動検出して、もう一方を案内しますが、最初から適切に振り分ければ、たらい回しを避けられます。

ほかの関連スキルのペアも、キーワードが重複します。各スキルが明示している対象範囲だけを基準に区別してください。あるスキルが「おそらく」何を扱うかという推測で判断してはいけません。誤った区別は、区別しない場合よりも振り分けを誤らせます。境界ペアの区別、計画スキルが明示する対象範囲と除外事項、順序付きの連鎖、名称が明示された対象範囲の欠落については、references/skill-routing.md を参照してください。2つのスキルに該当する可能性があるタスクを振り分ける前に、必ず確認してください。

CRM／パイプラインおよびチャネル／パートナー関連のタスク — 関連リポジトリを推奨し、無理に当てはめない

営業に関連するタスクの中には、漏れているからではなく、意図的にこのコレクションの対象外となっているものがあります。

• CRM／パイプラインの戦術的な業務 — リードの振り分け、リードのスコアリング、多数の商談にわたるパイプラインの整理、CRM データガバナンス、フォーキャストの診断、ステージやディールデスクのプロセス設計、顧客の健全性／解約スコアリング、収益レポート — は sales-skills ではなく、mbfinotti/revops-skills の領域です。
• チャネル／パートナーに関するマクロ戦略の業務 — パートナーエコシステムの設計、チャネルプログラムの構成、共同販売のルール、アライアンスやマーケットプレイスの戦略 — ならびにアフィリエイト、インフルエンサー、紹介プログラムの運用 — は mbfinotti/partnerships-skills の領域です。

最も近い sales-skills のスキルを無理に当てはめるのではなく、関連リポジトリのインストールを推奨してください。たとえば、「これは営業の実行ではなく、CRM／パイプラインの業務です。mbfinotti/revops-skills に適したスキルがあるかもしれないので、そのコレクションのインストールをご検討ください」のようにします。あくまで推奨にとどめ、依存関係にはしないでください。sales-skills は単独で完全に利用でき、案内先が示されるのは両コレクションが mbfinotti を所有者として共有しているからです。タスクとスキルの対応関係の全容は、references/skill-routing.md の「関連リポジトリの推奨」を参照してください。

タスクに必要なスキルがこのコレクションにも、上記の関連リポジトリ 2 つにもない場合は、その不足を明示してください。コレクション v1 には、次の専用スキルがありません。

実行側：

• ボイスメールのスクリプト
• 冒頭部分とディスカバリーパートを超える、通話全体のトークトラック
• 継続的なコーチング計画
• ソーシャルセリングと担当者のパーソナルブランディング
• 営業手法の選定
• 見込み顧客リストの作成
• 提案書や契約書の作成
• 担当者のマインドセットに関する取り組み

計画側：

• テリトリー分割の方法論
• 担当者の対応能力と人員数のモデル化
• 競合に対するポジショニング

「このタスクに対応するスキルはコレクションにありません」と伝えてください。スキルが存在すると約束したり、作り出したりしてはいけません。

4. 出力形式

毎回、ルーティング結果を次の形式で提示してください。

1. 状態の要約（ウォームスタートの場合のみ） — アーティファクトから次の 5 行をそのまま記載します。モーション、担当者とチームの構成、進行中の業務、最優先の未決事項、現在の制約。
2. ルート — 直近のタスクに適したスキルを 1 つ（または「適合するスキルなし」と、不足しているものの明記）。
3. 候補リスト — 今すぐこのプロジェクトに関係するスキルを 5～8 個、1 つの階層のみから選びます（セッションの高度に応じて、実行または計画）。価値に対する作業量の比率が高い順に並べます。各項目は 1 行で、対応するボトルネックとセッションにかかるコストの両方を示します。安さを基準に並べたり、ルーティング表の行順に並べたりしてはいけません。以下の「候補リストの並べ方」を参照してください。
4. 連鎖 — タスクが実際に順序のある一連の作業に分解される場合（例：sales-outreach-personalization → cold-email-subject-line-tester → cold-email-deliverability → sales-outbound-sequence）、実行順に、次のリンクに引き渡すものを各リンク 1 行で示します。連鎖の順序は依存関係に基づく順序であり、効率の順序ではありません。後続のリンクは先行するリンクより先に実行できないため、連鎖を順位付けしても意味はありません。連鎖がない場合は省略し、決して一連の作業を捏造してはいけません。
5. 今は対象外 — 後で重要になるスキルを、それぞれ利用可能になる明示的な条件とともに示します（例：「sales-call-review — 評価対象となる最初の録音済み通話が用意できたら」）。
6. 不足 — 今日のタスクに必要で、どのスキルにも対応していないものを不足として記載します。

候補リストの並べ方

その時点でユーザーが尋ねているのは、「どのスキルが存在するか」ではなく、「どれを最初に実行すべきか、そしてそのセッションに価値があるか」です。この問いに答えられるのは比率だけです。何かを順位付けする前に、セッションの高度に合った階層を選んでください。以下の実行階層か、その後に続く計画階層のいずれかです。両方を 1 つのリストに混ぜてはいけません。四半期にわたる意思決定と午後の作業を同じ比率で比較すると、上位の枠がすべて午後の作業で埋まってしまいます。

実行階層 — 既定のクラス順。価値に対する作業量の比率が高いものから並べます。

1. チャネルの健全性 - cold-email-deliverability。送信したメールが実際に届くかどうかを改善するため、以降のすべてのアウトバウンド指標に意味が生まれます。認証と送信者の評判に関する作業に数時間かかりますが、その大半は一度きりです。ただし、DNS レコードを管理するのは営業担当者ではなく、ドメインの所有者です。
2. 案件のトリアージ - deal-red-flags、meddpicc-scorecard、deal-champion-mapping。感覚ではなく、案件が実在するのかしないのかについて、明確な理由を得られます。すでに手元にあるメモや連絡先データを使って1回のセッションを行うだけで、案件には何も変更を加えません。それこそが、四半期の目標を見込みのない案件に費やさないための方法です。
3. 再利用可能な構成 - sales-outbound-sequence、sales-discovery-questions、negotiation-concession-planner、deal-value-calc。以降のすべてのやり取りの枠組みを作ります。何日にどの接点を設けるか、何を尋ねるか、何を譲歩できるか、案件にどれだけの価値があるかを決めます。それぞれ1回のセッションで作成し、同じペルソナのすべての見込み客や案件に再利用できます。
4. メッセージと実際の通話のアセット - sales-outreach-personalization、cold-email-subject-line-tester、cold-call-opener、sales-objection-handling、sales-meeting-recap。このコレクションで最も大きな成果である、アポイントの獲得と案件の進展につながりますが、終わりはありません。見込み客のグループ、通話、会議ごとに取り組みます。一度きりの修正ではなく、継続的な業務です。
5. レビュー - sales-call-review。上記の取り組みが成果につながったか、録音を根拠に確認できます。実際の文字起こしを読み、その後にコーチングの会話を行う必要があります。録音された通話があり、判定結果に基づいて行動する責任者がいるまでは、何の成果も得られません。

sales-hiring、sales-career、sales-radarは、この優先順位の最下位ではなく、その対象外です。これらが扱うのは人材に関する問いや最新情報を把握するための問いであり、パイプラインに関する問いではありません。セッションの目標がそれらに_ある_場合は、定義上それが第1段階になります。それ以外の場合は、候補リストに含めるべきではありません。

各評価軸の順位は一致しません。そのため、選択が難しくなります。

• 効率：チャネルの健全性 > 案件のトリアージ > 再利用可能な構成 > メッセージと通話のアセット > レビュー
• 価値：メッセージと通話のアセット > 再利用可能な構成 > 案件のトリアージ > チャネルの健全性 > レビュー
• 労力：メッセージと通話のアセット > 再利用可能な構成 > チャネルの健全性 > 案件のトリアージ > レビュー
• コンプライアンスコスト：メッセージと通話のアセット > チャネルの健全性 > レビュー > 再利用可能な構成 > 案件のトリアージ（なし） - 大規模なアウトリーチには適法な根拠と配信停止の手段が必要です。また、B2C の通話では、発信禁止リストとの照合が必要です。いったん送信したメールや発信した通話は取り消せません。送信設定には、その地域で求められる送信者の特定要件と配信停止要件が伴い、毀損したドメインの評判を回復するには数週間かかります。通話を評価するには録音への同意が必要であり、顧客自身の発言を記録します。条件を譲歩するには、その承認権限を持つ人の許可が必要です。案件のトリアージはすでに保管されているメモを読むだけで、何も引き起こしません。

労力では、チャネルの健全性が案件のトリアージより上位です。作業量は少ないものの、DNS レコードは営業チームの管理外にあるため、承認と待ち時間が必要です。一方、トリアージでは営業担当者がすでに持っている情報を読み取ります。

価値ではメッセージと通話のアセットが首位ですが、最上位の枠には入りません。成果は見込み客ごとに得られ、次々と対応が必要になるからです。この点が、効率重視の順序で見落とされる部分でもあります。第4クラスだけがアポイントを獲得したり案件を進展させたりするため、比率を優先するコレクションでは、実際にうまくいっていない冒頭のトークを誰も書き直さないまま、送信設定の監査ばかりを繰り返すことになります。ボトルネックの回答（Q4）が「アポイントが取れない」または「会議が成果につながらない」であれば、第4クラスをそのまま第1段階に引き上げてください。

デフォルトでは、面談で未解決のまま残った最上位クラスから候補リストを始め、到達率に関する兆候がある限り、チャネルの健全性より下位には移りません。上位クラスが整ってから、次のクラスに進みます。

対象外と判断したクラスは候補リストから削除してください。最下位に移すだけではいけません。対象外のスキルをリストの末尾に残すと、対象範囲にいつの間にか再び含まれてしまいます。

• 解決条件が明示されている場合：「今は見送り」リストに移し、その条件も引き継ぎます。
• 解決条件がない場合：一切言及しません。

この順序は基本形であり、絶対ではありません。案件の動きや、誰が実行するかによって変わります。面談と検出パスで判明したことを踏まえて順位を付け直し、どの回答によってどのクラスが動いたのかを明言してください。

• コールドアウトバウンドを行わない方針（Q1b、インバウンドまたはフルサイクルのAE）なら、クラス1とクラス4のコールドアウトリーチ分である sales-outreach-personalization、cold-email-subject-line-tester、cold-call-opener を候補リストから完全に削除します。
• 「営業職を採用している」または「営業職の面接をしている」（Q2e/f）なら、sales-hiring または sales-career を第1段階に上げ、このセッションの候補リストからすべてのパイプライン関連クラスを削除します。
• 「商談がサイクルの途中で停滞する」または「交渉やクロージングで負けている」（Q4）なら、クラス2を第1段階に固定し、クラス3から negotiation-concession-planner と deal-value-calc を引き上げます。
• クォータの期限または四半期末まで2週間を切っている（Q5a）なら、その期間内に効果が出るクラス2と4を上げ、効果が出るまで四半期を超えるものは、期限を解決条件として「今は見送り」に下げます。
• ドメインまたは送信者のレピュテーションに問題がある（Q5b）なら、セッションでほかに何が優先されていても、クラス1を第1段階に固定します。
• 規制対象のアウトリーチ（Q5c）では、クラス1と4に同意取得と通話拒否リストの確認を追加します。これにより所要時間は延びますが、得られる成果は変わりません。
• CRM または通話録音にアクセスできない（Q5d）場合は、sales-call-review を「今は見送り」に移し、最初の通話録音を解決条件とします。また、商談のトリアージは手作業でのメモ確認に切り替えます。
• 「単発で、使える時間は数時間のみ」（Q6）なら、候補リストをクラス1〜2から2項目に絞ります。「継続的に効果を高められ、人員を確保できる」（Q6）なら、クラス3と4を基本の位置より上げます。
• 決定済みの項目（Q7）は、そのスキルを候補リストから完全に削除します。対象外のものに順位を付けないでください。
• 検出結果によってクラスも動きます。git log に何か月も停滞している形跡があれば商談のトリアージが有力です。通話録音がすでにインベントリにあれば、クラス5は即日着手できる作業です。文書化されたICPと稼働中の営業活動の計画がディスク上にあれば、クラス3の該当項目を削除します。
• セッションの目標が計画策定レベルにある場合（Q3、Q4fの「ファネルの上位にある計画」、またはQ2c/dのリーダー職）、この段階分けを下記の計画策定向けのものに置き換えます。両者を決して統合しないでください。

計画レベルのショートリストの順位付け

計画スキルは実行の階層が動く枠組みを決めるため、それぞれ独自の価値対工数比で順位付けします。デフォルトのクラス順は、価値対工数比が高い順です。

1. 枠組み - sales-icp-definition、sales-motion。誰に、どのように販売するかを決め、その内容は以下のすべての数値に引き継がれます。それぞれワークショップが1回必要です。ここを誤ると、後続のすべてのモデルが精密でありながら誤ったものになります。
2. 市場の形状 - sales-account-segmentation、sales-account-tiering、sales-market-sizing。スコア付け、グループ分け、順位付けされたアカウント全体と、各グループのカバレッジレベルを得られます。それぞれ数日から1、2週間かかり、その大部分はすでに保有しているデータを使います。
3. 数値 - sales-quota-setting、sales-pipeline-coverage-modeling。現場が達成責任を負える目標と、それが必要とするパイプラインを設定します。計画サイクルが必要で、枠組みが定まるまでは何の価値もありません。
4. 人員と報酬 - sales-org-structure、sales-comp-design。全体を実行するための組織構造とインセンティブを整えます。組織再編または報酬制度の再設計が必要で、元に戻すのが最も困難です。

• 効率性：枠組み > 市場の形状 > 数値 > 人員と報酬
• 価値：人員と報酬 > 数値 > 枠組み > 市場の形状
• 工数：人員と報酬 > 数値 > 市場の形状 > 枠組み
• コンプライアンスコスト：人員と報酬 > その他すべての計画クラス（なし） - 組織構造の変更では報告系統が変わり、従業員代表が適用される場合は発表前に協議が必要です。報酬制度の変更では、HR と法務が関与するなかで契約を再締結する必要があり、期中の変更はガバナンス上の例外となります。ほかの3つは、誰も署名しない社内文書を作成するだけです。

効率性の順位は人員と報酬を後回しにします。価値は最高、工数も最大で、最も元に戻しにくいにもかかわらず、比率優先のプランナーは報酬プランが誤った行動に報いるあいだ、ICP を何度も再定義し続けます。営業担当者がICPの対象外のアカウントでノルマを達成した場合、またはモーションやセグメントモデルの変更直後には、優先度を上げてください。両方を変更する場合は、組織再編より先に報酬制度を再設計します。

デフォルトでは、インタビューで未解決のまま残った最上位クラスから開始し、ICP またはモーションが議論中であるかぎり、枠組みより下位から始めないでください。削除ルールは実行の階層と同じです。回答に基づいて順位を付け直し、何が変わったかを明示してください。

• 数週間以内の厳しい期限がある場合、計画サイクルが必要なクラス3と4の優先度を下げます。
• 「複利的な成長、採用枠あり」（Q6d）の場合、クラス4の優先度を上げます。
• 成約実績がない場合、最初の四半期のデータが揃うまで、ノルマとカバレッジの項目を削除します。

5. コンテキストアーティファクト

プロジェクトのルートに sales-context.md を作成または更新します。プロジェクトが git で管理されている場合は、プロジェクトとともにコミットする、バージョン管理されたファイルを 1 つだけ用意します。これが、次回の開始をスムーズにする唯一の信頼できる情報源です。次の項目を記載します。

• 販売活動の進め方
• シート数とチーム構成
• ICP とオファーに関する事実
• 現在のファネルのボトルネック
• 進行中の作業
• 決定済み事項と未決事項
• 制約（結果をいつまでに出す必要があるかを含む）
• 単発と複利効果を見込む場合の時間軸、および作業量の上限
• 意思決定における役割を含むステークホルダー
• セッションログ

最後の 3 項目（制約、時間軸と作業量の上限、ステークホルダー）があると、質問 5 と 6 を再度尋ねることなく、スムーズな再開時に候補リストと定期タスクの優先順位を付け直せます。テンプレート、記入例、避けるべき例については references/context-artifact.md を参照してください。

• スムーズに再開するときは、読み込むだけにして、作り直さないでください。5 行の状態サマリーを作成し、セッションログに 1 行追加して、変更された項目だけを更新します。
• 必要に応じて、プロジェクトの不変条件（販売活動の進め方、ICP、最低価格、厳守すべき制約）をプロジェクトのエージェント指示ファイルに追加し、今後の各セッションでこのスキルを読み込まなくても引き継げるようにします。
• プロジェクトに見合っていない作業ツリーを整備しないでください。このセッションに必要なものだけを整備します。時期尚早な構造化は、プロジェクトでまだ決まっていない事項を固定化してしまいます。
• 意思決定ログを残すのは、プロジェクトで実際に意見が分かれる決定が積み重なっている場合だけにします。それ以外の場合は、「決定済み事項と未決事項」の項目で十分です。実態のない形式的なログは古び、アーティファクトへの信頼を損ないます。

セッションの終了前に、毎回アーティファクトを更新します。記録されていないセッションは、次回にはコールドスタートになります。

6. メモリ

ハーネスに永続メモリがある場合は、コンテキストアーティファクトをもとにメモリエントリーを作成し、逆の順にはしないでください。メモリはチームメイトから見えず、確認もできないため、アーティファクトが唯一の信頼できる情報源であり続けます。メモリを先に扱うフローでは、ユーザーごとにプロジェクトの状態が分岐してしまいます。

• インタビュー完了後、§ 4 の出力形式に進む前に、回答をメモリに保存します。まず記録した回答をコンテキストアーティファクトに書き込み、次にそのアーティファクトをもとにメモリエントリーを作成します。回答から直接メモリに書き込んだり、回答が明白に思えたからといってアーティファクトを省略したりしてはいけません。
• メモリの保存先は、ユーザー環境内、チームのナレッジベース、git リポジトリ内の memories/ ディレクトリのいずれか 1 つだけにします。各エントリーを 1 行で説明するフックを記載したインデックスファイルで、メモリにインデックスを付けます。
• スムーズに再開するときは、メモリとアーティファクトの差分を確認します。内容が食い違う場合は、調整を提案します。デフォルトではアーティファクトを優先しますが、どちらかを上書きする前に確認してください。
• 次の情報は、メモリに保存してはいけません。個人を特定できる情報、CRM レコードに含まれる見込み客または顧客の個人識別情報、通話の録音や文字起こしの内容、契約上の価格、割引の下限、ノルマやコミッションの数値です。メモリに最初に書き込む際は、この除外事項を明記してください。
• メモリが git リポジトリにある場合、決して黙ってコミットしてはいけません。毎回、差分を提示して、承認を得てください。

7. 定期タスク

ハーネスがスケジュール設定された定期タスクに対応している場合は、2〜4 件を提案します。何かを作成する前に、必ずドライランとしてユーザーに提示し、それぞれに明確な出力先を指定してください。出力先のない定期タスクは雑音となり、ユーザーは 1 週間以内に通知を止めてしまいます。

• コスト：設定にかかる手間ではなく、実行のたびに費やす注意の量に、実行頻度を掛けたものです。
• 価値：決定がまだ可能なうちに、誰かに判断を促すことです。

候補をその比率で高い順に並べ、上から順に提案します。

1. 予測前の案件点検 → mbfinotti/sales-skills@deal-red-flags。営業担当者がその商談に向けていずれにせよまとめるコミット一覧を一度確認するだけで済み、数字が確定する前に偽の案件を数字から除外できる唯一の定例ルーティンです。予測会議の前日を基準にし、会議の後には決して実施しないでください。
2. 確定したタッチ回数でのシーケンス確認 → mbfinotti/sales-skills@sales-outbound-sequence。実行ごとのコストはほぼゼロで、ケイデンスをまだ変更できる期間内に継続か停止かを判断できます。一定の時間間隔ではなく、シーケンスごとに一度実行します。
3. このキックオフの月次または四半期ごとの再実行。 コストはほぼゼロで、成果物とルーティングを最新の状態に保てます。これにより、ほかのすべてのルーティンが、すでになくなった作業に対して実行されるのを防ぎます。git logからプロジェクトのペースを把握し、それに合わせて実行頻度を決めます。
4. 月次の送信設定チェック → mbfinotti/sales-skills@cold-email-deliverability。毎月、認証とレピュテーションのシグナルを確認するコストがかかります。設定が健全な間は得るものがありませんが、問題がある月には四半期全体を守れます。カレンダーに合わせるのではなく、送信量の増加を予定する前に実施します。
5. 録音した通話1件の週次レビュー → mbfinotti/sales-skills@sales-call-review。実行ごとのコストが最も高く、実際の文字起こしの確認に加え、その後のコーチングの会話も必要です。また、マネージャーや同僚がそれに基づいて行動しなければ、評価結果には価値がありません。通話を録音しており、コーチングの担当者がいる場合にのみ導入してください。
6. 四半期ごとの情報源の更新 → mbfinotti/sales-skills@sales-radar。年に4回、コストがほぼゼロの実行で、成果ではなく情報の最新性を保ちます。

• 効率性：deal inspection > sequence checkpoint > kickoff re-invocation > sending-setup check > tape review > source refresh
• 価値：deal inspection > tape review > sending-setup check > sequence checkpoint > kickoff re-invocation > source refresh
• 労力：tape review > deal inspection > sending-setup check > sequence checkpoint == kickoff re-invocation == source refresh
• コンプライアンスコスト：tape review > every other routine (none) - 文字起こしには、通話時に得た録音同意の条件のもとで顧客自身の言葉が含まれます。そのため、出力先はその同意の根拠とチームのデータポリシーの両方で許可されている必要があります。ほかのルーティンが出力するのは、社内向けの案件や設定の要約です。

労力が3つ同率なのは、実際にそうだからです。どれも一度の確認で済む、コストがほぼゼロの作業で、実行頻度は低く、確認する本人以外の人手も必要ありません。

情報源の更新は最も安価な候補ですが、導入する順番は最後です。安価さと効率性が異なる順序であることを最も明確に示しています。通話レビューは価値で2位、効率性で5位です。週次の確認と会話にコストがかかる一方、そこで得られる行動変化が現れるのは、その後の通話です。

デフォルトは1～3段階で、3つのルーティンです。アウトバウンドメールの送信量が無視できない規模になったら第4段階を追加し、第5段階は通話を録音していて、コーチングの担当者がいる場合にのみ追加します。4つを超えてはなりません。この上限によって、重要なルーティンが成果につながらない作業に埋もれるのを防ぎます。

この順位付けはデフォルトであり、絶対的なルールではありません。営業の進め方や、誰が実行するかによって変わります。インタビューの内容を踏まえて順位を付け直し、どの回答によって何が変わったかを説明してください。

• 「商談の機会を得られていない」（Q4）場合、シーケンスの確認と送信設定のチェックを、案件点検より上位にします。
• ノルマの期限まで2週間を切っている（Q5a）場合、案件点検だけを導入し、四半期が終わるまでほかは導入しません。
• 送信者のレピュテーションに問題がある（Q5b）場合、問題が解消するまで送信設定のチェックを週次にします。
• 規制対象のアウトリーチ（Q5c）では、出力先が録音同意の根拠に照らして許可されるまで、通話レビューを導入しません。
• CRMまたは通話録音にアクセスできない（Q5d）場合、通話レビューを完全に除外します。
• 「一度限りで、数時間だけ」（Q6）の場合、ルーティンは4つではなく、キックオフの再実行を1つだけ導入します。
• マネージャーがすでに週次で通話レビューを実施している場合、第5段階は重複するため、同じ通話を二重に評価するのではなく、順位を下げます。 トリガーは、都合のよい任意の日付ではなく、週次のパイプライン会議や予測会議、月末、四半期末、チームの定例レビュー日など、営業カレンダーに合わせて設定してください。新しいルーティンを追加する前に、前四半期から残っている古いルーティンを洗い出して整理してください。

ハーネスにスケジュール済みルーティンがない場合は、繰り返しのカレンダーリマインダーを1つだけ設定してください（「営業チェックイン - 営業キックオフを再実行」）。それ以上は追加しないでください。ドライランの形式、トリガーの設定、イベントトリガーの優先、クリーンアップのチェックリストについては、references/routines.md を参照してください。

8. 呼び出し例

• 「SaaS向けの新しいアウトバウンドプロジェクトを始めて。」
• 「どの営業スキルが必要ですか？デモの後、商談がいつも停滞します。」
• 「営業チェックインを実行して。」
• 「何から始めればよいですか？創業者ですが、コールドアウトリーチの経験がありません。」

9. 失敗パターン

• 無理にスキルを当てはめる。 最も近いスキルを対象外のタスクに無理に当てはめると、セッションが無駄になり、対応できない領域が見えなくなります。「該当するものはありません」と伝え、その領域を明示してください。
• CRM／パイプラインやチャネル／パートナー関連のタスクを無理に当てはめる。 リードの振り分け、リードスコアリング、パイプラインの整理、CRMデータガバナンス、予測は mbfinotti/revops-skills の領域です。パートナー／チャネル戦略や、アフィリエイト／インフルエンサー／紹介の運用は mbfinotti/partnerships-skills の領域です。代わりに、該当する兄弟リポジトリを案内してください。
• 異なる階層間でルーティングする。 「ノルマが適切ではない」「ターゲットにするアカウントを間違えている」「この商談が停滞している」は似て聞こえますが、3つの異なる階層の課題です。キーワードを照合する前に階層を見極め、計画スキルと実行スキルを1つのランキング付き候補リストに混在させないでください。
• キーワードで採用／キャリア関連のルーティングをする。 「面接の質問」や「30-60-90」は、どちらの立場にも当てはまります。質問者が誰かでルーティングし、不明な場合は、判別に必要な質問を1つだけしてください。
• 前提を把握した状態で開始したのに、もう一度質問する。 成果物が存在するのは、質問の重複を避けるためです。今回のセッションの目標だけを尋ねてください。
• 推測したスコープに基づいてルーティングする。 ルーティングは references/skill-routing.md に明記されたスコープに限ってください。もっともらしい推測に基づくと、自信を持ったまま誤ったルーティングをしてしまいます。
• インタビューの質問数に上限を設けない。 7問を超えると、キックオフがユーザーの離脱するフォームになってしまいます。不足を補うのは質問ではなく、検出です。
• 出力先のないルーティン。 何もないところに通知されて無効化され、本当に重要なルーティンまで埋もれてしまいます。
• 平坦な候補リスト。 選択肢の優先度が同じに見えると、好みや先頭の項目で選ばれてしまいます。労力あたりの価値で並べ、各行で両方の側面を明示してください。
• 最も安価な選択肢を最初に提示する。 安価であることと効率的であることは並び順が異なります。「何から始めるか」に答えられるのは後者だけです。ほぼコストゼロでも、得られる価値がほぼゼロのルーティンやスキルは、簡単に成果を得られる手段ではなく、端数誤差にすぎません。
• 除外したスキルを削除せずに候補リストの末尾へ移す。 インタビューで対象外と判断されたスキルを候補リストの末尾に残すと、2セッション後にはスコープとして再登場します。削除するか、「今は対象外」に移して、再検討の条件を明記してください。
• メモリへの反映を黙って行う。 反映された内容が見えなければ、チームメイトはレビューできません。必ず差分を提示し、承認を得てください。
• ルーティング表が古い。 コレクションに変更があったときは、スキルが追加、改名、削除、またはスコープ変更された場合も含め、このスキルの表、references/skill-routing.md、境界となる組み合わせ、連携順、ギャップ一覧を更新してください。古いルーターは、存在しなくなったスキルにユーザーを案内してしまいます。

10. 合格基準

セッションを終了する前に、すべての項目を確認してください。1つでも満たしていない場合は修正して再確認し、基準を満たさないままセッションを終了しないでください。

1. 推奨するすべてのスキルについて、宣言されている適用範囲が提示されたタスクと一致していることを確認してください。説明を読み直して確認します。
2. 上記の表にある27個のスキル以外の名前へのルーティングがゼロであること。
3. 採用とキャリアのどちらにルーティングするかは、トピックのキーワードではなく、誰が質問しているかに基づいて決定されていること。
4. 面接の質問数が上限内であること。コールドスタートでは最大7問、ウォームスタートではセッションの目標に関する質問のみとします。
5. セッション終了前に、セッションログの行を含む sales-context.md が作成または更新されていること。
6. 提案したすべてのルーチンについて、ドライランを提示し、明示的な出力先を指定していること。
7. CRM／パイプラインまたはチャネル／パートナーに関するタスクでは、無理にルーティングしたり、一律に「適合するスキルなし」としたりせず、mbfinotti/revops-skills または mbfinotti/partnerships-skills を推奨していること。
8. ショートリストとルーチンのセットが、どちらも労力あたりの価値が高い順に並べられていること。各項目で、対処するボトルネックと必要なコストを明示し、面接の回答によって順位を変更した場合は、そのたびに変更内容を声に出して説明していること。
9. 面接で対象外と判断したクラスは、ショートリストの最下位に残すのではなく、ショートリストから完全に除外していること。
10. ショートリストは、セッションの抽象度に基づいて選んだ実行または計画のいずれか一方の階層だけで構成し、もう一方の階層のスキルを含めていないこと。

参照資料

• references/skill-routing.md — 両方の抽象度にまたがる境界ペアの区別、計画スキルの適用範囲と除外事項、順序付きチェーン、カバレッジの欠落、関連リポジトリの推奨事項。曖昧なタスクをルーティングする前に読んでください。
• references/context-artifact.md — 成果物のテンプレート、具体例1件、否定例1件。
• references/routines.md — ドライランの形式、セールスカレンダーのトリガー設定、イベントトリガー、クリーンアップのチェックリスト。