About configs-update
A lifecycle skill for updating, archiving, and deleting LaunchDarkly AI configs and their variations. It is for teams maintaining configs, with pre-change checks, post-change verification, and archival preferred over permanent deletion.
Key features
- 01Assess config health and inspect details
- 02Update config metadata and variations
- 03Archive configs reversibly
- 04Fetch again to verify changes
- 05Require explicit confirmation for permanent deletion
Use cases
- 01Fix variations missing models or prompts
- 02Adjust models, instructions, or parameters
- 03Retire configs temporarily
- 04Permanently remove a config or variation after confirmation
MCP support
The skill requires a remotely hosted LaunchDarkly MCP server and uses its tools to inspect, update, archive, delete, and verify configs.
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ launchdarkly/ ai-tooling --skill configs-updateAfter installing, type/configs-updatein Claude Code to confirm it loaded.
Bundled filesREADME.md
Details
From the project READMEConfig Update & Lifecycle
You're using a skill that will guide you through updating, archiving, and deleting configs and their variations. Your job is to understand the current state of the config, make the changes, and verify the result.
Prerequisites
This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
Required MCP tools:
get-ai-config-health-- assess config health before making changes (detects missing models, orphaned tools, empty configs)get-ai-config-- understand current state before making changesupdate-ai-config-- update config metadata (name, description, tags, archive)update-ai-config-variation-- update variation model, prompts, or parameters
Optional MCP tools:
delete-ai-config-- permanently delete a config (irreversible)delete-ai-config-variation-- permanently delete a variation (irreversible)
Core Principles
- Fetch Before Changing: Always check the current state before modifying
- Verify After Changing: Fetch the config again to confirm updates were applied
- Archive Before Deleting: Archival is reversible; deletion is not
Workflow
Step 1: Assess Health and Understand Current State
Start with get-ai-config-health to get a structured health assessment. This detects:
- Variations with no model (show as "NO MODEL" in the UI)
- Variations with neither instructions nor messages
- Orphaned tool references (tools attached that don't exist in the project)
- Configs with no variations at all
The health verdict (healthy, warning, unhealthy) helps you prioritize what to fix.
Then use get-ai-config to review the full detail:
- Current mode (agent or completion)
- Existing variations and their models
- Current instructions or messages
- Attached tools and parameters
Step 2: Make the Update
Update config metadata -- Use update-ai-config:
- Change name or description
- Add or replace tags
- Archive with
archived: true(reversible)
Update a variation -- Use update-ai-config-variation:
- Switch model (provide new
modelConfigKeyandmodelName) - Change instructions or messages
- Tune parameters (temperature, max_tokens, etc.)
- Attach or detach tools via the parameters object
Archive a config -- Use update-ai-config with archived: true. Archiving is the preferred way to retire a config:
- It is reversible (unarchive with
archived: false) - The config is hidden from active lists but preserved
- After calling the archive, treat a successful response as confirmation and proceed to verification
- When a user says "remove", "retire", "decommission", or "no longer need", default to archiving unless they explicitly say "delete permanently"
Delete -- Use delete-ai-config or delete-ai-config-variation (irreversible, requires confirm: true). Always suggest archiving first. Only proceed with deletion if the user explicitly confirms they want permanent, irreversible removal.
Step 3: Verify
Use get-ai-config to confirm the response shows your updated values.
Report results:
- Update applied successfully
- Config reflects changes
- Flag any issues or rollback if needed
What NOT to Do
- Don't update production configs without testing in another variation first
- Don't change multiple things at once -- make incremental changes
- Don't skip verification
- Don't delete without explicit user confirmation -- always suggest archiving first
- Don't retry an update because the API response doesn't echo back the exact values you sent -- verify with
get-ai-configinstead
More resources
To learn more about creating and managing variations, read Create and manage config variations.
Related Skills
configs-variations-- Create variations to test changes side-by-sidetools-- Update tool attachments