Agent skills for ConfigDirector, a managed service for feature flags and remote configuration. An agent skill is a set of instructions your coding agent loads to carry out one ConfigDirector task, so it works with ConfigDirector the way someone who has read the docs would. Ask your agent to add ConfigDirector or feature flags to your project, and it picks up the matching skill on its own. The Agents docs page in the ConfigDirector docs also explains how the skills reach your account and the safety rules they follow.
| Skill | What it does | API token permissions |
|---|---|---|
configdirector-setup |
Adds ConfigDirector to the current project: picks the SDK for your framework, installs it, reads the SDK key from an environment variable, creates a first feature flag after you confirm it, or reads the flag you name, and evaluates the flag in your code. | Projects: Read, Configs: Read, Configs: Create |
configdirector-connect |
Sets up your agent's access to ConfigDirector, through the MCP server or the CLI, for each organization you work with, and checks it, on the CLI also reporting the token's organization and permissions. Asks what the agent will do and names the permissions for it; you create the token and set it where the agent runs, so the agent never sees it. | Projects: Read, plus the permissions you choose for the agent |
configdirector-flag-a-change |
Wraps a code change in a new temporary feature flag: proposes a key, creates a boolean flag that is off in every environment after you confirm it, reads it in your code so the change runs where the flag is on and the current behavior stays where it is off, and tests both branches. | Projects: Read, Configs: Read, Configs: Create |
configdirector-use-configs-in-code |
Gives your agent the rules for code that reads a config: what the in-code default value is and is not, the type each config is served as, which SDKs receive which configs, the evaluation context, keys the CLI can check, and one client per app. Applies when the agent writes or reviews such code, and fetches the exact calls from the SDK's docs page. When the agent can reach your account, checks that your project has a config before writing a read, and offers to create one it lacks. | none of its own; with the agent's access, Projects: Read and Configs: Read to check a config |
configdirector-test-with-flags |
Gives your agent the rules for testing code that reads a config: the SDK's test client or the OpenFeature in-memory provider instead of a mock, no real SDK key, both branches of a flag, the code's own keys and values of the config's type. Applies when the agent writes tests around flagged code, and fetches the test client from the SDK's docs page. | none |
configdirector-validate-in-ci |
Adds configdirector validate to your repository's CI, so the build fails when the code reads a config key that does not exist, was renamed, or has the wrong type. Links the repository to its project, adds the GitLab job from the CLI docs page or, on GitHub, the ConfigDirector Code Scan action, which can also upload where each config is read on pushes to your default branch, and runs the check once. You create a token used only by CI and save it as the CONFIGDIRECTOR_TOKEN secret, so the agent never sees it. |
Projects: Read, Configs: Read, plus Code references: Update for the upload, for the CI token you create |
configdirector-clean-up-flag |
Removes a settled temporary feature flag from your code, keeping the branch it serves: reads the flag's lifecycle state, its recent evaluations and every reference configdirector scan finds, including constants and tests, proposes the branch to keep, shows the exact change before editing, and runs your project's checks. Stops with the facts when the flag is still in use, is a kill switch or a permanent config, or when a reference cannot be resolved. Archives the config only once you confirm the removal is deployed everywhere that read the flag, and otherwise tells you how to archive later. |
Projects: Read, Environments: Read, Configs: Read, Configs: Archive |
configdirector-migrate-from-launchdarkly |
Moves your flags from LaunchDarkly, following the migration guide. Recreates a LaunchDarkly project's segments and flags in your ConfigDirector project, with the targeting rules of each environment, from flag data you export in your own terminal, so the agent never handles a LaunchDarkly token: proposes which flags to move and which to hardcode, shows each batch of configs next to LaunchDarkly's settings and rules before creating it, and checks the rules with an evaluation. Then switches one application's SDK calls over, runs configdirector validate and your checks, and removes the LaunchDarkly package once no read remains. Skips every key your project already has, and changes nothing in LaunchDarkly. |
Projects: Read, Environments: Read, Configs: Read, Configs: Create, Configs: Update targeting rules, Segments: Read, Segments: Create; for tags, Tags: Read |
configdirector-create-config |
Creates a config of any role and type from your description: a feature flag, kill switch, config or experiment, with its type's constraints, the SDKs that receive it, tags and variations. Marks the tags your project does not have yet as new, shows every setting and the default targeting rule value every environment starts with, asks for the ones it cannot work out from your description, and creates it, with any new tags, after you confirm. | Projects: Read, Configs: Read, Configs: Create; for tags, Tags: Read to find existing ones and Tags: Create to make new ones |
configdirector-roll-out |
Changes a config's targeting rules in one environment from your description: turns a flag on or off, rolls a change out to a percentage, targets specific users, contexts with certain attributes, or a segment, sets an experiment split, or changes the value it serves. Reads the environment's current rules first, shows them next to the resulting rules, and writes them after you confirm; in a live environment it says so and asks for an explicit yes. On request, shows what a context you describe now gets. | Projects: Read, Environments: Read, Configs: Read, Configs: Update targeting rules; for segments, Segments: Read; to evaluate a saved context, Contexts: Read |
configdirector-segments |
Creates a segment or changes one from your description: who is in it, as condition groups, its name or key, and an environment's own definition added, changed or removed. Reads the segment, the configs that use it and the targeting rules reference first, shows the current and resulting definition side by side with the configs that use the segment in the environments the change reaches, and writes it after you confirm; when one of those environments is live and a config uses the segment there, it says so and asks for an explicit yes. Never deletes a segment: it shows what uses it and gives you the command or the dashboard page to delete it yourself. | Projects: Read, Environments: Read, Segments: Read, plus Segments: Create to create a segment and Segments: Update to change one |
In your project:
npx skills add ConfigDirector/agent-skillsAdd --skill configdirector-setup to install only that skill, and -g to install for every project instead of the current one.
npx skills add installs into Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Windsurf, OpenCode and the other agents it supports.
The skills reach your ConfigDirector account through the ConfigDirector MCP server or the ConfigDirector CLI. Ask your agent to connect ConfigDirector, and the configdirector-connect skill walks you through it: it names the permissions for what you want the agent to do, you create an API token with them in the ConfigDirector dashboard under API tokens, and the agent writes the MCP configuration with the token referenced from an environment variable, or walks you through the CLI sign-in, then checks the access. The agent never sees the token, so never paste it into the chat.
A token belongs to one organization. If you work with several, the CLI keeps one sign-in for each, and the MCP configuration of each repository reads a variable named for its organization, such as CONFIGDIRECTOR_TOKEN_ACME. When the CLI is signed in to several organizations and a repository's configdirector.json names none, a skill asks which one you mean and adds it to the file. When the token belongs to another organization than the one the repository names, a skill tells you so and sends you to configdirector-connect instead of using it.
To set it up by hand instead, follow the MCP docs page or the CLI docs page.
This repository was ConfigDirector/claude-plugins, the ConfigDirector plugin for Claude Code. The plugin is no longer published, and these skills replace its setup skill. The plugin also connected Claude Code to the ConfigDirector MCP server, which the skills do not do: once you remove the plugin, ask your agent to connect ConfigDirector, or set the server up from the MCP docs page.
MIT, see LICENSE.