launch-strategy
作成者 coreyhaines31launch-strategy は、エージェントやチームが曖昧なリリース案を実行しやすいローンチ計画に落とし込むためのスキルです。ORB フレームワーク、段階的ロールアウト、Product Hunt 向けの指針、各種ローンチチェックリストを使って、プロダクトローンチ、機能告知、ベータ公開、ウェイトリスト運用、一般公開の計画を支援します。
このスキルの評価は 78/100 で、ディレクトリ掲載候補として十分に有力です。エージェントが反応しやすい明確なトリガーと、実質的なローンチ計画フレームワークを備えている一方、実行用ファイルのないドキュメント中心のスキルであり、すぐに始められるクイックスタートはあまり期待できません。
- トリガー性が非常に高く、説明文でローンチ関連の意図を幅広く挙げたうえで、ローンチ後に継続する作業は別スキルへ明確に誘導しています。
- ワークフロー内容が充実しており、定義済みの ORB フレームワーク、プロダクトマーケティングの文脈確認、さらに段階的なローンチ計画・タイムライン設計・当日チェックリストの運用を前提にした evals が含まれています。
- 導入判断に必要な情報が分かりやすく、SKILL.md は長く構造化され、多くの見出しで整理されているため、単なるプレースホルダーではなく実用的な launch-strategy プレイブックだと判断できます.
- 導入後の活用は文章ベースのガイダンスに全面的に依存しており、実行時の迷いを減らすスクリプト、テンプレート、補助リソース、install コマンドは用意されていません。
- 少なくとも 1 か所にプレースホルダー表記("coming soon")があり、セクションによっては未完成、または仕上がりにばらつきがある可能性があります。
launch-strategy スキルの概要
launch-strategy スキルでできること
launch-strategy スキルは、あいまいなリリース案を、実行可能なローンチ計画に落とし込むためのスキルです。プロダクトローンチ、機能告知、ベータ公開、ウェイトリスト施策、一般公開まで、幅広い公開シーンに対応します。単に「GTMプランを書いて」と投げるだけでは足りず、出荷直前のチームに必要な構造化された判断材料を与えてくれるのが特徴です。
launch-strategy が向いている人
この launch-strategy スキルが特に向いているのは、次のようなケースです。
- ローンチ準備を進める SaaS 創業者やインディーメーカー
- 機能リリースを担当するプロダクトマーケター
Product Hunt、早期アクセス、ベータ、ウェイトリスト施策を計画しているチーム- オーディエンス規模がまだ小さく、チャネルの優先順位付けが必要なビルダー
なお、すでにローンチ後の長期的な成長フェーズに入っている場合は、リポジトリ内でも継続的なマーケティング施策向けの別スキルが案内されています。
本当に解決したい仕事は何か
多くのユーザーが必要としているのは、抽象的なローンチ理論ではありません。知りたいのは、次のような問いに答える計画です。
- まず何から着手すべきか
- 現在のオーディエンス規模なら、どのチャネルが重要か
- プレローンチ、ベータ、本番公開をどういう順番で進めるべきか
- ローンチ当日までに何を準備しておくべきか
- 維持できないチャネルに工数を使いすぎないにはどうするか
こうした実務的な問いに対しては、単発のブレスト用プロンプトより launch-strategy のほうが役立ちます。
このスキルが他と違う理由
最大の違いは、このスキルが明確な方針を持っていることです。単に施策を羅列するのではなく、特定のローンチモデルに沿って考えるよう設計されています。
- まず既存の product marketing コンテキストがあるか確認する
- チャネルを ORB フレームワーク(
Owned、Rented、Borrowed)で整理する - 一度きりの大きな告知ではなく、繰り返し訪れるローンチの節目として捉える
- 施策をローンチ当日だけでなく、段階的な公開プロセス全体に対応づける
ユーザー側の情報がまだ不完全でも、現実的な計画に組み立てやすいのは、この構造があるからです。
インストール前に知っておきたいこと
これは自動化パッケージではなく、プロンプト型のスキルです。スキルディレクトリ内にヘルパースクリプト、テンプレート、リソースフォルダはありません。価値の中心は SKILL.md に書かれたローンチ計画フレームワークと、evals/evals.json で示される期待出力にあります。
つまり導入自体は簡単ですが、出力の質は、どれだけ具体的な文脈を渡せるかに強く左右されます。
launch-strategy スキルの使い方
launch-strategy スキルのインストール前提
coreyhaines31/marketingskills リポジトリのスキルワークフローを使って launch-strategy をインストールします。一般的な Skills CLI パターンを使う場合、基本のインストールコマンドは次のとおりです。
npx skills add https://github.com/coreyhaines31/marketingskills --skill launch-strategy
インストール後にまず見るべき主要ファイルは以下です。
skills/launch-strategy/SKILL.md
確認用として役立つファイル:
skills/launch-strategy/evals/evals.json
まず読むべきリポジトリファイル
素早く導入判断したいなら、次の順で読むのがおすすめです。
- 実際のワークフローと位置づけが分かる
SKILL.md - 良い出力に何が含まれるべきか確認できる
evals/evals.json
このスキルには追加の resources/ や scripts/ がないため、実際の挙動を把握するにはこの2ファイルでほぼ十分です。
最初に product marketing context の有無を確認する
見落としやすい実務上のポイントとして、このスキルは質問を始める前に .agents/product-marketing-context.md または .claude/product-marketing-context.md を確認するよう、エージェントに明示しています。
ブランド、対象顧客、ポジショニング、価格、チャネル情報などを再利用できる形で管理しているなら、そこに置いておくと効果的です。毎回同じ説明を繰り返さずに済み、launch-strategy の活用精度もかなり上がります。
launch-strategy に渡すべき入力情報
launch-strategy スキルは、次の情報があると最も力を発揮します。
- 何をローンチするのか: product、feature、beta、pricing update、integration
- ローンチの種類: alpha、beta、early access、full public launch、Product Hunt
- スケジュール: 正確な日付、または残り週数
- 対象オーディエンス: 誰が関心を持つべきか、その理由
- 現在のトラクション: メールリスト規模、SNS フォロワー数、顧客数、waitlist、コミュニティ到達範囲
- 利用できるチャネル: newsletter、X/Twitter、LinkedIn、communities、partners、existing users
- チーム上の制約: 予算、デザイン工数、創業者の稼働、動画なし、広告なし
- 成功指標: signups、demos、waitlist joins、activation、awareness
これらがなくても計画は出せますが、どうしても汎用的になりやすいです。
あいまいな目標を、強い launch-strategy プロンプトに変える
弱いプロンプト:
- “Help me launch my product.”
より良いプロンプト:
- “Use the launch-strategy skill to plan a 4-week launch for a B2B invoicing SaaS. We have 900 email subscribers, 1,500 LinkedIn followers, no ad budget, and 30 beta users. Our goal is 200 qualified trial signups. Include ORB channel recommendations, a phased rollout, launch day checklist, and what to prepare this week.”
この書き方が有効な理由は次のとおりです。
- チャネル上の制約をスキルに渡せる
- 測定可能な成果目標がある
- 限られた期間の中で優先順位付けが必要になる
- スキルが前提にしている ORB と段階的ローンチ構造に合っている
ORB フレームワークは、このスキルの前提どおりに使う
launch-strategy の中心にあるのが ORB フレームワークです。
Owned: email list、website、in-app messages など、自分たちでコントロールできるチャネルRented: social platforms のように投稿はできるが所有していないチャネルBorrowed: third-party audiences、partnerships、communities、press、Product Hunt など、他者の到達範囲を借りるチャネル
実務上の利点は、優先順位を明確にできることです。SNS フォロワーは少ない一方で既存顧客との関係が強いなら、計画の中心は Owned になるべきです。逆に、そもそも自前のオーディエンスがほとんどないなら、Borrowed をより重視した設計が必要です。
ローンチ当日だけでなく、段階的な launch-strategy を想定する
リポジトリを見る限り、このスキルは複数フェーズにまたがるローンチモデルを推奨する前提で作られています。通常は次のような流れをカバーします。
- internal prep
- alpha
- beta
- early access
- full launch
ここは重要です。失敗するローンチの多くは、フィードバック収集、メッセージ整理、アセット制作、オーディエンス形成をすべて一日に圧縮してしまいます。launch-strategy はコピー作成の近道というより、順序設計のためのツールとして使うほうが向いています。
Product Launches 向け launch-strategy のおすすめ運用フロー
実務では、次の順序で進めると使いやすいです。
- ビジネスとオーディエンスの文脈を渡す
- 自分たちのチャネルを ORB に分類させる
- 実際の日付にひもづく段階別タイムラインを出させる
- フェーズごとのローンチアセットを依頼する
- launch day checklist を出させる
- 初稿のあと、チャネル・オーディエンスセグメント・オファー単位で絞り込む
launch-strategy for Product Launches では、「全部まとめて出して」と一度に求めるより、この段階的な進め方のほうが良い出力になりやすいです。
良い出力に含まれているべき要素
スキル本体と evals を踏まえると、良い出力には通常、次の要素が入ります。
- 既存の marketing context files を確認する動き
- 実際のオーディエンス規模に基づく ORB channel mapping
- ローンチ期間に沿った timeline
- 各フェーズごとの tactics
- ローンチ当日以前の audience-building
- 具体的な launch day checklist
これらが抜けている場合、スキルの呼び出し方が弱いか、プロンプト側の文脈が不足している可能性が高いです。
Product Hunt とチャネル別の使いどころ
evals からは、Product Hunt の計画に明確に対応していることが読み取れます。ここを主戦場にするなら、その前提をはっきり伝え、次の情報も含めてください。
- 初めてのローンチかどうか
- maker audience と相性があるか
- 支援してくれる supporters や partners がいるか
- すでに持っている assets は何か
- 重視する成功指標は何か: ranking、traffic、signups、demos
単に「コツを教えて」で済ませず、pre-launch checklist、当日の execution plan、post-launch follow-up sequence まで依頼するのがおすすめです。
よくあるインストール・運用上の制約
スキルフォルダ内に、完成済みテンプレート集は同梱されていません。そのため launch-strategy install 自体は簡単ですが、実際の使い勝手は、どれだけ文脈を渡せるか、そして成果物を段階的に依頼できるかに左右されます。
プロンプトなしで、完全に標準化されたローンチ文書をすぐ欲しいなら、このスキルは少し軽く感じるかもしれません。反対に、自社状況に合わせて構造化された思考を引き出したいなら、相性は良いです。
launch-strategy スキル FAQ
launch-strategy は普通のローンチ用プロンプトより優れている?
一般的には、構造の一貫性がほしいなら優れています。launch-strategy スキルは、特に ORB によるチャネル設計と、段階的ロールアウトの考え方をエージェントに与えます。通常のプロンプトでもアイデアは出ますが、チャネルの優先順位付けや進行順序が抜けやすいのが難点です。
launch-strategy スキルは初心者にも向いている?
はい。特に、専任のマーケティングチームなしでローンチする創業者には向いています。フレームワーク自体はシンプルで追いやすく、それでいて経験者にとっても再利用しやすい計画パターンとして十分実用的です。
launch-strategy があまり向かないのはどんなとき?
次のようなケースでは相性がやや弱くなります。
- ローンチ計画より、ローンチ後の成長戦略が必要な場合
- 施策の中心が paid acquisition の場合
- scripts や templates から自動生成される成果物を求めている場合
- すでに成熟した GTM プロセスがあり、必要なのが copy edits だけの場合
フルプロダクトではなく、機能リリースにも launch-strategy は使える?
はい。スキル説明でも、対象はフルスケールの会社ローンチだけでなく、feature announcements や product updates まで明示されています。特に、小さなリリースを静かに出すのではなく、勢いのあるイベントとして扱いたいときに有効です。
launch-strategy は既存オーディエンスがないと使えない?
いいえ。ただし、オーディエンスがない場合は使い方が変わります。自前のオーディエンスが小さいなら、計画は borrowed channels、partnerships、communities、そして本格プッシュ前の段階的な検証をより重視する形になるはずです。
インストール前に何を比較すべき?
比較すべきポイントは次のとおりです。
- 欲しいのが framework なのか、template pack なのか
- 必要なのがローンチの sequencing なのか、単なる messaging support なのか
.agents/product-marketing-context.mdのような再利用可能な context files を活かせる運用か
このあたりの要件が合っているなら、launch-strategy ガイドは十分に導入価値があります。
launch-strategy スキルを改善するには
launch-strategy には具体的な制約条件を渡す
結果を最も早く改善できるのは、厳密な制約を明示することです。
- 正確なローンチ日
- チーム人数
- 週あたりに使える時間
- 制作できるアセットの上限
- 使わないチャネル
- 法務やブランド上の制約
広い話をするローンチ助言より、制約を踏まえた計画のほうが実際にはずっと使えます。
曖昧な「リーチ」ではなく、実数でチャネル情報を出す
「オーディエンスは小さい」とは書かず、次のように具体的に伝えてください。
650 email subscribers2,100 X followers14 design partners3 integration partners willing to co-promote
スキルの ORB フレームワークは、実際の到達規模と関係の温度感が分かると、チャネル順位付けの精度が大きく上がります。
戦略だけでなく、成果物を依頼する
launch-strategy の使い勝手を上げるには、戦略論だけで終わらせず、次のような出力を明示的に求めるのが有効です。
- 週次タイムライン
- チャネル別プラン
- launch day checklist
- asset list
- announcement angle options
- risk list と mitigation steps
こうすることで、戦略がそのままチームで実行できる形に近づきます。
リソースが限られているなら、優先順位付けを強制する
ありがちな失敗は、やることが多すぎる前提の計画が出ることです。それを防ぐには、次のように聞くと効果的です。
- “Rank the top 3 channels only.”
- “What should we cut if we have 5 hours per week?”
- “What is the minimum viable launch plan?”
特に、ソロファウンダーが launch-strategy for Product Launches を使う場合は重要です。
2パスのプロンプト運用にする
Pass 1:
- 戦略、フェーズ、ORB mapping、抜けている要素を出させる
Pass 2:
- 内容を確認したあと、選んだチャネルとフェーズについてだけ実行詳細を出させる
この進め方なら、計画が肥大化しにくく、まず意思決定、その次に施策詳細という順でスキルを使えます。
メッセージング情報を先に渡して、初回出力を強くする
すでに次の情報が分かっているなら、早い段階で含めてください。
- positioning
- target user
- core pain point
- key differentiator
- proof or traction
- launch offer
ここがないと、チャネル戦略としては筋が通っていても、メッセージが弱い出力になりやすいです。
よくある失敗パターンをレビュー観点にする
launch-strategy の出力が弱いときは、たいてい次のどれかに当てはまります。
- ローンチ当日に寄りすぎていて、プレローンチの積み上げが薄い
- 実際のオーディエンスを無視したチャネル提案になっている
- 順序設計のない generic な social media tasks に終始している
- beta、early access、full launch の違いが整理されていない
- 実行準備のための checklist がない
初回の回答を見たあと、これらを点検項目として使うと改善しやすいです。
launch-strategy にローンチタイプを明示して適応させる
次のどのケースかを明示すると、出力はかなり強くなります。
- cold-start の新規 product launch
- 既存ユーザー向けの feature announcement
- フィードバック獲得が目的の beta
- waitlist campaign
- Product Hunt launch
- customer expansion release
これらは同じ計画で扱うべきではありません。
独自の再利用コンテキストファイルでスキル精度を上げる
このスキルを繰り返し使うなら、.agents/product-marketing-context.md を作って次の情報をまとめておくのがおすすめです。
- product summary
- ICP
- pricing
- traction
- competitors
- brand voice
- primary channels
- launch constraints
頻繁にローンチを行うチームにとって、これは最もレバレッジの大きい改善策です。というのも、launch-strategy スキル自体がこのファイルを明示的に確認する設計になっているからです。
最初のプランのあとに反復する
最初のドラフトが出たあとで、まったく新しい計画を一から求める必要はありません。代わりに、次のような絞ったフォローアップを行うと実用性が上がります。
- “Rewrite this for a 2-week timeline.”
- “Reduce this to channels we already own.”
- “Add a Product Hunt-specific checklist.”
- “What should happen in beta vs early access?”
- “Turn this into a founder-only execution plan.”
このような反復なら、スキルの構造を保ったまま、実際に使える計画へ寄せていけます。
