detect

リポジトリのスタックを検出する（SDK インストール）

何かをインストールする前に、プロジェクトを理解する必要があります。プロジェクトが何で構築されているか、LaunchDarkly がすでに存在するかどうかを特定してください。

このスキルは LaunchDarkly SDK インストール（オンボーディング） の配下にあります。親の ステップ 1 は 検出 です。次: 決定木によって別の場所へ誘導されない限り、統合プランを生成する に進みます。

1. 言語とフレームワーク

以下の指標となるファイル（および関連するルート構成）を探し、該当するマニフェストを読んで言語とフレームワークを推測します。

スタックを特定するために、以下のファイルを探してください:

ファイル	言語/フレームワーク
package.json	JavaScript/TypeScript（React、Next.js、Vue、Angular、Express、React Native、Electron などがないか確認）
requirements.txt、pyproject.toml、Pipfile、setup.py	Python（Django、Flask、FastAPI がないか確認）
go.mod	Go（Gin、Echo、Fiber、Chi がないか確認）
pom.xml、build.gradle、build.gradle.kts	Java/Kotlin（Spring、Quarkus、Android がないか確認）
Gemfile	Ruby（Rails、Sinatra がないか確認）
*.csproj、*.sln、*.fsproj	.NET/C#（ASP.NET、MAUI、Xamarin、WPF、UWP がないか確認）
composer.json	PHP（Laravel、Symfony がないか確認）
Cargo.toml	Rust（Actix、Axum、Rocket がないか確認）
pubspec.yaml	Flutter/Dart
Package.swift、Podfile、*.xcodeproj	Swift/iOS
AndroidManifest.xml	Android（build.gradle に com.android がないかも確認）
rebar.config、mix.exs	Erlang/Elixir
CMakeLists.txt、Makefile（C/C++ のパターンを含むもの）	C/C++（#include パターンがないか確認）
*.cabal、stack.yaml	Haskell
*.lua、rockspec	Lua
manifest、*.brs	Roku（BrightScript）
wrangler.toml	Cloudflare Workers（エッジ SDK）
エッジ関数を含む vercel.json	Vercel Edge（エッジ SDK）

依存関係ファイルを読んで、具体的なフレームワークを特定します。package.json の場合は、dependencies と devDependencies の両方を確認してください。

言語またはフレームワークを特定できない場合:

D5 -- BLOCKING: 構造化質問ツールを今すぐ呼び出してください。

• question: 「プロジェクトの言語またはフレームワークを検出できませんでした。どの SDK を使用しますか？」
• options: SDK レシピ から利用可能な SDK を選択肢として提示します。
• STOP。質問をテキストとして書かないでください。ユーザーが選択肢を選ぶまで続行しないでください。

2. パッケージマネージャー

プロジェクトが依存関係をどのようにインストールするかを特定します:

指標	パッケージマネージャー
package-lock.json	npm
yarn.lock	yarn
pnpm-lock.yaml	pnpm
bun.lockb	bun
Pipfile.lock	pipenv
poetry.lock	poetry
go.sum	go modules
Gemfile.lock	bundler

検出されたパッケージマネージャーを、すべてのインストールコマンドに使用してください。複数のロックファイルが存在する場合は、最も最近変更されたものを優先してください。

3. モノレポの構成

一部のリポジトリは複数のパッケージやサービスをホストしています。以下の指標を探してください:

ファイル / パターン	ツールまたは構成
pnpm-workspace.yaml	pnpm workspaces
lerna.json	Lerna
nx.json	Nx
turbo.json	Turborepo
rush.json	Rush
複数の package.json ファイルを含む packages/ ディレクトリ	汎用モノレポ

これらのいずれかに該当する場合、リポジトリのルートが統合対象であると仮定しないでください:

D5 -- BLOCKING: 構造化質問ツールを今すぐ呼び出してください。

• question: 「これはモノレポです。どのパッケージ、アプリ、またはサービスに LaunchDarkly を統合すべきですか？」
• options: 検出されたパッケージ/アプリを選択肢として列挙します。
• STOP。質問をテキストとして書かないでください。ユーザーが選択肢を選ぶまで続行しないでください。

その後、この検出ステップの残り（言語、パッケージマネージャー、エントリポイント、SDK 検索）を、ルートだけでなくその対象ディレクトリ（およびそのサブツリー）で実行してください。

4. アプリケーションのエントリーポイント

アプリケーションが起動するメインファイルを探します。モノレポの場合は、セクション 3 モノレポのレイアウトの後で、選択したパッケージ内で以下のパターンを適用します。一般的なパターン:

• Node.js (サーバー): package.json の "main" フィールドを確認するか、index.js、server.js、app.js、src/index.ts を探します
• NestJS: src/main.ts または src/main.js を探します
• Python: app.py、main.py、manage.py、wsgi.py、または [tool.poetry.scripts] セクションを探します
• Go: main.go または cmd/*/main.go を探します
• Java: public static void main または @SpringBootApplication を検索します
• Ruby: config.ru、config/application.rb を探します
• React/Vue/Angular: src/index.tsx、src/main.tsx、src/App.tsx、src/main.ts を探します
• Next.js: App Router -- app/layout.tsx または app/layout.js (ルートレイアウト)。Pages Router -- pages/_app.tsx または pages/_app.js
• React Native: App.tsx、App.js、index.js (AppRegistry.registerComponent を含むもの) を探します
• Electron: package.json の "main" を確認します。一般的なパスには main.js や src/main.ts があります
• JavaScript (ブラウザ): index.html、src/index.js、または webpack.config.js / vite.config.ts 内のバンドラーエントリーを探します
• Flutter: lib/main.dart を探します
• Swift/iOS: AppDelegate.swift、SceneDelegate.swift、または @main 構造体を探します
• Android: MainActivity.java または MainActivity.kt を探します

5a. ワークスペースの信頼度を分類する

セクション 1 から 4 の後、続行する前にワークスペースを 3 つの状態のいずれか に分類します。この分類によって、以降のフローの進め方が決まります。

状態	意味	基準
明確なアプリ	実行可能なアプリケーションが見つかった	言語/フレームワークが検出され、実際のエントリポイントが存在し、アプリケーションの依存関係を含む依存関係マニフェストが存在する
不明確 / 弱い証拠	何かは存在するが、実行可能なアプリを明確に表していない	散発的または最小限の package.json (例: devDependencies のみで scripts がない)、孤立した設定/マニフェストファイル、テーマまたは設定のみのフォルダ、トークン/フィクスチャの JSON、対応するソースがないロックファイル、または支配的なアプリ構造がないまま複数の矛盾する指標がある
アプリが見つからない	認識可能なアプリケーション構造が検出されなかった	依存関係マニフェストがない、エントリポイントがない、既知のパターンに一致するソースファイルがない、またはワークスペースが空である / ドキュメントのみを含む

弱い証拠を確認と見なしてはいけません。 弱い証拠の例:

• scripts セクションがなく、アプリケーションのソースファイルもない package.json
• データファイルやノートブックのディレクトリに単独で存在する requirements.txt
• 実行可能なサービスを表さないマニフェストを含む設定、テーマ、またはフィクスチャのディレクトリ
• 実際のアプリがサブディレクトリにあるのに、どれも選択されていないモノレポのルート

状態による分岐:

• 明確なアプリ → セクション 6 (既存の LaunchDarkly SDK) に進み、その後 SDK の確認を行います。

• 不明確 / 弱い証拠:

D5-UNCLEAR -- BLOCKING: ここで構造化質問ツールを呼び出してください。

• question: 「いくつかのプロジェクトファイルを見つけましたが、統合すべき正しいアプリケーションを特定できた自信がありません。正しいアプリのフォルダを教えていただけますか?」
• context: 見つけたものと、それが曖昧である理由を簡潔に説明してください (例: 「ルートに package.json がありますが、start スクリプトもアプリケーションのソースファイルもありません」)。
• options:
  • 検出した候補フォルダを選択可能なオプションとして提示する
  • 「別の場所にあります -- パスを伝えます」
  • 「まだアプリはありません -- デモの作成を手伝ってください」
• STOP。ユーザーが対象を確認するまで、コード変更、パッケージのインストール、統合計画の生成を行わないでください。ユーザーがオプションを選択するまで続行しないでください。

ユーザーが正しいフォルダを指し示したら、そのフォルダを対象に検出 (セクション 1 から 4) を再実行します。

• アプリが見つからない:

ユーザーにはっきりと伝えてください: 「このワークスペースには実行可能なアプリケーションが見つかりませんでした。」 次に 2 つの道筋を提示します:

D5-NOAPP -- BLOCKING: ここで構造化質問ツールを呼び出してください。

• question: 「このワークスペースには実行可能なアプリケーションが見つかりませんでした。どのように進めますか?」
• options:
  • 「正しいフォルダを教えます -- アプリは別の場所にあります」
  • 「LaunchDarkly を試せるように最小限のデモアプリを作成してください」
• STOP。ユーザーがオプションを選択するまで続行しないでください。

ユーザーが「正しいフォルダを教えます」を選んだ場合、提供されたパスを対象に検出を再実行します。ユーザーが「デモアプリを作成してください」を選んだ場合、新しいサブフォルダ (例: launchdarkly-demo/) に、スキャフォールドできる最もシンプルなスタック (Node.js + Express または静的 HTML ページが適切なデフォルトです) を使って最小限の実行可能アプリを作成し、そのサブフォルダから検出を続行します。

アプリの対象が確認され、アプリが実際に実行できる状態でなければ、オンボーディング完了と宣言しないでください。

6. 既存の LaunchDarkly SDK

コードベースで既存の LaunchDarkly の使用を検索します:

Search for: launchdarkly, ldclient, ld-client, LDClient, @launchdarkly, launchdarkly-

確認:

• SDK はすでに依存関係ファイルに含まれていますか?
• 初期化コードはありますか?
• 適切に設定されていますか、それとも部分的にセットアップされていますか?
• すでにフィーチャーフラグの評価はありますか?

SDK の確認

スタックを検出したら、SDK の選択をユーザーに確認します。

• 1 つの SDK が明らかに適切な場合: 推奨事項を提示して確認を得ます。

D5 -- BLOCKING: ここで構造化質問ツールを呼び出してください。

• question: 「検出結果に基づき、[SDK 名] SDK を推奨します。これでよろしいですか？」

• options:

  • 「はい、その SDK で進めてください」 -> 計画へ進む
  • 「いいえ、別のものを希望します」 -> ユーザーに指定してもらう

• STOP。質問をテキストとして書かないでください。ユーザーがオプションを選択するまで続行しないでください。

• 複数の SDK が該当する可能性がある場合（例: サーバーコンポーネントとクライアントコンポーネントの両方を持つ Next.js プロジェクト）:

  • ユーザーがすでに両方を求めている場合（例: 「フロントエンドとバックエンド」、「サーバー + ブラウザ」、「API と SPA」）: これを デュアル SDK のスコープとして扱います。統合計画の生成 へ進み、両方 の SDK をスコープに含めます -- 片方だけを計画・実装し、もう片方が「カバーされている」と見なしては いけません。
  • スコープが不明確な場合:

D5 -- BLOCKING: ここで構造化質問ツールを呼び出してください。

• question: 「このプロジェクトにはサーバーサイドとクライアントサイドの両方のサーフェスがあります。どちらを統合しますか？」
• options:
  • 「サーバーサイドのみ」
  • 「クライアントサイドのみ」
  • 「サーバーサイドとクライアントサイドの両方」
• STOP。質問をテキストとして書かないでください。ユーザーがオプションを選択するまで続行しないでください。

両方 を選択した場合、計画には 2 つ の具体的な統合を含める必要があります（計画: デュアル SDK 統合 を参照）。

• 適切な SDK を判断できない場合: SDK レシピ から利用可能なオプションを質問ツールの選択可能なオプションとして提示し、上記と同じブロッキングパターンを使用します。

決定ツリー

検出と確認の後:

• アプリが見つからない、または不明確 --> セクション 5a の D5-NOAPP / D5-UNCLEAR で処理済みです。ユーザーが実際のアプリのターゲットを確認するまで計画へ進まないでください。
• SDK がすでにインストールされ初期化済み --> 親スキルの ステップ 4: 最初のフラグ へスキップします
• SDK はインストール済みだが初期化されていない --> コード変更の適用 へスキップします（init コードを追加するだけです）
• SDK が存在しない --> 統合計画の生成 へ進みます
• 複数のターゲットが検出された場合（例: フロントエンド + バックエンド） --> ユーザーが 両方 の SDK を希望する場合（上記の D5 で確認済み）、デュアル SDK スコープ（2 つのパッケージ、2 つのエントリポイント）で 統合計画の生成 へ進みます。1 つ のサーフェスのみを希望する場合は、その単一の SDK について計画します。
• 言語が検出されない --> セクション 1 の D5 ブロッキング質問で処理済みです。

---

完了時（通常のパス）: 統合計画の生成