Meet Unleash in person at a Conference near you➩ Book a meeting
Unleash
13.5k

From Cursor Rules to Safe Releases: Feature Flag Automation with Unleash

Alex Casalboni

Alex Casalboni

Developer Advocate

May 14, 2026

The first post in this series covered why an AI-first IDE needs governance for feature flags. Cursor’s multi-model architecture makes consistent flag practices harder to enforce manually. The Unleash MCP server provides the tools. Cursor’s Rules, Hooks, and Skills provide the automation.

This post is the hands-on follow-up. We will build the integration from scratch and work through five layers: connecting the MCP server, encoding policies in Rules, adding pre-flight validation with Hooks, orchestrating workflows with Skills, and bundling everything into a Plugin.

Each layer builds on the one before it. By the end, you will have a setup you can distribute to your entire team.

What you need before starting

The Unleash MCP server runs as a local process that communicates with Cursor via the Model Context Protocol. You will need:

  • Node.js 18+ for running the MCP server via npx
  • Cursor (IDE or CLI)
  • An Unleash instance with API access (cloud or self-hosted)
  • A personal access token (PAT) with permissions to create and manage feature flags

Layer 1: Connect the MCP server

Start by creating the credentials file:


mkdir -p ~/.unleash
cat > ~/.unleash/mcp.env << 'EOF'
UNLEASH_BASE_URL=https://your-instance.getunleash.io/api
UNLEASH_PAT=your-personal-access-token
UNLEASH_DEFAULT_PROJECT=default
EOF
chmod 600 ~/.unleash/mcp.env

Then create .cursor/mcp.json at your project root:


{
  "mcpServers": {
    "unleash": {
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "envFile": "~/.unleash/mcp.env"
    }
  }
}

Cursor supports envFile for stdio servers, which keeps credentials out of version control while keeping the config file simple. You can commit .cursor/mcp.json safely.

If you prefer a one-click setup, the Unleash MCP server is also listed on cursor.directory. Click Add to Cursor, enter your credentials, and the config is created for you. For team projects, replace the inline credentials with the envFile approach above.

Open Cursor Settings and navigate to Tools & MCPs. The Unleash server should appear in the list. If it does not, check the Output panel (Cmd+Shift+U) and select MCP Logs from the dropdown.

At this point you have a working integration. You can ask the agent to evaluate changes, create flags, and generate wrapping code. But every interaction depends on the developer remembering to ask. The next layers fix that.

Your first workflow: evaluate, create, wrap

Before adding automation, try the manual workflow. Open an Agent session and tell Cursor:

Evaluate whether the Stripe payment integration should be behind a feature flag. The change modifies the checkout service.

The agent calls evaluate_change with your description. For a payment integration, it recommends a flag. It then calls detect_flag to check for duplicates. If none are found, it proceeds to create_flag with a name like checkout-stripe-integration, and finally calls wrap_change to generate framework-specific guard code:


if (unleash.isEnabled("checkout-stripe-integration", context)) {
    return stripeService.processPayment(request);
} else {
    return legacyPaymentService.process(request);
}

The flag is created in Unleash, disabled by default. You can test in staging, roll out gradually, and disable instantly if something goes wrong.

This works, but it relies on the developer knowing to ask. Layer 2 makes the conventions automatic.

Layer 2: Encode policies with Rules

Cursor Rules live in .cursor/rules/ as .mdc files with optional YAML frontmatter. Four application modes are available: alwaysApply (every session), glob-scoped (when specific files are touched), intelligent (the agent decides based on the rule’s description), and manual (via @rule-name).

Start with a universal conventions file that loads into every session:


---
description: "Feature flag conventions for all code changes"
alwaysApply: true
---

# Feature Flag Conventions

When making changes to this codebase, follow these feature flag practices:

1. **Always evaluate risk** before implementing changes to payments,
   authentication, data migrations, or external integrations.
   Use the evaluate_change tool.

2. **Naming** — Use the format `{domain}-{feature}-{variant}`.
   Examples: `checkout-stripe-integration`, `auth-sso-google`.

3. **Flag types**:
   - `release` for gradual feature rollouts
   - `experiment` for A/B tests
   - `kill-switch` for emergency shutdowns

4. **Prefer reuse** — Check for existing flags with detect_flag before creating.

5. **Clean up after rollout** — Flags at 100% for 2+ weeks should be cleaned up.

Save as .cursor/rules/feature-flags.mdc.

For high-risk domains, add a glob-scoped rule that fires only when the agent touches relevant files:


---
description: "Payment domain requires feature flags for all changes"
globs: ["src/payments/**/*.ts", "src/payments/**/*.tsx"]
---

# Payments Domain — Feature Flag Policy

All changes in the payments domain require feature flags. No exceptions.

- Use `kill-switch` type for external payment provider integrations
- Naming: `payments-{feature}-{variant}`
- Always include a fallback path for external provider calls
- Evaluate risk with evaluate_change before writing implementation code

Save as .cursor/rules/payments-flags.mdc.

Now when a developer works in the payments directory, the agent automatically applies the domain-specific rules on top of the universal conventions. The agent calls evaluate_change before writing code, uses the correct naming convention, and picks the right flag type. No special prompting needed.

On Teams and Enterprise plans, administrators can create Team Rules with enforcement toggles that prevent developers from disabling mandatory policies. The rules travel with the codebase, so new team members get the same conventions from their first session.

Layer 3: Validate with Hooks

Rules guide the agent’s behavior. Hooks go further: they intercept operations and can block them before they execute. Cursor hooks are scripts stored in .cursor/hooks.json that fire at specific points in the agent loop. The beforeMCPExecution event is especially useful for feature flags: it fires before any MCP tool call and can validate, allow, or deny the request.

Here is a hook that validates flag names against your naming convention before create_flag reaches the Unleash server:


{
  "version": 1,
  "hooks": {
    "beforeMCPExecution": [
      {
        "command": ".cursor/hooks/validate-flag-name.sh",
        "matcher": "MCP:unleash",
        "timeout": 10,
        "failClosed": true
      }
    ]
  }
}

Save as .cursor/hooks.json.

The hook script checks the flag name:


#!/bin/bash
input=$(cat)
tool_name=$(echo "$input" | jq -r '.tool_name // empty')

if [[ "$tool_name" == "create_flag" ]]; then
  flag_name=$(echo "$input" | jq -r '.tool_input' | jq -r '.name // empty')
  if [[ ! "$flag_name" =~ ^[a-z]+-[a-z]+-[a-z]+$ ]]; then
    cat << EOF
{
  "permission": "deny",
  "agent_message": "Flag name '$flag_name' violates naming convention. Use {domain}-{feature}-{variant} with lowercase and hyphens."
}
EOF
    exit 0
  fi
fi

echo '{"permission": "allow"}'

Save as .cursor/hooks/validate-flag-name.sh and make it executable with chmod +x.

When the agent tries to create a flag with a name like enableStripe or new_payment_flow, the hook catches it before the MCP server ever sees the request. It returns deny with a message explaining the violation. The agent adjusts the name and retries. The MCP server only receives validated requests.

This is a capability most AI coding assistants do not have.

You can add a second hook for audit logging. The afterMCPExecution event fires after every tool call:


{
  "version": 1,
  "hooks": {
    "beforeMCPExecution": [
      {
        "command": ".cursor/hooks/validate-flag-name.sh",
        "matcher": "MCP:unleash",
        "timeout": 10,
        "failClosed": true
      }
    ],
    "afterMCPExecution": [
      {
        "command": ".cursor/hooks/audit-mcp.sh",
        "matcher": "MCP:unleash"
      }
    ]
  }
}

The audit script logs every MCP operation with a timestamp:


#!/bin/bash
input=$(cat)
timestamp=$(date '+%Y-%m-%d %H:%M:%S')
mkdir -p .cursor/hooks/logs
echo "[$timestamp] $(echo "$input" | jq -c '{tool: .tool_name, duration: .duration}')" >> .cursor/hooks/logs/mcp-audit.log
exit 0

Enterprise teams can distribute hooks via the web dashboard. They sync to all team members automatically every 30 minutes.

Layer 4: Orchestrate with Skills

Rules tell the agent when to evaluate. Hooks validate what the agent sends. Skills define how multi-step workflows run. Cursor supports skills as SKILL.md files within the plugin system. They are invoked with /skill-name in chat or discovered automatically by the agent when the context matches.

Create a skill that orchestrates the complete FeatureOps workflow:


# Evaluate and Flag

Evaluate whether current changes need a feature flag, then create and wrap it.

## Steps

1. Use `evaluate_change` to assess the risk of the current changes
2. If a flag is needed, use `detect_flag` to check for existing similar flags
3. If no suitable flag exists, use `create_flag` with the recommended name and type
4. Use `wrap_change` to generate framework-specific guard code
5. Suggest a rollout strategy based on the change's risk level

Save as skills/evaluate-and-flag/SKILL.md inside your plugin directory (see Layer 5).

Now a developer can type /evaluate-and-flag in chat, and the agent runs the full workflow: evaluate, detect, create, wrap, suggest rollout. Each step calls the appropriate MCP tool. The hook validates the flag name along the way. The rules provide the naming conventions. All five layers working together.

Layer 5: Bundle into a Plugin

You now have an MCP server configuration, three Rules files, a hooks definition, and a Skill. Separately they work. Together they require per-project setup. A Cursor Plugin bundles everything into a single installable package.

Create a directory with this structure:


unleash-featureops/
├── .cursor-plugin/
│   └── plugin.json
├── rules/
│   ├── feature-flag-conventions.mdc
│   ├── payments-flags.mdc
│   └── rollout-guidance.mdc
├── skills/
│   └── evaluate-and-flag/
│       └── SKILL.md
├── hooks.json
└── mcp.json

The plugin.json manifest:


{
  "name": "unleash-featureops",
  "description": "Automate feature flag management with Unleash.",
  "version": "1.0.0",
  "author": { "name": "Your Team" }
}

The Rules, Skills, hooks, and MCP config are the same files from the previous layers. Components are discovered automatically from their default directories.

For team distribution, push the plugin to a GitHub repository and share it through the Team Marketplace on Teams or Enterprise plans. Administrators can import the repository via Dashboard > Settings > Plugins and set it as required so every developer gets the same setup automatically. For local testing, symlink to ~/.cursor/plugins/local/unleash-featureops.

The plugin structure is team-specific by design. Your Rules, hooks, and naming conventions reflect how your organization builds software. Two teams at different companies will have different Rules, different hook validation logic, and different naming patterns. The MCP server is shared, but the governance layer on top of it is yours.

The same setup in the CLI

The Cursor CLI shares the same MCP configuration and Rules as the IDE. Install it with curl https://cursor.com/install -fsS | bash, then run agent to start an interactive session where you can use the same Unleash MCP tools.

For non-interactive use in scripts or CI/CD:


agent -p "Check if any changes in this branch should be feature flagged" --output-format text

Use –approve-mcps to skip MCP server confirmation prompts.

What you built

Five layers, each building on the last:

  1. MCP server gives the agent the tools to create and manage feature flags
  2. Rules encode your team’s conventions so the agent follows them automatically
  3. Hooks validate MCP operations before they execute and log every action
  4. Skills orchestrate multi-step workflows into repeatable sequences
  5. A Plugin packages everything into a single install for the whole team

Start with Layer 1 and a few manual workflows. Add Rules when you see naming drift. Introduce hooks when you want pre-flight validation on your highest-risk operations. Wrap it in a Plugin when you are ready to share. Each layer is valuable on its own. Together, they make feature flag governance automatic.

For the full configuration reference, including additional Rule templates and troubleshooting guides, see our Cursor integration documentation and the Unleash MCP server repository.

Explore further