Labsco
launchdarkly logo

projects

โ˜… 19

by launchdarkly ยท part of launchdarkly/agent-skills

Guide 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.

๐Ÿ”Œ This skill ships inside the launchdarkly plugin โ€” install the plugin and you also get an MCP server.

This is the playbook your agent receives when the skill activates โ€” you don't need to read it to use the skill, but it's here to audit before installing.

LaunchDarkly Projects Setup

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.

Core Principles

  1. Understand First: Explore the codebase to understand the stack and patterns.
  2. Choose the Right Fit: Select an approach that matches your architecture.
  3. Follow Conventions: Respect existing code style and structure.
  4. Verify Integration: Confirm the setup works: the agent performs checks and reports results.

API Key Detection

Before prompting the user for an API key, try to detect it automatically:

  1. Check environment variables: Look for LAUNCHDARKLY_API_KEY, LAUNCHDARKLY_API_TOKEN, or LD_API_KEY
  2. Check MCP config: If using Claude, read ~/.claude/config.json for mcpServers.launchdarkly.env.LAUNCHDARKLY_API_KEY
  3. Prompt user: Only if detection fails, ask the user for their API key

See Quick Start for API usage patterns.

What Are Projects?

Projects are LaunchDarkly's top-level organizational containers that hold:

  • All your configs
  • Feature flags and segments
  • Multiple environments (Production and Test created by default)

Think of projects as separate applications, services, or teams that need their own isolated set of configurations.

Project Key Best Practices

Project keys must follow these rules:

โœ“ Good examples:
  - "support-ai"
  - "chat-bot-v2"
  - "internal-tools"

โœ— Bad examples:
  - "Support_AI"     # No uppercase or underscores
  - "123-project"    # Must start with letter  
  - "my.project"     # No dots allowed

Naming Recommendations:

  • Keep keys short but descriptive
  • Use team/service/purpose as naming scheme
  • Be consistent across your organization

Common Organization Patterns

By Team

platform-ai       โ†’ Platform Team Agent
customer-ai       โ†’ Customer Success Team Agent
internal-ai       โ†’ Internal Tools Team Agent

By Application/Service

mobile-ai         โ†’ Mobile App configs
web-ai            โ†’ Web App configs
api-ai            โ†’ API Service configs

By Region/Deployment

ai-us             โ†’ US Region
ai-eu             โ†’ Europe Region
ai-apac           โ†’ Asia-Pacific Region

Edge Cases

SituationAction
Project already existsCheck if it's the right one; use it or create with different key
Need multiple projectsCreate separately for each service/region/team
Shared configs across servicesUse same project, separate by SDK context
Token lacks permissionsRequest projects:write or use MCP server
Project name conflictKeys must be unique, names can be similar

What NOT to Do

  • Don't create projects without understanding the use case first
  • Don't commit API tokens or SDK keys to version control
  • Don't use production SDK keys in test/development environments
  • Don't create duplicate projects unnecessarily
  • Don't skip the exploration phase

Next Steps

After setting up projects:

  1. Create configs - Use the configs-create skill
  2. Set up SDK Integration - Use the sdk skill
  3. Configure Targeting - Use the configs-targeting skill
  • configs-create - Create configs in projects
  • sdk - Integrate SDK in your application
  • configs-targeting - Configure config targeting
  • configs-variations - Manage config variations

References