Agent Skills by ALSEL
Anthropic Claudeその他⭐ リポ 0品質スコア 50/100

gtm-0-to-1-launch

新製品のアイデアから最初の顧客獲得までをサポートするスキル。製品ローンチ、アーリーアダプターの発掘、ローンチウィークの戦略立案、採用停滞の原因診断、またはプレス掲載が必ずしも成長につながらないことを学ぶ場面で活用できる。3層診断フレームワーク、2週間の実験サイクル、そして5万インプレッション・12件サインアップを達成したローンチ事例を含む。

description の原文を見る

Launch new products from idea to first customers. Use when launching products, finding early adopters, building launch week playbooks, diagnosing why adoption stalls, or learning that press coverage does not equal growth. Includes the three-layer diagnosis, the 2-week experiment cycle, and the launch that got 50K impressions and 12 signups.

SKILL.md 本文

0-to-1 ローンチ

アイディアから最初の顧客までの新製品ローンチ。目標はヘッドラインではなく、あなたなしでは生きられない10人の顧客を見つけることです。

いつ使うか

トリガー:

  • 「この製品はどうやってローンチするの?」
  • 「初期顧客獲得戦略」
  • 「ローンチしたけど誰も使ってくれていない」
  • 「Product Hunt vs 直接営業?」
  • 「認知度はあるのにコンバージョンがない」
  • 「これが機能しているかどうかをどうやって知ればいい?」

コンテキスト:

  • 新製品ローンチ
  • 新製品のように感じる機能ローンチ
  • 最初の10~50顧客を見つける
  • プロダクト・マーケット・フィットの検証
  • 初期の勢いが停滞する理由を診断する

コア・フレームワーク

1. プレス報道 ≠ 成長 (12サインアップを得たローンチ)

パターン:

機能ローンチを完全なプレスツアーと組み合わせて調整。TechCrunch、VentureBeat、プロダクトブログ。大きなアナウンスの日。

結果:

  • 50K インプレッション
  • 12 サインアップ
  • 2 コンバージョン

失敗した理由:

メディアバズに最適化され、ユーザー価値には最適化されていませんでした。機能はセルフサービス対応ができていませんでした。教育、コンテキスト、ハンドホールディングが必要でした。プレスはあなたに視線をもたらします。でも活性化がない視線=バニティメトリクスです。

より効果的な方法:

ターゲット顧客50人に直接メール。「私たちは[機能]を、あなたのようなチームが[問題]で苦労しているから構築しました。アーリーアクセスを試してみませんか?」セットアップを手動で進めてください。フィードバックを得て、反復します。

結果: 50通のメール → 15件の返信(30%返信率)→ 8件のトライアル → 4件のコンバージョン(50%トライアル・トゥ・ペイド)。

教訓:

初期顧客はプレス報道ではなく直接営業から来ます。プレスは後で重要になります(Series Aアナウンス、主要なマイルストーン)。0-to-1段階では、それは気を散らすだけです。


2. 3層診断フレームワーク (ローンチが停滞する理由)

パターン:

ローンチしました。認知度は多少あります。でもコンバージョンは弱い。問題は3層のうち1つにあり、各層には異なる介入が必要です。

レイヤー1: ポジショニング問題

症状:

  • メッセージが競合他社のように聞こえる
  • 差別化に複雑な技術詳細の説明が必要
  • 買い手はあなたを競合他社と区別がつかないと見る
  • 営業会話が比較の質問で脇道に逸れる

診断: 「非対称戦争を間違った前線で戦っている」—より資金が豊富な企業機能に対して競争しています。競合他社が独自の価値を主張している場所をマッピングします。彼らが簡単にはコピーできないポジションを見つけます。

修正: 構造的に所有できるクレームを立てる(単なる製品機能ではなく)。製品リソースを確保する前にアウトバウンドメッセージでテストします。

レイヤー2: 体験問題

症状:

  • 強い認知度だが弱い活性化
  • ユーザーは登録するが最初のワークフローを完了しない
  • 複数のエントリーポイントが決定の麻痺を引き起こしている
  • ドキュメンテーションが機能中心で、結果中心ではない

診断: 意思のあるデフォルト値がない柔軟性は、機能ではなく負債です。ユーザーは「選択肢の逆説」に直面しています—多くのオプション、アハモーメントへのガイダンス不足。

修正: すぐに価値を提供する「否定できないユースケース」2~3つを特定します。オンボーディングをその特定のユースケースに制限します。高度な機能をマスタリーパスの背後に置きます。機能リストではなく、ジョブス・トゥ・ビー・ドーンの周りにヘルプコンテンツを書き直します。

レイヤー3: アラインメント問題

症状:

  • チームが「顧客のための帯域幅がない」と報告している
  • 異なるチームが異なるメトリクスに最適化している
  • すべてのアイデアが同じ重みを持っている(タイブレーカーがない)
  • アクティビティを結果に接続する明確な北極星がない

診断: すべてのイニシアチブが同等の優先度を持つ「探索モード」は、リソースが限られているときに破壊的になります。

修正: 単一の共有北極星を定義します。すべての決定のタイブレーカーとして使用します: 「これは顧客を獲得するのに役立つのか?」それに関連しないアクティビティを削除します。進捗を四半期ごとではなく週ごとに見える化します。

これをどう使うか:

ローンチが停滞するとき、リソースを投入する前にどのレイヤーが壊れているか診断します。問題がポジショニングのときに体験を修正するとエンジニアリングの時間が無駄になります。問題が内部アラインメントのときにポジショニングを修正するとマーケティング支出が無駄になります。


3. 最初の10顧客フレームワーク

原則: 最初の10顧客は収益のためではなく、学習のためです。

何を学ぶか:

  1. 製品は実際に問題を解決するのか?
  2. 活性化フローは何か? (どのように価値を得るのか?)
  3. どんな異議が出てくるのか? (価格、機能、統合?)
  4. 実際の買い手は誰か? (肩書き、役割、予算権限?)
  5. セールスサイクルは何か? (日数、週数、月数?)

どのように見つけるか:

チャネル1: パーソナルネットワーク (最初の2~3人)

  • 「[X]を構築中で、フィードバックをもらえませんか?」
  • 有料顧客に転換する (無料では与えない—無料ユーザーは有料ユーザーと異なるフィードバックを与える)

チャネル2: 直接営業 (顧客3~20人)

  • 100のターゲットアカウントのリストを構築
  • 彼らの特定の痛みにパーソナライズ
  • メッセージング変形をテスト—どの角度が返信を得るか?

チャネル3: 天井モーメント・ターゲティング (最高意図)

  • 最高意図の見込み客は、比較可能なソリューションを採用し、その限界に達した人です
  • 彼らはツール学習に投資し、その天井に達し、乗り換えコストが低い
  • 限界の周りにアウトリーチを作成します: 「[既存製品]が[機能]を必要とするときにそれを上回るチームを見てください。それが私たちが構築したものです。」
  • 彼らは既に問題を理解しているため、コールドアウトリーチより3~5倍良いコンバージョン率

チャネル4: コミュニティ (開発者製品)

  • 「[X]を構築した[問題]を解決するため、初期ユーザーを探しています」
  • ホワイトグローブオンボーディングを提供
  • ユーザーがSlack/Discord/フォーラムに集まる製品に最適

4. 2週間実験サイクル

パターン:

初期段階ではスピードが完璧さより重要です。制約は、あなたが正しいかどうかではなく、どの程度の速さで仮説をテストして反復できるかです。

実行方法:

  • 開始前に明確な成功基準で各テストをフレーム化
  • 実験ごとに1つの変数をテスト (メッセージング、チャネル、価格、機能)
  • 最大2週間実行—その時点までにシグナルを示していなければ、そうはならない
  • 機能したら、1週間以内にリソースを3倍に割り当てる
  • 機能しなかったら、キルして次のテストに移る
  • 結果に関係なく、学習したことを文書化

プレイブック・ルール:

成功したすべての実験は、スケール前にプレイブックになる必要があります。構造: 目標 → ステップ → 期待される出力 → メトリクス → リスク。よく知らない人がプレイブックを実行できなければ、十分にドキュメント化されていません。

これが重要な理由:

1度限りの勝利は複合しません。体系的な実験は複合します。目標は単一のローンチではなく、スピードで仮説をテストするための反復可能なマシンを構築することです。

一般的な間違い:

テスト前の過度な計画。「完璧な」条件が整うまで待つ。失った感情的エネルギーのために失敗する実験に長く留まる。70%の情報で決定を下す。


5. パートナー主導市場進出 (流通がない場合)

パターン:

直接営業だけで新市場に進出するのではなく、確立されたプレーヤーとのパートナーシップを使用して加速します。

実行方法:

  1. ターゲットセグメントの市場リーダーを特定
  2. パートナーシップピッチではなく顧客問題にアプローチ—「あなたのユーザーが[機能]にアクセスできたらどう?」はあなたのニーズから彼らのニーズへシフト
  3. 1つの特定の問題を解決する小さなことから始める (完全なパートナーシップではなく、狭い統合)
  4. より広いコミットメントを求める前に3~6ヶ月のパイロットで価値を証明
  5. 一緒にリファレンス顧客を構築—彼らのリスクを減らす
  6. 彼らのGTMを活用: 統合後、彼らは彼らのベースに市場

スーパーノード・パターン:

他のツールが自然に接続する統合ハブとして自分をポジショニング。あなたは他のプラットフォームが必要とする重要なデータやワークフローを所有しています。これは複合します—各新規パートナーはあなたを次のパートナーにとってより価値のあるものにします。

カテゴリ・シーケンシング:

すべての場所でパートナーシップを追求しないでください。四半期ごとに2~3のカテゴリを支配:

  1. 本物のユースケースでリード: 「当社のユーザーは[パートナー]統合を月50回要求しています」
  2. トップ層のプレーヤーと一度パートナーになったら、競合他社はあなたと一緒に仕事をすることの緊急性を感じます
  3. カテゴリ内で2~3件の成功したパートナーシップ後、共同顧客ストーリーを作成

一般的な間違い:

明確な統合パスなしでパートナーシップを開始。パートナーはサポートなしで認知度を駆動すると予期。パートナーシップをプラットフォーム拡張ではなく営業チャネルとして扱う。


6. PMF検証チェックリスト

プロダクト・マーケット・フィットは、顧客が前に進まされるのではなく、前に引っ張られるときです。

リテンション:

  • 週1ユーザーの40%以上が週4に戻る
  • 時間とともに使用が増加
  • 顧客がセールスプッシュなしで更新

オーガニック成長:

  • 口コミ紹介が発生
  • 顧客が「チームを追加できるか?」と聞く
  • 有料マーケティングなしのインバウンド関心

営業速度:

  • セールスサイクルが短縮
  • トライアルの30%以上のウィンレート
  • 顧客が「今必要だ」と言う

定性的:

  • 製品がなくなった場合、40%以上が非常に失望 (Sean Ellisテスト)
  • 顧客がそれが何のためにあるのかを説明できる (明確なユースケース)
  • 顧客が公開で提唱

これらがなければ、PMFはまだありません。マーケティング/営業をスケーリングしないでください。


決定木

なぜローンチが停滞しているのか?

見込み客はあなたが何であるかを理解していますか?
├─ いいえ → レイヤー1: ポジショニング問題
│            修正: 製品を変更する前に新しいメッセージをテスト
└─ はい → 続行...
    │
    ユーザーはサインアップ後に活性化しますか?
    ├─ いいえ → レイヤー2: 体験問題
    │            修正: オンボーディングを2~3のユースケースに制限し、アハモーメントにガイド
    └─ はい → 続行...
        │
        チームは何が重要かについて調整されていますか?
        ├─ いいえ → レイヤー3: アラインメント問題
        │            修正: 単一北極星、週次可視性、非必須を削除
        └─ はい → 反復を続ける、正しい軌道に乗っている

プレスローンチまたは直接営業?

セルフサービスの準備ができていますか? (ユーザーが<10分で価値を得る)
├─ いいえ → 直接営業のみ (プレスは変換されません)
└─ はい → >$100万の資金調達をアナウンスしていますか?
    ├─ はい → 両方 (認知度のためプレス、コンバージョンのため営業)
    └─ いいえ → 最初に直接営業、後でプレス

一般的な間違い

1. ヘッドラインではなく活性化に最適化 50Kインプレッション、12サインアップ。プレス≠成長。

2. ローンチ前にターゲット顧客リストなし スプレー・アンド・プレイは0-to-1では機能しません。最初に100のアカウントのリストを構築します。

3. デフォルト値がない柔軟性 ユーザーにすべてのオプションを与えると麻痺します。2~3の否定できないユースケースを選び、強くガイドします。

4. 製品を無料で配る 無料ユーザーは丁寧なフィードバックを与えます。有料ユーザーは正直なフィードバックを与えます。

5. 学ぶ前にスケーリング 最初の10顧客は収益のためではなく学習のためです。すべてを文書化します。

6. 過度な計画、テスト不足 明確なキル基準がある2週間実験。速く動き、学習を文書化します。

7. 間違ったレイヤーを診断 問題が体験のときポジショニング修正=マーケティング支出を無駄。問題がポジショニングのときに体験修正=エンジニアリング無駄。


クイック・リファレンス

3層診断: レイヤー1: ポジショニング (メッセージが競合他社のように聞こえる) → 新しいメッセージをテスト レイヤー2: 体験 (認知度あるが活性化なし) → アハモーメントにガイド レイヤー3: アラインメント (チーム分散) → 単一北極星、週次可視性

最初の10顧客: パーソナルネットワーク (2~3人) → 直接営業 (3~20人) → 天井モーメント・ターゲティング (最高意図) → コミュニティ (開発者製品)

2週間実験サイクル: 仮説 → 成功基準 → テスト (最大2週間) → キルまたは3倍 → プレイブック文書化

PMFシグナル: 40%以上週1→4リテンション+口コミ+短縮セールスサイクル+40%以上非常に失望

パートナー主導進出: 顧客問題第一 → 狭いパイロット → 一緒にリファレンス顧客 → 彼らのGTMを活用


関連スキル

  • product-led-growth: 初期の勢いの後のスケーリング
  • positioning-strategy: ローンチのためのポジショニング
  • partnership-architecture: パートナー主導市場進出

プレスに最適化し50Kインプレッションから12サインアップを得た機能ローンチ、3社全体で3層モデルを使用してローンチ停滞を診断、テスト中心のテストを反復可能なマシンに変えた2週間実験サイクルを構築した経験に基づく。また複数の地域とセグメント全体でのパートナー主導市場進出も含める。理論ではなく—バニティメトリクスを成長と勘違いし、実際の問題を診断することを学んだ経験から。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
github
リポジトリ
github/awesome-copilot
ライセンス
MIT
最終更新
不明

Source: https://github.com/github/awesome-copilot / ライセンス: MIT

関連スキル

汎用その他⭐ リポ 1,982

superfluid

Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper

by LeoYeAI
汎用その他⭐ リポ 100

civ-finish-quotes

実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。

by huxiuhan
汎用その他⭐ リポ 1,110

nookplot

Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。

by BankrBot
汎用その他⭐ リポ 59

web3-polymarket

Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。

by elophanto
汎用その他⭐ リポ 52

ethskills

Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。

by jiayaoqijia
汎用その他⭐ リポ 44

xxyy-trade

このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。

by Jimmy-Holiday
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: github · github/awesome-copilot · ライセンス: MIT