Featureops

Unleash · FeatureOps Template

This skill brings FeatureOps — the discipline of controlling software behavior at runtime — into your coding agent. It drives the Unleash MCP server to evaluate changes for risk, create flags with consistent naming, generate SDK guard code, manage rollouts, and clean up stale flags.

The defaults work out of the box, but feature-management conventions vary across teams and industries. This skill ships as a customizable template: every tunable value lives in one policy file, which you override per project without editing the skill — see Active policy and Customize for your team.

Setup check

This skill needs the Unleash MCP server connected. When installed as a Claude Code plugin, the server is registered automatically from the bundled .mcp.json; you only need to set three environment variables in the shell that launches your agent. With a standalone install on any other agent, connect the Unleash MCP server yourself first (see examples/README.md in the repository, https://github.com/Unleash/unleash-claude-skills, including the remote MCP server option):

export UNLEASH_BASE_URL=https://your-instance.getunleash.io/api
export UNLEASH_PAT=your-personal-access-token
export UNLEASH_DEFAULT_PROJECT=default   # optional; defaults to "default"

If the Unleash tools are not available, tell the user to complete setup (see the README at https://github.com/Unleash/unleash-claude-skills for full install, transport, and credential instructions) and stop rather than guessing flag state.

Tool naming note (Claude Code): on Claude Code the read-only tools are pre-approved via allowed-tools under two names each: mcp__unleash__* (standalone-skill install, where you register the server under the key unleash) and mcp__plugin_unleash_mcp__* (plugin install, where Claude Code namespaces the bundled server — keyed mcp in .mcp.json — as mcp__plugin_<plugin>_<server>__<tool> → mcp__plugin_unleash_mcp__<tool>, verified on a real install). Pre-approval only applies while this skill is active; a read-only tool invoked before the skill has loaded will still prompt once. Write operations (create_flag, set_flag_rollout, toggle_flag_environment, remove_flag_strategy) are never pre-approved — always let the user confirm them. wrap_change and cleanup_flag don't mutate server state (they return guard code and removal instructions), but they are deliberately not pre-approved either: each immediately precedes edits to production code paths, so the confirmation prompt stays. On other agents, allowed-tools doesn't apply — they use their own permission model — but the read-only vs. write distinction above still holds: never let a write tool run without user confirmation.

Active policy

Every tunable value — naming convention, flag types and lifetimes, rollout milestones and holds, halt thresholds, staleness windows, and the high-risk domains — comes from the active policy. The reference files describe how to apply these values and never restate the numbers, so always resolve them from here.

Precedence, highest first: project override → user override → shipped defaults. For each value, use the highest layer that sets it; anything unset falls through to the defaults. The project override and the defaults are inlined below at load time. If a user override exists (~/.unleash/featureops.md), read it with your file tools and slot it between them.

Project override — ${CLAUDE_PROJECT_DIR}/.unleash/featureops.md (repo-specific; wins): !cat "${CLAUDE_PROJECT_DIR}/.unleash/featureops.md" 2>/dev/null || echo "(no project override — using user override and/or the defaults below)"

Shipped defaults — references/policy-defaults.md: !cat "${CLAUDE_SKILL_DIR}/references/policy-defaults.md" 2>/dev/null || echo "(defaults file not found; load references/policy-defaults.md manually)"

If the two blocks above are empty or show a literal !`…` command, your agent doesn't run inline injection (this is a Claude Code feature). Read the files yourself with your file tools and apply the same precedence: the project override .unleash/featureops.md, the user override ~/.unleash/featureops.md, and this skill's references/policy-defaults.md.

When to load the reference files

Load the reference file that matches the task. For tasks that span workflows (e.g. "create a flag and plan its rollout"), load both.

Core workflow

For a change that might need a flag, follow this sequence. The reference files hold the detailed rules for each step.

1. Evaluate risk — call evaluate_change with a description of the change before implementing anything in the active policy's flag-required categories (see Active policy). See references/feature-flag-conventions.md and references/high-risk-domains.md.
2. Prefer reuse — call detect_flag before creating anything. Reuse a matching flag rather than adding to flag sprawl.
3. Create — if no match exists, call create_flag with a name following the active policy's naming convention and the right flag type. See references/feature-flag-conventions.md.
4. Wrap — call wrap_change for SDK-appropriate guard code. Apply it verbatim; keep the fallback branch realistic.
5. Roll out — use set_flag_rollout and toggle_flag_environment to progress through milestones. See references/rollout-guidance.md.
6. Clean up — flags are temporary by design. When a rollout stabilizes or an experiment concludes, remove the flag. See references/cleanup-cadence.md.

Do not auto-execute write operations. Present the plan, get confirmation, then act — especially for flag creation, rollout changes, and cleanup, which touch production code paths.

Migrations are a different workflow

When the task is migrating existing flags from another system (e.g. GitLab feature flags) into Unleash, defer to the migrate-gitlab-flags skill (/unleash:migrate-gitlab-flags) and do not apply this skill's conventions to the migrated flags — migration parity rules win: flag names carry over unchanged (never renamed to {domain}-{feature}-{variant}), state carries over exactly (no evaluate_change gate, no default rollout milestones), and strategy parameters such as groupId are preserved verbatim. This skill's conventions govern new flags, and they resume governing migrated flags once the migration completes.

Tool reference

The Unleash MCP server exposes the following tools.

The read-only tools — evaluate_change, detect_flag, get_flag_state, list_projects, list_flags — are pre-approved via allowed-tools. Every other tool prompts for approval — the write operations because they mutate server state, and wrap_change/cleanup_flag because their output immediately precedes code edits. Keep it that way unless the user has a specific reason to lower the bar. Use list_projects and list_flags for inventory discovery before creating new flags; list_flags (active + archived) is also the basis of the flag audit workflow in references/cleanup-cadence.md.

Customize for your team

Don't edit this skill's files to customize it — in a plugin install they live in a managed cache that a plugin update overwrites. Instead, put your team's policy in an override file; the skill reads it automatically (see Active policy). references/policy-defaults.md lists every tunable value and doubles as the template.

• Project (recommended): create ./.unleash/featureops.md in the repo and set only the values you want to change — especially your real high-risk domains. It's committed with the repo and wins over everything.
• User (optional): ~/.unleash/featureops.md for personal cross-repo defaults.

Copy the sections you want to change out of references/policy-defaults.md, or just ask the agent: "set up a FeatureOps policy override for this project." For company-wide standardization, the heavier alternative is to fork this repo, bake your policy into policy-defaults.md, and publish it as your own internal plugin — see the skill README.

Metadata

• License: Apache-2.0
• Privacy Policy: https://www.getunleash.io/privacy-policy
• Support: support@getunleash.io · GitHub Issues at https://github.com/Unleash/unleash-claude-skills/issues
• Source: https://github.com/Unleash/unleash-claude-skills

MCP server attribution

This skill configures the Unleash MCP server:

• Package: @unleash/mcp on npm
• Source: https://github.com/Unleash/unleash-mcp
• License: Apache-2.0
• Maintainer: Unleash (Bricks Software AS)
• Transport: local stdio via npx, or remote Streamable HTTP at https://<your-instance>/api/admin/mcp