$npx -y skills add launchdarkly/ai-tooling --skill projectsGuide for setting up LaunchDarkly projects in your codebase. Helps you assess your stack, choose the right approach, and integrate project management that makes sense for your architecture.
| 1 | # LaunchDarkly Projects Setup |
| 2 | |
| 3 | You're using a skill that will guide you through setting up LaunchDarkly project management in a codebase. Your job is to explore the codebase to understand the stack and patterns, assess what approach makes sense, choose the right implementation path from the references, execute the setup, and verify it works. |
| 4 | |
| 5 | ## Prerequisites |
| 6 | |
| 7 | **Choose one:** |
| 8 | - LaunchDarkly API access token with `projects:write` permission |
| 9 | - LaunchDarkly MCP server configured in your environment |
| 10 | |
| 11 | ## Core Principles |
| 12 | |
| 13 | 1. **Understand First**: Explore the codebase to understand the stack and patterns. |
| 14 | 2. **Choose the Right Fit**: Select an approach that matches your architecture. |
| 15 | 3. **Follow Conventions**: Respect existing code style and structure. |
| 16 | 4. **Verify Integration**: Confirm the setup works: the agent performs checks and reports results. |
| 17 | |
| 18 | ## API Key Detection |
| 19 | |
| 20 | Before prompting the user for an API key, try to detect it automatically: |
| 21 | |
| 22 | 1. **Check environment variables**: Look for `LAUNCHDARKLY_API_KEY`, `LAUNCHDARKLY_API_TOKEN`, or `LD_API_KEY` |
| 23 | 2. **Check MCP config**: If using Claude, read `~/.claude/config.json` for `mcpServers.launchdarkly.env.LAUNCHDARKLY_API_KEY` |
| 24 | 3. **Prompt user**: Only if detection fails, ask the user for their API key |
| 25 | |
| 26 | See [Quick Start](references/quick-start.md) for API usage patterns. |
| 27 | |
| 28 | ## What Are Projects? |
| 29 | |
| 30 | Projects are LaunchDarkly's top-level organizational containers that hold: |
| 31 | - All your configs |
| 32 | - Feature flags and segments |
| 33 | - Multiple environments (Production and Test created by default) |
| 34 | |
| 35 | Think of projects as separate applications, services, or teams that need their own isolated set of configurations. |
| 36 | |
| 37 | ## Project Setup Workflow |
| 38 | |
| 39 | ### Step 1: Explore the Codebase |
| 40 | |
| 41 | Before implementing anything, understand the existing architecture: |
| 42 | |
| 43 | 1. **Identify the tech stack:** |
| 44 | - What language(s)? (Python, Node.js, Go, Java, etc.) |
| 45 | - What framework(s)? (FastAPI, Express, Spring Boot, etc.) |
| 46 | - Is there an existing LaunchDarkly integration? |
| 47 | |
| 48 | 2. **Check environment management:** |
| 49 | - How are environment variables stored? (.env files, secrets manager, config files) |
| 50 | - Where is configuration loaded? (startup scripts, config modules) |
| 51 | - Are there existing LaunchDarkly SDK keys? |
| 52 | |
| 53 | 3. **Look for patterns:** |
| 54 | - Are there existing API clients or service modules? |
| 55 | - How is external API integration typically done? |
| 56 | - Is there a CLI, scripts directory, or admin tooling? |
| 57 | |
| 58 | 4. **Understand the use case:** |
| 59 | - Is this a new project being set up? |
| 60 | - Adding to an existing LaunchDarkly integration? |
| 61 | - Part of a multi-service architecture? |
| 62 | - Need for project cloning across regions/teams? |
| 63 | |
| 64 | ### Step 2: Assess the Situation |
| 65 | |
| 66 | Based on your exploration, determine the right approach: |
| 67 | |
| 68 | | Scenario | Recommended Path | |
| 69 | |----------|------------------| |
| 70 | | New project, no LaunchDarkly integration | **Quick Setup** - Create project and save SDK keys | |
| 71 | | Existing LaunchDarkly usage | **Add to Existing** - Create new project or use existing | |
| 72 | | Multiple services/microservices | **Multi-Project** - Create projects per service | |
| 73 | | Multi-region or multi-tenant | **Project Cloning** - Clone template project | |
| 74 | | Infrastructure-as-Code (IaC) setup | **Automated Setup** - Script-based creation | |
| 75 | | Need project management tooling | **CLI/Admin Tools** - Build project management utilities | |
| 76 | |
| 77 | ### Step 3: Choose Your Implementation Path |
| 78 | |
| 79 | Select the reference guide that matches your stack and use case: |
| 80 | |
| 81 | **By Language/Stack:** |
| 82 | - [Python Implementation](references/python-setup.md) - For Python applications (FastAPI, Django, Flask) |
| 83 | - [Node.js/TypeScript Implementation](references/nodejs-setup.md) - For Node.js/Express/NestJS applications |
| 84 | - [Go Implementation](references/go-setup.md) - For Go services |
| 85 | - [Multi-Language Setup](references/multi-language-setup.md) - For polyglot architectures |
| 86 | |
| 87 | **By Use Case:** |
| 88 | - [Quick Start](references/quick-start.md) - Create first project and get SDK keys |
| 89 | - [Environment Configuration](references/env-config.md) - Save SDK keys to .env, secrets, or config |
| 90 | - [Project Cloning](references/project-cloning.md) - Clone projects for regions/teams |
| 91 | - [IaC/Automation](references/iac-automation.md) - Terraform, scripts, CI/CD integration |
| 92 | - [Admin Tooling](references/admin-tooling.md) - Build CLI or admin utilities |
| 93 | |
| 94 | ### Step 4: Implement the Integration |
| 95 | |
| 96 | Follow the chosen reference guide to implement project management. Key considerations: |
| 97 | |
| 98 | 1. **API Authentication:** |
| 99 | - Store API token securely |
| 100 | - Follow existing secrets management patterns |
| 101 | - Never commit tokens to version control |
| 102 | |
| 103 | 2. **Project Naming:** |