> Markdown version of https://www.getunleash.io//blog/cursor-rules-safe-releases-feature-flag-automation > For clean Markdown of any blog post, append .md to its URL. > For a site index, see https://www.getunleash.io//llms.txt. # From Cursor Rules to Safe Releases: Feature Flag Automation with Unleash _Published 2026-05-14 by Alex Casalboni in How to._ The [first post in this series](https://www.getunleash.io/blog/cursor-feature-flags-ai-first-ide) 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: ```shell 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: ```json { "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](https://cursor.directory/plugins/mcp-unleash). 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: ```js 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: ```markdown --- 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: ```markdown --- 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: ```json { "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: ```shell #!/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: ```json { "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: ```shell #!/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](https://featureops.io/) workflow: ```markdown # 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: ```shell 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: ```json { "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](https://cursor.com/docs/cli/overview) 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: ```shell 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](https://docs.getunleash.io/integrate/cursor) and the [Unleash MCP server repository](https://github.com/Unleash/unleash-mcp).