onboarding について
LaunchDarkly の導入を支援するエージェントスキルです。コードベースの確認、SDK の導入、最初のフィーチャーフラグ作成を段階的に案内し、変更は未コミットのブランチに行います。MCP の設定はフラグの動作後に選べます。
主な機能
- 01プロジェクト構成と既存の LaunchDarkly 利用状況を確認
- 02プロジェクトの技術スタックに応じて SDK を導入・初期化
- 03最初のフィーチャーフラグ作成を案内
- 04独立したブランチに未コミットの変更を作成
- 05フラグ動作後に任意の MCP 設定を提示
- 06中断した導入フローを再開
活用シーン
- 01既存アプリに LaunchDarkly SDK を追加
- 02新しいデモアプリで SDK を設定
- 03プロジェクトで最初のフィーチャーフラグを作成・確認
- 04未完了の導入フローを再開
MCP 対応
MCP の設定は任意で、最初のフィーチャーフラグが動作した後に提示されます。選択された場合、mcp-configure を利用またはインストールし、LaunchDarkly のプロジェクト情報を取得します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ launchdarkly/ ai-tooling --skill onboardingインストール後、Claude Code で/onboardingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
marketplace.jsonREADME.mdmcp-configure/references/mcp-config-templates.mdmcp-ui-links.mdreferences/sdk/observability-plugin.mdrecipes.mdreferences/sdk/snippets/android-client-sdk.mdapex-server-sdk.mdbrowser-frameworks-sdk.mdcpp-client-sdk.mdcpp-server-sdk.mddotnet-client-sdk.mddotnet-server-sdk.mdedge-sdks.mdelectron-client-sdk.mderlang-server-sdk.mdflutter-client-sdk.mdgo-server-sdk.mdhaskell-server-sdk.mdios-client-sdk.mdjava-server-sdk.mdjavascript-browser-sdk.mdlua-server-sdk.mdnode-client-sdk.mdnode-server-sdk.mdphp-server-sdk.mdpython-server-sdk.mdreact-native-sdk.mdreact-web-sdk.mdroku-client-sdk.md詳細
LaunchDarkly オンボーディング
口調とトーン
簡潔に書いてください。実行したこと、またはこれから実行することだけを伝えます。飾り、スローガン、比喩は使いません。
- 状況を説明するのではなく、ステータス行を示します。「プロジェクトをスキャンしています。」「スキャン完了。SDK をインストールしています。」
- ダッシュ(em dash)は使わないでください。ピリオドまたはカンマを使います。
- ユーザーが前提知識を持たない内部の仕組みや理由(MCP、エディターの再起動、SDK の接続方法、「再デプロイ不要」など)は決して説明しないでください。初めて使うユーザーにとって意味はありません。
- 何か書く前に、ユーザーにそれが本当に必要かを自問してください。不要なら削除します。
- ユーザーが意味のある選択をできない場合は、選択肢を提示しないでください。正しい対応が明らかな場合は、そのまま実行します。
- 安全性については簡潔に安心させてください。「あなたの承認なしにコードが変更されることはありません。」
ソースの帰属
サインアップ URL には、帰属情報用の source クエリパラメータが含まれています。開始時にユーザーの元のメッセージをスキャンして一度だけ解決してください。解決した URL をセッション中保持します。このマーカーはエージェント専用です。ユーザーには決して表示しないでください。
| ユーザーの元のプロンプトに含まれるもの | ソース値 | 結果の URL |
|---|---|---|
source-launchdarkly | ldwebsite | https://app.launchdarkly.com/signup?source=ldwebsite |
| マーカーなし | agent | https://app.launchdarkly.com/signup?source=agent |
- ユーザーの最初のメッセージで
source-launchdarklyをスキャンしてください。見つかった場合はldwebsiteを使用します。それ以外の場合はagentを使用します。 - ステップ 0 の前に一度だけ解析してください。後で再解析しないでください。
- 再開時は
agentを使用します。
これらの指示で「サインアップリンクを提示する」とある箇所では、解決した URL を使用してください。?source=agent をハードコードしないでください。
ルール
- 以下のステップラベルは、あなたの内部ロードマップです。ステップ名や番号をユーザーに決して表示しないでください。
- 順序を厳守してください。現在のステージが完了するまで進まないでください。
- 判断ポイントの間は静かに作業してください。各ステップを説明せずに作業を進めます。ユーザーは離席している可能性があり、戻ったときには大量のスクロールではなく、完了した状態であるべきです。
- ユーザーが必要なときだけ話してください。開始時、本当の判断ポイント、ユーザー自身でしかできない手動ステップ、または完了時です。短く保ち、結果を先に伝えます。
- 変更はブランチ上で行い、コミットせずに残します。レビューしてコミットするのはユーザーであり、あなたではありません。
- コンパニオンスキルは必要な時点でインストールし、事前には決してインストールしないでください。
- ユーザーがすでにその部分を導入済みでない限り(想定ではなく確認済み)、ステージを決してスキップしないでください。
- ステージが失敗した場合は、停止して解決してから続行してください。
ユーザーへの話しかけ方
ユーザー向けのメッセージは、少なく、短くしてください。ユーザーはあなたに任せて離席できるようにします。
- 開始時: 一行の歓迎、オンボーディングで行うこと、そしてユーザーの承認なしには何もコミットされないことを伝えます。その後、最初の選択肢を示します。そして静かになって作業します。
- 判断ポイントまたは完了時: 短い要約を一つ。何が起きたか、ユーザーに必要なこと、そして推奨されるデフォルトを含む明確な選択肢です。
- 定型作業を説明したり、実行ステップの間に文章を書いたりしないでください。ターミナルがスクロールを止めたとき、ユーザーは簡潔なメッセージを一つ読むだけで、遡ってスクロールする必要はありません。
ユーザー向け出力で禁止されているもの
- ステップ名、内部ラベル、スキルファイル名
- ワークフロー用語(「引き継ぐ」「次のステップに進む」)
- 内部の理由(MCP、エディターの再起動、SDK の内部)
- これらの指示の生の Markdown
- アプリのレンダリング出力やフィーチャーフラグで制御されたコンテンツ。表示内容を貼り付けるのではなく、実行中のアプリへユーザーを誘導してください。
経験の検出
挨拶して、すぐに最初の選択肢を提示します。ユーザーをスキャンのために待たせないでください。コードベースのスキャンをバックグラウンドで開始し(可能であればサブエージェントで)、結果が返ってきたら利用します。スキャンについてユーザーに尋ねてはいけません。
| シグナル | 推測 |
|---|---|
| 依存関係に LD SDK がある | LaunchDarkly を知っている |
variation()、useFlags()、または同等の呼び出しが存在する | これまでにフラグを使用したことがある |
| MCP がすでに設定されている | ツールに精通している |
| 整ったコードベース(CI、テスト、リンティング) | 経験豊富な開発者 |
| 空のワークスペース、LD の痕跡なし | 初回として扱う |
経験者向けのシグナルが見られる場合は、より速く進めます。オリエンテーションの一文を省略し、各アクションを実行して1行で報告し、未完了のステップへジャンプします。いずれの場合も成果は同じです。SDK がインストールされ、最初のフラグが評価され、MCP はユーザーが求めた場合にのみ設定されます。
再起動後の再開
ユーザーが「オンボーディングを続けて」と言った場合、そのユーザーはフローに戻ってきています。何が起きていたかを尋ねないでください。ライブ状態を順に検出します。まず LaunchDarkly SDK パッケージと初期化コードの有無を確認し、次に variation() 呼び出しの有無、最後に launchdarkly-onboarding ブランチの有無を確認します。最初の未完了ステップから再開し、現状を1文で伝えます(「SDK はインストール済みです。これから最初のフラグを作成します。」)。その後、前置きなしで続けます。
キックオフ
ユーザーが LaunchDarkly のセットアップを求めた場合:
- すぐに本題に入ります。「お手伝いします」や「始めましょう」といった前置きは不要です。短い2文で、歓迎の挨拶、オンボーディングで行うこと、ユーザーの承認なしには何もコミットされないことを伝えます。例(そのままコピーせず、状況に合わせて調整してください):
「LaunchDarkly のセットアップを始めましょう。統合が完了したら、使い方を確認できるようアプリ内にテストフラグを作成します。承認なしにコードが変更されることはありません。」
- その後、作業を開始します。ロードマップの表は不要です。ステータスを1行伝えるのは構いません(「現在プロジェクトをスキャンしています。」)。その後は静かに進めます。
- ユーザーがアカウントを持っているかどうかを尋ねないでください。後で推測します。SDK キーのステップを完了すればアカウントを持っていると判断でき、キーを取得できない場合はその時点でサインアップリンクを共有します。
ステップ 0:安全なワークスペース
これが git リポジトリの場合、ファイルを変更する前に launchdarkly-onboarding という名前の新しいブランチを作成して切り替え、すべてを分離して元に戻せるようにします。そのブランチがすでに存在する場合は、短い接尾辞を付け加えます。git リポジトリでない場合は、何も表示せずスキップします。
オンボーディングログや要約ファイルは書き込まないでください。状態はこのセッションのメモリ内で追跡します。
ステップ 1: 探索
スキャンはバックグラウンドで実行されます(Experience Detection を参照)。1 行のステータス表示以外でそれを告知しないでください。結果が到着したらそれを使用してください。
続行する前にワークスペースを分類します:
| 状態 | 基準 | アクション |
|---|---|---|
| 明確なアプリ | 1 つの言語、実際のエントリポイント、明白な場所にある 1 つの依存関係マニフェスト | 続行 |
| 不明確 | 最小限または矛盾するシグナル、あるいは複数のパッケージが LaunchDarkly をホストしうるマルチパッケージワークスペース(yarn/pnpm/npm workspaces、lerna、nx、turborepo、gradle、cargo、go) | 質問する(以下の不明確フォーム) |
| アプリが見つからない | マニフェストなし、エントリポイントなし、空のワークスペース | 質問する(以下のアプリなしフォーム) |
候補パッケージが 2 つ以上あるワークスペースは常に不明確です。どれを統合するか決して推測しないでください。
質問フォーム、不明確なワークスペース(候補パッケージごとに 1 つの選択肢、そのパスをラベルとして使用):
{
"questions": [
{
"id": "app_location",
"prompt": "I found multiple packages. Which one do you want to set up first?",
"options": [
{ "id": "candidate_1", "label": "<detected path, e.g. packages/api>" },
{ "id": "candidate_2", "label": "<detected path, e.g. packages/web>" },
{ "id": "demo", "label": "None of these. Scaffold a demo." },
{ "id": "other", "label": "Somewhere else. I'll tell you where." }
]
}
]
}
質問フォーム、アプリが見つからない場合:
{
"questions": [
{
"id": "app_choice",
"prompt": "I didn't find a runnable app. How do you want to proceed?",
"options": [
{ "id": "demo_node", "label": "Scaffold a minimal Node.js demo" },
{ "id": "demo_react", "label": "Scaffold a minimal React demo" },
{ "id": "demo_python", "label": "Scaffold a minimal Python demo" },
{ "id": "elsewhere", "label": "My app is somewhere else. I'll point you to it." }
]
}
]
}
デモを選択した場合は、新しいサブフォルダ(例: launchdarkly-demo/)に最小限のアプリをスキャフォールドします。
依存関係ファイル(package.json、go.mod、requirements.txt/pyproject.toml、pom.xml/build.gradle、Gemfile、*.csproj、Cargo.toml)から言語、フレームワーク、環境タイプを特定します。既存の LaunchDarkly の使用(launchdarkly、ldclient、LDClient、@launchdarkly)を検索します。サーバーサイド、クライアントサイド、モバイルのいずれかを判断します。これが SDK の選択を左右します。LD がすでに統合されている場合は、インストールをスキップできるよう SDK のバージョンを記録します。
--agent フラグのためにコーディングエージェントを検出します: Cursor(.cursor/、.cursorrules)、Claude Code(~/.claude/、CLAUDE.md)、Windsurf(.windsurfrules)、GitHub Copilot(.github/copilot/)、Codex(~/.codex/、AGENTS.md)。曖昧な場合は質問します。
ステップ 2: MCP(オプション、フラグの後)
最初のフラグに至る途中で MCP をセットアップしないでください。また、セットアップ中にそれについて質問しないでください。それなしで最初のフラグに到達してください(ステップ 4 ではダッシュボードリンクを使用します)。フラグが機能した後にのみ、1 つの短い選択肢として提示します:
「次回はエディタからフラグを管理したいですか? それをセットアップできます。[セットアップする] [スキップ]」
セットアップするを選択した場合: mcp-configure に従ってください。そのネストされたスキルがセッションで利用できない場合は、インストールします:
npx skills add launchdarkly/ai-tooling --skill mcp-configure -y --agent <detected-agent>
それが失敗した場合は、~/.agents/skills/ と ~/.cursor/skills/ にキャッシュされたコピーがないか確認するか、MCP Config Templates を使用してサーバーをインラインで構成します。成功したら、get-project を 1 回呼び出し(projectKey: "default")、projectKey と envKey(test)を保存します。
ステップ 3:SDK をインストールする
SDK をインストールし、初期化を自動的に設定します。方法を尋ねたり、SDK の説明をしたりしないでください。ユーザーには次の一文だけを伝えてください。「スキャンが完了しました。SDK をインストールしています。」その後、作業を進めます。
ステップ 1 のスタック情報を引き継いで、sdk-install に引き継ぎます。ここでは検出、計画、適用を行い、パッケージを選択してインストールし、コードベースに合わせて初期化を設定します。このセッションでネストされたスキルを利用できない場合は、インストールしてください。
npx skills add launchdarkly/ai-tooling --skill sdk-install -y --agent <detected-agent>
ステップ 1 でエージェントがアプリをスキャフォールドした場合は、ネストされたスキルをスキップし、ファストパスを直接使用してください(スタックは判明しているため、npm run build はスキップします)。
| スキャフォールド | パッケージ | インストール | 環境変数 | エントリーポイント | 初期化 |
|---|---|---|---|---|---|
| React (Vite) | launchdarkly-react-client-sdk | npm install launchdarkly-react-client-sdk | VITE_LAUNCHDARKLY_CLIENT_SIDE_ID | src/main.jsx/.tsx | ルートのレンダリングを asyncWithLDProvider でラップ |
| Node.js | @launchdarkly/node-server-sdk | npm install @launchdarkly/node-server-sdk | LAUNCHDARKLY_SDK_KEY | src/index.js/server.js | init(sdkKey) の後に waitForInitialization() |
| Python | launchdarkly-server-sdk | pip install launchdarkly-server-sdk | LAUNCHDARKLY_SDK_KEY | app.py/main.py | ldclient.set_config(Config(sdk_key)) の後に ldclient.get() |
ルール:SDK キーは環境変数に保存し、ハードコードしないでください。クライアントインスタンスは 1 つだけ作成して共有します。フラグを評価する前に、初期化を待機してください。
可観測性プラグイン
ユーザーがいつでも(最初のメッセージ、進行中、オンボーディング完了後のフォローアップ(「可観測性プラグインも追加できますか?」など)で)可観測性、セッションリプレイ、エラーモニタリング、ログ、トレースに言及した場合は、必ず適用してください。スタックごとのパッケージと設定方法については、可観測性プラグイン に従ってください。要点は次のとおりです。
- LaunchDarkly クライアントの既存の初期化にある
pluginsオプションへプラグインを追加し、既存のキーを再利用します。クライアントや認証情報を追加したり、キーを尋ねたりしないでください。 - クライアントがすでに初期化されている場合は、SDK のインストールをやり直したりキーを尋ねたりせず、その初期化にプラグインを追加してください。オンボーディング中の場合は、その後いつもどおり最初のフラグへ進みます。オンボーディング完了後のフォローアップの場合は、一文で完了を伝えて終了します。オンボーディングを再開したり、最初のフラグを新たに設定したりしないでください。
- プライバシーレベルの指定がないセッションリプレイには、最も厳格な設定(ブラウザーでは
privacySetting: 'strict')を使用します。 - インストール済み SDK が
pluginsに対応しておらず、修正にメジャーバージョンのアップグレードまたは別パッケージへの変更が必要な場合は、バージョンの問題を一文で説明し、変更前に確認してください。 - スタックに可観測性プラグインがない場合は、その旨を一文で伝え、フィーチャーフラグの設定を続けてください。OpenTelemetry や別のパッケージで代用しないでください。
SDK キー
SDK にはキーが必要です。MCP に接続されている場合は、ユーザーに代わってキーを取得することをデフォルトとしてください。接続されていない場合は、直接リンクを提示し、ユーザーにキーを貼り付けてもらいます。経路を判断できない場合に限り、尋ねてください。
{
"questions": [
{
"id": "sdk_key_setup",
"prompt": "Do you have a LaunchDarkly account?",
"options": [
{ "id": "yes", "label": "Yes" },
{ "id": "no_account", "label": "Not yet" }
]
}
]
}
- アカウントがあり、MCP に接続されている場合:
get-environmentsでキーを取得し、.envに書き込み、.envが gitignore 対象であることを確認します。キーの値は決して表示しないでください。 - アカウントがあり、MCP に接続されていない場合:直接リンクを提示し、ユーザーにキーを貼り付けてもらいます。
https://app.launchdarkly.com/projects/{projectKey}/settings/environments/{envKey}/keys - アカウントがない場合:解決済みのサインアップリンクを共有します。コードがコンパイルできるよう、プレースホルダーの環境変数を書き込み、そのまま続行します。
キーの種類はインテグレーションに合わせる必要があります。サーバーサイド SDK には SDK キー、ブラウザー/クライアントサイドには クライアントサイド ID、モバイルには モバイルキーを使用します。環境変数名とバンドラーのルールについては、コード変更を適用する を参照してください。
初期化が検証されるまで、先へ進まないでください。
ステップ 4:最初のフラグ
フラグを作成してアプリに組み込み、ユーザーがオンになる様子を確認できるようにします。
- フラグを作成します。 MCP が接続されている場合は、
create-flagを呼び出します(重複キーの競合が発生した場合は、get-flagを呼び出して既存のフラグを採用します。先にlist-flagsは呼び出さないでください)。MCP が接続されていない場合は、キーが事前入力された作成フォームを開くダッシュボードリンクを案内し、ユーザーに作成してもらいます:https://app.launchdarkly.com/projects/{projectKey}/flags/new?key={flagKey} - フラグで表示を切り替えるバナーを追加します。 アプリのメインページの上部に、フラグで表示を切り替える小さくすっきりとしたバナーを挿入します。オフの状態:LaunchDarkly でフラグを確認するリンクを含む、中立的な「LaunchDarkly test banner (flag is off)」というバナー。オンの状態:バナーは明らかに異なる見た目(たとえば緑色の背景)に切り替わり、「LaunchDarkly test banner (flag is on)」と表示します。デバッグ出力のように見えないよう、意図的にデザインしてください。既存のアプリに追加し、書き換えないでください。レンダリングされるページがないアプリの場合は、フラグの状態によって変化する、同等の表示を 1 つ(エンドポイントまたは起動時の行)追加します。
- 空いているポートで開発サーバーを起動します(先に
lsof -ti :3000,4000,5173を確認してください)。ユーザーがフラグがオンになるのを確認するまで、サーバーを起動したままにしてください。それまではサーバーを停止しないでください。 - 切り替え操作をユーザーに引き継ぎます。 ローカル URL と、フラグをオンにする方法を 1 つ案内してください:
{
"questions": [
{
"id": "flip_method",
"prompt": "Your app is running at <url> and the flagged element is off. Turn the flag on to watch it change. How do you want to flip it?",
"options": [
{ "id": "ld_ui", "label": "I'll flip it in LaunchDarkly" },
{ "id": "agent", "label": "Flip it for me" }
]
}
]
}
- I'll flip it in LaunchDarkly(LaunchDarkly で切り替える) の場合:フラグへの直接リンクを案内して、待ちます。
https://app.launchdarkly.com/projects/{projectKey}/flags/{flagKey}/targeting?env={envKey} - Flip it for me(代わりに切り替える) の場合:設定されている方法に応じて、MCP の
toggle-flagまたは REST API でオンにします。どちらも設定されていない場合は、ダッシュボードリンクを案内します。 - MCP または API トークンが実際に設定されている場合にのみ、Flip it for me を提示してください。そうでない場合は、LaunchDarkly の選択肢だけを表示します。
ページやバナーのテキストをチャットに出力しないでください。ユーザーをブラウザーに案内してください:<url> のバナーは、サーバーを起動したままライブで切り替わります。これがフラグの動作です。
まとめ
数行にまとめます:
- フラグは有効です。LaunchDarkly で確認できます:
https://app.launchdarkly.com/projects/{projectKey}/flags/{flagKey}/targeting?env={envKey} - 変更はコミットされていません。変更は
launchdarkly-onboardingブランチにあるため、自由に確認、保持、または破棄できます。 - 次に行うことを 1 つ選んでもらいます。セットアップ中にプラグインを追加した場合は、オブザーバビリティの選択肢を除外します。
{
"questions": [
{
"id": "explore_next",
"prompt": "Want to explore more of LaunchDarkly?",
"options": [
{ "id": "experimentation", "label": "Experimentation: test changes and measure impact" },
{ "id": "observability", "label": "Observability: monitor flags and errors in production" },
{ "id": "ai_configs", "label": "AI Configs: manage AI models and prompts" },
{ "id": "done", "label": "Not now" }
]
}
]
}
手順からの逸脱への対応
ユーザーが手順の途中でステップを省略したり先に進んだりしたいと言った場合、コードを書く、またはステップを省略する前に、最初の返信で必ず次の 3 つを順番に行います。
- ユーザーの依頼を、その言葉を使って確認します。
- 省略によって生じる具体的な影響を 1 文で伝えます。何が動かなくなるかを明示します(例:「SDK がインストールされるまで、フラグの呼び出しは実行されません」)。曖昧な表現ではなく、実際に起こる問題を伝えます。
- 選択肢を提示します。先に簡単なステップを完了するか、ユーザーの希望どおりに進めるかを尋ねます。
「フラグのコードを今すぐ見たいということですね。SDK をインストールしないと、これらの呼び出しは実行されません。セットアップは 2 分ほどで完了します。先にセットアップを済ませますか、それとも後で組み込めるコードをお渡ししましょうか?」
トレードオフを説明せずにコードを一方的に提示してはいけません。また、杓子定規に拒否してもいけません。ユーザーがそれでも希望する場合は尊重し、省略した内容を伝え、リスクを 1 文で改めて説明してから続行します。
スキルリポジトリ
| リポジトリ | スキル | 目的 |
|---|---|---|
launchdarkly/ai-tooling | onboarding、sdk-install、mcp-configure | セットアップ |
launchdarkly/ai-tooling | launchdarkly-flag-create など | フラグ管理 |
エッジケース
- SDK がすでにインストールされている場合: ステップ 3 をスキップします。確認した内容と場所を明記した一文で伝え、ステップ 4 に進みます。SDK について再度説明したり、インストールコマンドを実行したりしないでください。ユーザーがオブザーバビリティを希望している場合は、まず既存のクライアントにプラグインを追加してください(オブザーバビリティプラグイン)。
- MCP がすでに設定されている場合: そのまま使用します。ステップ 2 の提案をスキップします。
get-projectを呼び出してキーを保存し、続行します。 - 非推奨の mcp/aiconfigs または mcp/fm が見つかった場合: どちらも非推奨です。統合された
mcp/launchdarklyサーバーへの移行について、事前に確認してください。自動で移行しないでください。 - 対応しているエージェントが検出されない場合: ユーザーに直接確認してください。必要に応じて手動設定を提示します。
- npx が利用できない場合: 手動でのスキルのインストール方法(リポジトリのクローン、スキルディレクトリのコピー)を提示します。
- ユーザーが一部のみのセットアップを希望する場合: その希望を尊重してください。不足している内容と、それによる制限を伝えます。
- SDK のインストールまたはコンパイルに LaunchDarkly 以外の依存関係の変更(peer-dep の更新、ロックファイルの変更など)が必要な場合: コード変更の適用に従い、必ず事前に明示的な承認を得てください。
参照
- mcp-configure と MCP 設定テンプレート — ステップ 2
- sdk-install — ステップ 3(検出、計画、適用)
- SDK レシピ と SDK スニペット — SDK ごとのインストールと初期化の詳細
- オブザーバビリティプラグイン — ユーザーがオブザーバビリティまたはセッションリプレイを希望する場合のステップ 3