aiconfig-projects
npx skills add https://github.com/launchdarkly/agent-skills --skill aiconfig-projects
Agent 安装分布
Skill 文档
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 Key Detection
Before prompting the user for an API key, try to detect it automatically:
- Check environment variables â Look for
LAUNCHDARKLY_API_KEY,LAUNCHDARKLY_API_TOKEN, orLD_API_KEY - Check MCP config â If using Claude, read
~/.claude/config.jsonformcpServers.launchdarkly.env.LAUNCHDARKLY_API_KEY - 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 AI 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 via API to confirm it exists:
curl -X GET "https://app.launchdarkly.com/api/v2/projects/{projectKey}?expand=environments" \ -H "Authorization: {api_token}"Confirm the response includes the project, environments, and SDK keys.
-
Test SDK integration: Run a quick verification to ensure the SDK key works:
from ldclient import set_config, Config set_config(Config("{sdk_key}")) # SDK initializes successfully -
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 AI
customer-ai â Customer Success Team AI
internal-ai â Internal Tools Team AI
By Application/Service
mobile-ai â Mobile App AI Configs
web-ai â Web App AI Configs
api-ai â API Service AI 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 AI Configs – Use the
aiconfig-createskill - Set up SDK Integration – Use the
aiconfig-sdkskill - Configure Targeting – Use the
aiconfig-targetingskill
Related Skills
aiconfig-create– Create AI Configs in projectsaiconfig-sdk– Integrate SDK in your applicationaiconfig-targeting– Configure AI Config targetingaiconfig-variations– Manage config variations