Integrations

Agent skills

Install the ConfigDirector agent skills, so your coding agent adds an SDK to your project, reads and tests configs the way these docs describe, and checks config keys in CI

Introduction

The agent skills are a pre-release. What a skill does may change before 1.0, and the changelog lists every change.

An agent skill is a set of instructions your coding agent loads to carry out one ConfigDirector task, such as adding an SDK to your project or checking config keys in CI. Once the skills are installed, ask your agent to add feature flags to your app, and it picks the matching skill on its own and does the work the way someone who has read these docs would.

The skills use the shared Agent Skills format, so they work with any coding agent that reads it. Two of them give your agent rules for writing and testing code that reads configs. They need no API token of their own, and run the CLI's checks only when your project already has the CLI set up.

Install

Run this in your project:

npx skills add ConfigDirector/agent-skills

It asks which skills to install, which of your coding agents to install them into, and whether to install them in the current project, where you can commit them for your team, or for every project on your machine. Add -g to install for every project without being asked, or --skill with a skill's name to install only that one:

npx skills add ConfigDirector/agent-skills -g
npx skills add ConfigDirector/agent-skills --skill configdirector-setup

npx skills add works with Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Windsurf and the other agents it supports. The skills live in the ConfigDirector/agent-skills repository on GitHub.

The skills

Skill	What it does	API token permissions
`configdirector-setup`	Adds ConfigDirector to your project: picks the SDK for your framework, installs it, reads the SDK key from an environment variable, creates a first feature flag once you confirm it, and evaluates the flag in your code.	`Projects: Read`, `Configs: Read`, `Configs: Create`, for the first flag
`configdirector-connect`	Sets up your agent's access to your ConfigDirector account, through the MCP server or the CLI, and checks it with one read.	`Projects: Read`, plus the permissions you choose for the agent
`configdirector-use-configs-in-code`	Gives your agent the rules for code that reads a config: what the in-code default value is for, the type to read each config as, which SDKs receive it, the evaluation context, keys the CLI can check, and one client per app. Applies when your agent writes or reviews such code.	None of its own
`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, a test for each branch of a flag, and test values of the config's type. Applies when your agent writes tests around flagged code.	None of its own
`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.	`Projects: Read`, `Configs: Read`, for a token used only by CI

How the skills reach your account

Besides configdirector-connect, two skills work with your ConfigDirector account. configdirector-setup creates your first flag through the MCP server; without the server, it still adds the SDK to your project and asks you to create the flag in the dashboard. configdirector-validate-in-ci checks your code with the CLI, the same command your CI runs.

Both need access set up with an API token you create. Ask your agent to connect ConfigDirector, and configdirector-connect sets it up with you:

It asks what you want the agent to do, and names the permissions for it.
In the ConfigDirector dashboard, you open API tokens and create a token with those permissions and an expiration.
If your agent supports MCP servers, it adds the MCP server with the configuration the MCP page gives for your agent. Otherwise, it has you install the CLI and sign in with configdirector login in your own terminal.
It checks the access with one read and tells you what the token can do.

A skill that finds neither set up sends you to configdirector-connect. You can also set up either one by hand from its page.

The token's permissions decide what your agent can do. The MCP server offers only the tools they allow, so a read-only token makes a read-only agent, and the CLI refuses a command that needs a permission the token lacks. Changes your agent makes through the MCP server show in the audit log with the source MCP and the token owner's name. The CLI commands the skills run only read from your account.

Safety

The skills follow these rules:

Your agent never sees your API token. The MCP configuration reads the token from an environment variable or your editor's secret prompt, and you sign in to the CLI with configdirector login in your own terminal. Never paste a token into the chat, where it would stay in the transcript. If you do, the skill asks you to revoke it and create another.
Every change to your account is confirmed: a skill shows what it will create or change, and waits for your yes.
Before a skill changes the targeting rules of a live environment, archives a config, or removes code, it shows you the exact change.
No skill deletes anything in your account.

Versions

The skills are released together under one version number, and the changelog lists what each release changed. To update the skills you installed, run npx skills update.

MCP

Manage projects, configs, targeting rules, and segments from AI coding tools through the Model Context Protocol

CLI

Find where your code reads each config, fail the build when it reads a key that does not exist, was renamed, or has the wrong type, and see the value a context gets for a config and why, with the configdirector command line tool