deal のコンテキスト（closed-won の商談、SOW、ディスカバリーコールのメモ）を、担当者が明記され、契約開始日に紐づいた目標日と明示的な time-to-value（TTV）ゴールを持つマイルストーンベースのオンボーディング計画に変換する Claude Skill です。output は構造化された Markdown 計画と、Rocketlane のプロジェクトインポートにきれいにマッピングされるマイルストーンの CSV で、CSM は「deal が成約したばかりで計画がない」状態から、空のテンプレートを眺める代わりに数分でキックオフ準備が整った draft へと進めます。artifact の bundle には SKILL.md と、オンボーディングチームが一度適応させてすべての新規アカウントで再利用する 3 つのリファレンスファイルが含まれます。
使うとき
あなたは成約したばかりのアカウントを引き継ぎ、キックオフコールに持ち込む計画が必要な CSM またはオンボーディングマネージャーです。deal のコンテキストは存在します（署名済みの SOW または order form があり、AE がハンドオフのメモを残し、おそらくディスカバリーコールの transcript もある）。しかし誰もそれを担当者と日付を持つ順序立った計画に変換していません。この Skill がその変換を行います。オンボーディングがセグメント別にテンプレート化されており（SMB には標準の 30/60/90 motion、enterprise にはより長いフェーズ別のロールアウト）、作業がそのテンプレートをこの特定のアカウントの scope、連携、ステークホルダーに適応させることである一般的なケース向けに作られています。
SOW が具体的な成果物を明記し、契約開始日が分かっており、どのオンボーディングテンプレート（セグメント、製品エディション、デプロイメントタイプ）が該当するかを伝えられるときに、最も有用な output を生みます。その 3 つを与えれば、起草するのではなく編集する計画が返ってきます。これは意図的に beginner レベルの Skill です。最初の計画を得るのに API の配線は不要で、deal のコンテキストを Claude に貼り付ければ計画と CSV が返ってきます。Rocketlane へのインポートは、マイルストーンを手作業の再入力なしに PSA へ入れるオプションのラストワンマイルです。
使わないとき
人間のチェックなしに Rocketlane のプロジェクトを自動作成するために使ってはいけません。この Skill は draft の計画を書きます。コミットメントは CSM が所有します。Skill が契約開始日から計算する目標日は出発点であり、顧客への約束ではありません。CSV をレビューなしに Rocketlane と顧客向けポータルへ直接押し込む CSM は、delivery チームが一度も合意していない日付を出すことになります。
SOW も scope の定まった成果物リストもないアカウントには使ってはいけません。1 行の order form から生成される計画は、アカウント名を貼り付けただけの汎用テンプレートであり、テンプレートから直接始めた方が良いでしょう。Skill はこれをフラグします。deal のコンテキストに含まれる具体的な成果物が 3 つ未満の場合、SCOPE_TOO_THIN 通知と素のテンプレートを返し、もっともらしく読めるが誰も scope に入れていない作業にチームをコミットさせるマイルストーンをでっち上げることはしません。
renewal や拡大の計画立案には使ってはいけません。それらは新しい SOW ではなく利用状況と success plan の進捗で駆動され、ここのマイルストーンロジックはグリーンフィールドの実装を前提としています。継続的な health と拡大については、関連する artifact はこれではなく customer health score と拡大シグナル検出の workflow です。
キックオフ会話の代替として使ってはいけません。計画はキックオフへの input であり、そこで顧客が担当者、日付、順序を確認します。その確認を飛ばす計画は、顧客が一度も合意していない計画です。
セットアップ
初回はおよそ 30〜45 分で、そのほとんどは 3 つのリファレンスファイルをチームのオンボーディング motion に適応させることに費やされます。その後は、新しい計画ごとに貼り付けて実行するだけです。
- Skill をインストールする。
apps/web/public/artifacts/onboarding-plan-generator-skill/の bundle を~/.claude/skills/onboarding-plan-generator/に配置します。SKILL.md は 1 つのエントリ動作（deal のコンテキストとテンプレート名を与えると計画を生成する）と、parsing および日付計算のヘルパーを定義します。コアフローに認証情報は不要です。 - マイルストーンテンプレートを適応させる。
references/1-onboarding-templates.mdを開き、サンプルテンプレートを実際のものに置き換えます。少なくとも 2 つ用意してください。短い SMB motion と、フェーズ別の enterprise motion です。各テンプレートはフェーズのリスト、各フェーズ内のマイルストーン、マイルストーンごとのデフォルト担当者 role（CSM、onboarding-manager、customer-champion、solutions-engineer）、契約開始日からのオフセット（日数）です。Skill が目標日に変換するのはこのオフセットです。一度正しく設定すれば、すべての計画がそれを継承します。 - 担当者ロスターを定義する。
references/2-owner-roster.mdを開き、担当者 role をチームでの呼称にマッピングし、顧客側の担当者を解決するルール（通常は「SOW に明記された economic buyer」またはハンドオフメモの「プロジェクトスポンサー」）を加えます。Skill はすべてのマイルストーンに担当者 role を割り当てます。このファイルは role が名前付きの人物になる方法です。 - TTV の定義を設定する。
references/3-ttv-definition.mdを開き、テンプレートごとに、あなたの製品にとって「time to value」が何を意味するか（最初の価値となる特定のマイルストーン: 最初の連携が稼働、最初のレポートが提出、最初のチームが完全にプロビジョニング）を宣言します。Skill はそのマイルストーンを計画内でマークし、TTV の目標日を計算するので、キックオフは感覚ではなく数値を持てます。 - 1 つのアカウントで実行する。 deal のコンテキスト（SOW のテキストまたは要約、契約開始日、AE のハンドオフメモ、テンプレート名）を、Skill を有効にした Claude に貼り付けます。Markdown 計画と
onboarding-plan.csvが返ってきます。オプションの Rocketlane インポートでは、Rocketlane でプロジェクトを開き、Import を選び、CSV の列（milestone、phase、owner_role、target_date、is_ttv_milestone）を Rocketlane のタスクフィールドにマッピングします。リファレンスファイルの列名はすでに Rocketlane のインポート schema と一致しています。
Skill が実際に行うこと
Skill は 2 パスで実行します。scope の抽出と計画の構築は別の仕事であり、それらを統合すると成果物をハルシネーションする計画が生まれるからです。パス 1 は抽出です。Claude は deal のコンテキストを読み、具体的な成果物、明記されたステークホルダーとその role、契約開始日、SOW がすでにコミットしている明示的な日付や制約（go-live 日、ペナルティ付きの契約マイルストーン）を抽出します。これを内部の scratchpad に書き、成果物を数えます。数が 3 未満なら、ここで停止し SCOPE_TOO_THIN と素のテンプレートを返します。これは薄い order form を自信ありげに見えるがでっち上げの計画に変えることへのガードです。
パス 2 は構築です。Claude は references/1-onboarding-templates.md から選んだテンプレートを取り、抽出した成果物をテンプレートのフェーズに重ね、各マイルストーンに references/2-owner-roster.md から担当者 role を割り当て、各マイルストーンの日数オフセットを契約開始日に加えて目標日を計算します。SOW が明示的な日付にコミットしている箇所では、その日付が計算されたオフセットを上書きし、Skill はそのマイルストーンを契約上固定としてフラグするので、CSM が安易に動かすことはありません。references/3-ttv-definition.md の TTV マイルストーンがマークされ、その目標日はキックオフの見出しの数値として計画の最上部に出されます。
抽出を構築から分離することが重要なのは、QBR Skill が synthesis を slot マッピングから分離するのと同じ理由です。単一パスでは最後に読んだ input を過大に重み付けし、日付が scope からずれる計画を生みます。2 パスは scope 抽出を正直に保ち、日付計算を決定論的に保ちます。
output はフェーズ別にグループ化された Markdown 計画で、マイルストーンテーブル（マイルストーン、担当者 role、目標日、TTV フラグ、出所 — テンプレート対 SOW-コミット）と 1 行の TTV 要約、そして Rocketlane インポート向けの形をした兄弟ファイル onboarding-plan.csv を持ちます。CSM はキックオフの前に必ず編集します。Skill は draft エンジンであり、プロジェクト作成ツールではありません。
コストの実際
1 つの計画はおよそ 6,000〜15,000 input トークン（その大半は SOW とハンドオフメモ）と 2,000〜4,000 output トークンを Claude Sonnet で消費します。現在の Sonnet 価格で 1 計画あたり 3〜6 セントといったところです。完全なディスカバリー transcript を伴う長い enterprise の SOW は上限近くに着地し、メモが 1 段落の引き締まった SMB の order form は大きく下回ります。実時間は 1 分未満です。コアフローに外部 API 呼び出しがないため、設計で回避すべき rate-limit の上限はありません。
オンボーディング計画をゼロから作る CSM（SOW を読み、成果物をテンプレートにマッピングし、担当者を割り当て、日付を計算する）は、通常 1 アカウントあたり 30〜60 分を費やします。Skill はそれを 5〜15 分（編集パスとキックオフ準備）にします。月に 8〜12 件の新規アカウントを立ち上げるオンボーディングマネージャーにとって、それは月あたり 6〜10 時間程度の回収であり、さらに重要なのは、計画が各人独自のテンプレートではなく CSM 間で一貫することです。
成功指標
2 つの数値を追跡します。第一に、「deal closed-won」から「キックオフ計画完成」までの時間です。Skill は使用開始から最初の 1 か月で中央値を 1 営業日未満に引き下げるはずです。以前これを 3〜5 日も滑らせていたチームほど、オンボーディングが早く始まるため最大の TTV 改善を見ます。第二に、生成されたマイルストーンのうち CSM の編集パスを生き残る割合です。70% 以上を目指します。それを下回る場合、references/1-onboarding-templates.md のテンプレートがチームの実際のオンボーディング方法と一致しておらず、修正は Skill ではなくテンプレートです。90% を超える場合、CSM はおそらく編集不足で、計画をアカウントに適応させていません。
注目に値する先行指標は SCOPE_TOO_THIN の率です。成約 deal の大きな割合がこれをトリップさせる場合、upstream の問題は営業が scope の定まった SOW なしにアカウントをハンドオフしていることです。Skill は失敗しているのではなく、deal-desk の衛生のギャップを表面化させています。
代替案との比較
vs Rocketlane Nitro。 Rocketlane 自身のエージェント層である Nitro は、Rocketlane 内で SOW とディスカバリーコールからプロジェクト計画を構築します。すでに Rocketlane の顧客で完全にその中で生活しているなら、Nitro は摩擦の少ない道です。インストールする Skill はなく、計画はプロジェクトとしてネイティブに着地します。トレードオフは、Nitro の計画ロジックは Rocketlane のものであり、あなたのものではない点です。担当者解決ルール、TTV の定義、テンプレートオフセットは、あなたが制御しバージョン管理するこの Skill のリファレンスファイルです。ゼロセットアップを望み、そのデフォルトを受け入れるなら Nitro を使ってください。テンプレートロジックを自分のものにして再利用したい場合、またはすべてのオンボーディングが Rocketlane に住んでいるわけではない場合は、この Skill を使ってください。この 2 つは相互排他ではありません。Skill で生成し、CSV をインポートし、Rocketlane に実行と顧客ポータルを任せましょう。
vs 静的テンプレート。 ほとんどのチームはここから始めます。アカウントごとにコピーして手で編集する Google Doc または Rocketlane テンプレートです。テンプレートは無料で予測可能ですが、各コピーは SOW のテンプレートへの手作業の転記であり、それがまさに Skill が取り除く 30〜60 分の仕事です。テンプレートは、SOW がテンプレートのすでに前提とする以上のものを何も加えない、同一の SMB オンボーディングの long tail には正しい選択です。Skill は、scope に実際のばらつきがあり SOW を手でマッピングするところに時間がかかるアカウントで、その価値を発揮します。
vs カスタムスクリプト。 SOW を parse して CSV を書く自作スクリプトは、SOW が厳格に構造化されているなら成立しますが、ほとんどの SOW は散文であり、散文を確実に parse することはスクリプトが間違える部分です。Skill は散文を処理します。スクリプトは Skill ができないことを何も処理しません。SOW が構造化された deal-desk システムから生成されクリーンなフィールドとして届く場合にのみスクリプトに頼ってください。その場合、抽出パスはそもそも不要です。
注意点
- 薄い scope からのでっち上げマイルストーン。 あいまいな order form は、誰も scope に入れていないもっともらしく聞こえるマイルストーンで計画を水増しするようモデルを誘います。ガード: 抽出パスは具体的な成果物を数え、3 つ未満のとき素のテンプレートとともに
SCOPE_TOO_THINを返し、でっち上げた作業にチームをコミットさせる計画を構築しません。 - 約束として提示される日付。 目標日は契約開始日にテンプレートオフセットを加えたもので、計画立案のデフォルトであり delivery のコミットメントではありません。ガード: 計画ヘッダーは日付が draft かつキックオフ前であると明示し、すべての SOW-コミット日は契約上固定としてフラグされ計算された日付から視覚的に分離され、Skill は顧客向けポータルに日付を書き込むことは決してありません。それはキックオフがそれらを確認した後の意図的な人間のステップです。
- 誤ったテンプレートが静かに選ばれる。 SMB テンプレートを enterprise アカウントで実行すると、短すぎて人員不足の計画が生まれます。ガード: テンプレート名は必須の input であり、Skill はそれを推測しません。計画ヘッダーは選ばれたテンプレートとそのセグメントをエコーするので、誰かがマイルストーンを読む前に最上部でミスマッチが見えます。
- 未解決のまま残される担当者 role。 担当者 role はあるが名前付きの人物がいない計画は実行可能ではありません。ガード: Skill はすべてのマイルストーンに role を割り当て、
references/2-owner-roster.mdの顧客側解決ルールを適用します。deal のコンテキストから担当者を解決できないマイルストーンは空白のまま残さずOWNER_TBDとフラグされるので、CSM はキックオフ前に何を埋めるべきか正確に分かります。 - motion 変更後の古いオフセット。 チームがオンボーディング motion を変更すると、リファレンスファイルが更新されるまで計画は古い日数オフセットを継承し続けます。ガード: テンプレートファイルは自身の
last_reviewed日付を持ち、計画ヘッダーがそれを表面化させます。6 か月以上前に設定されたオフセットは、日付を信頼する前に motion を再確認する合図です。
スタック
- Claude — 2 パスの計画生成: scope 抽出、続いて日付計算を伴う計画構築（Sonnet 推奨。この仕事に Opus は不要）
- Rocketlane — オプションのラストワンマイルの宛先。CSV は Rocketlane のプロジェクトインポートにマッピングされマイルストーンが再入力なしに着地し、Rocketlane が実行と顧客ポータルを動かす
- 3 つのリファレンスファイル —
1-onboarding-templates.md（フェーズ、マイルストーン、担当者 role、日数オフセット）、2-owner-roster.md（role-から-人物 と顧客側の解決）、3-ttv-definition.md（テンプレートごとの最初の価値マイルストーン）