
projects
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.
- Installs
- 1.8K
- 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 projects- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads projects automatically when relevant.
- 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.
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.
Prerequisites
Choose one:
- LaunchDarkly API access token with
projects:writepermission - LaunchDarkly MCP server configured in your environment
Core Principles
- Understand First: Explore the codebase to understand the stack and patterns.
- Choose the Right Fit: Select an approach that matches your architecture.
- Follow Conventions: Respect existing code style and structure.
- Verify Integration: Confirm the setup works: the agent performs checks and reports results.
API Access
Prefer the LaunchDarkly MCP server tools: they authenticate via OAuth and need no token. If a step has no MCP equivalent and you must call the REST API directly, ask the user to paste an API access token for this session and substitute it for {api_token} in the examples below. Do not search environment variables, .env files, or agent/MCP config files for credentials.
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 Setup Workflow
Step 1: Explore the Codebase
Before implementing anything, understand the existing architecture:
-
Identify the tech stack:
- What language(s)? (Python, Node.js, Go, Java, etc.)
- What framework(s)? (FastAPI, Express, Spring Boot, etc.)
- Is there an existing LaunchDarkly integration?
-
Check environment management:
- How are environment variables stored? (.env files, secrets manager, config files)
- Where is configuration loaded? (startup scripts, config modules)
- Are there existing LaunchDarkly SDK keys?
-
Look for patterns:
- Are there existing API clients or service modules?
- How is external API integration typically done?
- Is there a CLI, scripts directory, or admin tooling?
-
Understand the use case:
- Is this a new project being set up?
- Adding to an existing LaunchDarkly integration?
- Part of a multi-service architecture?
- Need for project cloning across regions/teams?
Step 2: Assess the Situation
Based on your exploration, determine the right approach:
| Scenario | Recommended Path |
|---|---|
| New project, no LaunchDarkly integration | Quick Setup - Create project and save SDK keys |
| Existing LaunchDarkly usage | Add to Existing - Create new project or use existing |
| Multiple services/microservices | Multi-Project - Create projects per service |
| Multi-region or multi-tenant | Project Cloning - Clone template project |
| Infrastructure-as-Code (IaC) setup | Automated Setup - Script-based creation |
| Need project management tooling | CLI/Admin Tools - Build project management utilities |
Step 3: Choose Your Implementation Path
Select the reference guide that matches your stack and use case:
By Language/Stack:
- Python Implementation - For Python applications (FastAPI, Django, Flask)
- Node.js/TypeScript Implementation - For Node.js/Express/NestJS applications
- Go Implementation - For Go services
- Multi-Language Setup - For polyglot architectures
By Use Case:
- Quick Start - Create first project and get SDK keys
- Environment Configuration - Save SDK keys to .env, secrets, or config
- Project Cloning - Clone projects for regions/teams
- IaC/Automation - Terraform, scripts, CI/CD integration
- Admin Tooling - Build CLI or admin utilities
Step 4: Implement the Integration
Follow the chosen reference guide to implement project management. Key considerations:
-
API Authentication:
- Store API token securely
- Follow existing secrets management patterns
- Never commit tokens to version control
-
Project Naming:
- Use consistent, descriptive names
- Follow existing naming conventions
- Project keys: lowercase, hyphens, start with letter
-
SDK Key Management:
- Extract and store SDK keys for each environment
- Use the same pattern as other secrets in your codebase
- Consider separate keys for test/staging/production
-
Error Handling:
- Handle existing projects gracefully (409 conflict)
- Provide clear error messages
- Don't fail silently
Step 5: Verify the Setup
After creating the project, verify it works:
-
Fetch to confirm it exists. Prefer the MCP
get-projecttool over rawcurl— it returns a typed object you can inspect directly. If you must call the REST API:curl -X GET "https://app.launchdarkly.com/api/v2/projects/{projectKey}?expand=environments" \ -H "Authorization: {api_token}"Do not pipe the response straight into a
.environments.items[]-stylejqfilter. The shape ofenvironmentsvaries byexpandparameter — sometimes it's{items: [...]}, sometimes a bare array — and a hand-rolled filter will fail withCannot index array with string "items". Runjq -e .first to inspect the actual shape, or usejq '.environments | if type == "object" then .items else . end'to handle both. -
Test SDK integration: Run a quick verification to ensure the SDK key works:
import ldclient from ldclient.config import Config ldclient.set_config(Config("{sdk_key}")) # SDK initializes successfully # Always flush events before closing — trailing events are at risk of being # lost otherwise, in short-lived scripts and long-running services alike. ldclient.get().flush() ldclient.get().close() -
Report results:
- ✓ Project exists and has environments
- ✓ SDK keys are present and valid
- ✓ SDK can initialize (or flag any issues)
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
| Situation | Action |
|---|---|
| Project already exists | Check if it's the right one; use it or create with different key |
| Need multiple projects | Create separately for each service/region/team |
| Shared configs across services | Use same project, separate by SDK context |
| Token lacks permissions | Request projects:write or use MCP server |
| Project name conflict | Keys 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:
- Create configs - Use the
configs-createskill - Set up SDK Integration - Use the
sdkskill - Configure Targeting - Use the
configs-targetingskill
Related Skills
configs-create- Create configs in projectssdk- Integrate SDK in your applicationconfigs-targeting- Configure config targetingconfigs-variations- Manage config variations
References
- Python Implementation
- Node.js Implementation
- Go Implementation
- Quick Start Guide
- Environment Configuration
- Project Cloning
- IaC/Automation
- Admin Tooling
FAQ
What does the projects skill do?
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.
How do I install projects?
Run npx skills add https://github.com/launchdarkly/ai-tooling --skill projects 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/projects/ (personal) or .claude/skills/projects/ (project).
Which AI agents can use projects?
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 projects 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 projects?
It is published by launchdarkly in launchdarkly/ai-tooling. It has 1,821 recorded installs.
More from launchdarkly/ai-tooling
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'.
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.
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.
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.
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.
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.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
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.