MCPInstall

detect

Detect repository stack for LaunchDarkly SDK onboarding: languages, frameworks, package managers, monorepo targets, entrypoints, existing LD usage. Nested under sdk-install; next is plan.

Installs
2.3K
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/launchdarkly/ai-tooling --skill detect
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads detect automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Detect repository stack (SDK install)

Before installing anything, you must understand the project. Identify what the project is built with and whether LaunchDarkly is already present.

This skill is nested under LaunchDarkly SDK Install (onboarding); the parent Step 1 is detect. Next: Generate integration plan unless the decision tree sends you elsewhere.

1. Language and framework

Look for the indicator files below (and related root layout), then read the relevant manifests to infer language and framework.

Look for these files to identify the stack:

FileLanguage/Framework
package.jsonJavaScript/TypeScript (check for React, Next.js, Vue, Angular, Express, React Native, Electron, etc.)
requirements.txt, pyproject.toml, Pipfile, setup.pyPython (check for Django, Flask, FastAPI)
go.modGo (check for Gin, Echo, Fiber, Chi)
pom.xml, build.gradle, build.gradle.ktsJava/Kotlin (check for Spring, Quarkus, Android)
GemfileRuby (check for Rails, Sinatra)
*.csproj, *.sln, *.fsproj.NET/C# (check for ASP.NET, MAUI, Xamarin, WPF, UWP)
composer.jsonPHP (check for Laravel, Symfony)
Cargo.tomlRust (check for Actix, Axum, Rocket)
pubspec.yamlFlutter/Dart
Package.swift, Podfile, *.xcodeprojSwift/iOS
AndroidManifest.xmlAndroid (also check build.gradle for com.android)
rebar.config, mix.exsErlang/Elixir
CMakeLists.txt, Makefile (with C/C++ patterns)C/C++ (check for #include patterns)
*.cabal, stack.yamlHaskell
*.lua, rockspecLua
manifest, *.brsRoku (BrightScript)
wrangler.tomlCloudflare Workers (edge SDK)
vercel.json with edge functionsVercel Edge (edge SDK)

Read the dependency file to identify the specific framework. For package.json, check both dependencies and devDependencies.

If you cannot identify the language or framework:

D5 -- BLOCKING: Call your structured question tool now.

  • question: "I couldn't detect the project's language or framework. Which SDK would you like to use?"
  • options: Present the available SDKs from SDK recipes as selectable options.
  • STOP. Do not write the question as text. Do not continue until the user selects an option.

2. Package manager

Identify how the project installs dependencies:

IndicatorPackage Manager
package-lock.jsonnpm
yarn.lockyarn
pnpm-lock.yamlpnpm
bun.lockbbun
Pipfile.lockpipenv
poetry.lockpoetry
go.sumgo modules
Gemfile.lockbundler

Use the detected package manager for all install commands. If multiple lock files exist, prefer the one that was most recently modified.

3. Monorepo layout

Some repositories host multiple packages or services. Look for these indicators:

File / patternTool or layout
pnpm-workspace.yamlpnpm workspaces
lerna.jsonLerna
nx.jsonNx
turbo.jsonTurborepo
rush.jsonRush
packages/ directory with multiple package.json filesGeneric monorepo

When any of these apply, do not assume the repo root is the integration target:

D5 -- BLOCKING: Call your structured question tool now.

  • question: "This is a monorepo. Which package, app, or service should I integrate LaunchDarkly into?"
  • options: List the discovered packages/apps as selectable options.
  • STOP. Do not write the question as text. Do not continue until the user selects an option.

Then run the rest of this detect step -- language, package manager, entrypoint, and SDK search -- in that target directory (and its subtree), not only at the root.

4. Application entrypoint

Find the main file where the application starts. In a monorepo, apply the patterns below within the chosen package after section 3 Monorepo layout. Common patterns:

  • Node.js (server): Check package.json "main" field, or look for index.js, server.js, app.js, src/index.ts
  • NestJS: Look for src/main.ts or src/main.js
  • Python: Look for app.py, main.py, manage.py, wsgi.py, or the [tool.poetry.scripts] section
  • Go: Look for main.go or cmd/*/main.go
  • Java: Search for public static void main or @SpringBootApplication
  • Ruby: Look for config.ru, config/application.rb
  • React/Vue/Angular: Look for src/index.tsx, src/main.tsx, src/App.tsx, src/main.ts
  • Next.js: App Router -- app/layout.tsx or app/layout.js (root layout). Pages Router -- pages/_app.tsx or pages/_app.js
  • React Native: Look for App.tsx, App.js, index.js (with AppRegistry.registerComponent)
  • Electron: Check package.json "main"; common paths include main.js or src/main.ts
  • JavaScript (browser): Look for index.html, src/index.js, or bundler entry in webpack.config.js / vite.config.ts
  • Flutter: Look for lib/main.dart
  • Swift/iOS: Look for AppDelegate.swift, SceneDelegate.swift, or @main struct
  • Android: Look for MainActivity.java or MainActivity.kt

5a. Classify workspace confidence

After sections 1-4, classify the workspace into one of three states before continuing. This classification determines how the rest of the flow proceeds.

StateMeaningCriteria
Clear appA runnable application was foundLanguage/framework detected, a real entrypoint exists, dependency manifest is present with application dependencies
Unclear / weak evidenceSomething is present but it does not clearly represent a runnable appStray or minimal package.json (e.g. only devDependencies, no scripts), isolated config/manifest files, theme or config-only folders, token/fixture JSON, lockfiles without corresponding source, or multiple conflicting indicators with no dominant app structure
No app foundNo recognizable application structure was detectedNo dependency manifests, no entrypoints, no source files matching known patterns, or the workspace is empty / contains only documentation

Weak evidence must not be treated as confirmation. Examples of weak evidence:

  • A package.json with no scripts section and no application source files
  • A lone requirements.txt in a directory of data files or notebooks
  • Config, theme, or fixture directories with manifests that do not represent a runnable service
  • Monorepo roots where the real apps live in subdirectories but none was selected

Branching by state:

D5-UNCLEAR -- BLOCKING: Call your structured question tool now.

  • question: "I found some project files, but I'm not confident I've identified the right application to integrate. Can you point me to the correct app folder?"
  • context: Briefly describe what you found and why it's ambiguous (e.g., "There's a package.json at the root, but it has no start script and no application source files").
  • options:
    • Present any candidate folders you detected as selectable options
    • "It's somewhere else -- I'll tell you the path"
    • "There is no app yet -- help me create a demo"
  • STOP. Do not make code changes, install packages, or generate an integration plan until the user confirms the target. Do not continue until the user selects an option.

After the user points to the correct folder, re-run detection (sections 1-4) scoped to that folder.

  • No app found:

Tell the user clearly: "I didn't find a runnable application in this workspace." Then offer two paths:

D5-NOAPP -- BLOCKING: Call your structured question tool now.

  • question: "I didn't find a runnable application in this workspace. How would you like to proceed?"
  • options:
    • "Point me to the right folder -- the app is somewhere else"
    • "Create a minimal demo app so I can try LaunchDarkly"
  • STOP. Do not continue until the user selects an option.

If the user chooses "point me to the right folder," re-run detection scoped to the path they provide. If they choose "create a demo app," create a minimal runnable app in a new subfolder (e.g. launchdarkly-demo/) using the simplest stack you can scaffold (Node.js + Express or a static HTML page are good defaults), then continue detection from that subfolder.

Do not declare onboarding complete unless the app target has been confirmed and the app can actually run.

6. Existing LaunchDarkly SDK

Search the codebase for existing LaunchDarkly usage:

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

Check:

  • Is the SDK already in the dependency file?
  • Is there initialization code?
  • Is it properly configured or partially set up?
  • Are there already feature flag evaluations?

SDK confirmation

After detecting the stack, confirm the SDK choice with the user:

  • If one SDK is clearly the right fit: Present your recommendation and get confirmation:

D5 -- BLOCKING: Call your structured question tool now.

  • question: "Based on what I found, I recommend the [SDK name] SDK. Does that look right?"

  • options:

    • "Yes, proceed with that SDK" -> continue to plan
    • "No, I want a different one" -> let user specify
  • STOP. Do not write the question as text. Do not continue until the user selects an option.

  • If multiple SDKs could apply (e.g., a Next.js project with both server and client components):

    • If the user already asked for both (e.g. "frontend and backend," "server + browser," "API and SPA"): Treat that as a dual-SDK scope. Proceed to Generate integration plan with both SDKs in scope -- do not plan or implement only one and assume the other is "covered."
    • If scope is unclear:

D5 -- BLOCKING: Call your structured question tool now.

  • question: "This project has both server-side and client-side surfaces. Which do you want to integrate?"
  • options:
    • "Server-side only"
    • "Client-side only"
    • "Both server-side and client-side"
  • STOP. Do not write the question as text. Do not continue until the user selects an option.

If they choose both, the plan must include two concrete integrations (see plan: Dual SDK integrations).

  • If you cannot determine the right SDK: Present the available options from the SDK recipes as selectable options in your question tool and use the same blocking pattern above.

Decision tree

After detection and confirmation:

  • No app found or unclear --> Already handled by D5-NOAPP / D5-UNCLEAR in section 5a. Do not proceed to plan until the user confirms a real app target.
  • SDK already installed and initialized --> Skip to the parent skill's Step 4: First Flag
  • SDK installed but not initialized --> Skip to Apply code changes (just add init code)
  • SDK not present --> Continue to Generate integration plan
  • Multiple targets detected (e.g., frontend + backend) --> If the user wants both SDKs (confirmed via D5 above), continue to Generate integration plan with dual-SDK scope (two packages, two entrypoints). If they want one surface only, plan for that single SDK.
  • Language not detected --> Already handled by the D5 blocking question in section 1.

Upon completion (normal path): Generate integration plan

FAQ

What does the detect skill do?

Detect repository stack for LaunchDarkly SDK onboarding: languages, frameworks, package managers, monorepo targets, entrypoints, existing LD usage. Nested under sdk-install; next is plan.

How do I install detect?

Run npx skills add https://github.com/launchdarkly/ai-tooling --skill detect in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/detect/ (personal) or .claude/skills/detect/ (project).

Which AI agents can use detect?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is detect safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains detect?

It is published by launchdarkly in launchdarkly/ai-tooling, and it is an official skill from the maker of the technology it covers. It has 2,284 recorded installs.

More from launchdarkly/ai-tooling

View all →

onboarding

launchdarkly/ai-tooling

Scripted onboarding for LaunchDarkly: quiet execution, fixed sequence, SDK install, first flag with a live reveal, MCP offered afterwards. Enforces step completion before advancing and redirects drift. Use when adding LaunchDarkly, setting up or integrating feature flags in a project, SDK integration, or 'onboard me'.

OfficialAI & Agents4.8K installs

launchdarkly-flag-discovery

launchdarkly/ai-tooling

Audit your LaunchDarkly feature flags to understand the landscape, find stale or launched flags, and assess removal readiness. Use when the user asks about flag debt, stale flags, cleanup candidates, flag health, or wants to understand their flag inventory.

OfficialSecurity4.2K installs

launchdarkly-flag-create

launchdarkly/ai-tooling

Create and configure LaunchDarkly feature flags in a way that fits the existing codebase. Use when the user wants to create a new flag, wrap code in a flag, add a feature toggle, or set up an experiment. Guides exploration of existing patterns before creating.

OfficialCode Quality & Workflow4.1K installs

launchdarkly-flag-targeting

launchdarkly/ai-tooling

Control LaunchDarkly feature flag targeting including toggling flags on/off, percentage rollouts, targeting rules, individual targets, and copying flag configurations between environments. Use when the user wants to change who sees a flag, roll out to a percentage, add targeting rules, or promote config between environments.

Official4.1K installs

launchdarkly-flag-cleanup

launchdarkly/ai-tooling

Safely remove a feature flag from code while preserving production behavior. Use when the user wants to remove a flag from code, delete flag references, or create a PR that hardcodes the winning variation after a rollout is complete.

OfficialCode Quality & Workflow4.1K installs

launchdarkly-metric-choose

launchdarkly/ai-tooling

Choose the right metrics for a LaunchDarkly experiment, guarded rollout, or release policy. Use when the user wants to know which metrics to use, which is the primary metric for an experiment, what guardrails to add, or which events to monitor in a rollout. Surfaces what will auto-attach from existing release policies before making additional recommendations.

Official3.3K installs

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.