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.
Security Assessment
Detected risks:
About detect
detect is the first step of LaunchDarkly's SDK-install onboarding flow, responsible for understanding a repository before anything is installed. It identifies the languages and frameworks in use, the package manager, any monorepo structure, the application entrypoints, and whether LaunchDarkly is already present, then hands off to the plan step. Nothing is modified during detection; the goal is an accurate picture of the project.
Language and framework detection keys off indicator files and their manifests: package.json for JavaScript and TypeScript stacks such as React, Next.js, or Express; requirements.txt or pyproject.toml for Python and Django, Flask, or FastAPI; go.mod, pom.xml, Gemfile, .csproj, composer.json, Cargo.toml, pubspec.yaml, and many more, including edge targets like Cloudflare Workers and Vercel Edge. The package manager is inferred from lock files such as package-lock.json, yarn.lock, pnpm-lock.yaml, and bun.lockb, preferring the most recently modified when several coexist. Monorepo layouts are recognized through workspace tooling such as pnpm workspaces, Lerna, Nx, Turborepo, and Rush, and in that case the repo root is not assumed to be the target: a blocking question asks which package or service to integrate, and the remaining detection runs inside that subtree. Entrypoint discovery applies per-framework patterns to locate the file where the application starts.
A distinctive part of the step is workspace-confidence classification. After gathering evidence, the workspace is placed into one of three states: a clear runnable app, unclear or weak evidence, or no app found. Weak evidence such as a stray package.json with no scripts, a lone requirements.txt amid data files, or config-and-fixture directories is explicitly not treated as confirmation, and an ambiguous or empty workspace triggers a blocking question asking the user to point to the correct app or to opt into creating a demo. Blocking decision points also fire when the language or framework cannot be identified, prompting the user to choose an SDK from the available recipes. The overall effect is a careful, consent-gated read of the project that keeps later install steps accurate.
FAQ
What does this step do?
It reads a repository to identify languages, frameworks, package managers, monorepo structure, application entrypoints, and any existing LaunchDarkly usage, without modifying anything.
Where does it fit in the flow?
It is Step 1 of the sdk-install onboarding, handing off to the plan step next.
How does it identify the stack?
From indicator files and their manifests, such as package.json, requirements.txt, go.mod, and pom.xml, plus lock files like package-lock.json or pnpm-lock.yaml to infer the package manager.
How does it handle a monorepo?
It recognizes workspace tools like pnpm workspaces, Lerna, Nx, Turborepo, and Rush, then asks with a blocking question which package or service to target and runs the rest of detection inside that subtree.
What are the three workspace-confidence states?
Clear app, unclear or weak evidence, and no app found. Weak evidence is not treated as confirmation, and ambiguous or empty workspaces trigger a blocking question to confirm the target.
Install detect
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
launchdarkly/agent-skills