Unleash
13.3k

Building an Unleash Power for Kiro: Feature Flags from Setup to Distribution

Alex Casalboni

Alex Casalboni

Developer Advocate

March 26, 2026

The first post in this series covered why spec-driven development and feature flags are a natural fit. Specs identify risk at the requirements stage. The Unleash MCP server acts on that signal by creating flags, enforcing naming conventions, and generating wrapping code.

This post is the hands-on follow-up. We will build the integration from scratch and work through four layers: connecting the MCP server, encoding policies in steering files, automating evaluation with hooks, and packaging everything into a shareable Kiro Power. Each layer adds capability on top of the previous one. By the end, you will have a setup that your entire team can install with one click.

What you need before starting

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

  • Node.js 18+ for running the MCP server via npx
  • Kiro IDE (macOS, Windows, or Linux) or the Kiro 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 MCP configuration file. Open the Command Palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows/Linux) and run Kiro: Open workspace MCP config (JSON). This opens .kiro/settings/mcp.json.

Add the Unleash server:


{
  "mcpServers": {
    "unleash": {
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "env": {
        "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
        "UNLEASH_PAT": "${UNLEASH_PAT}",
        "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT}"
      },
      "autoApprove": ["get_flag_state", "detect_flag", "evaluate_change"]
    }
  }
}

The autoApprove array lets Kiro invoke read-only tools without asking for confirmation each time. Write operations like create_flag and wrap_change still require approval. This is a Kiro-specific feature that most AI coding assistants do not support.

Before this works, two one-time setup steps are required:

  1. Enable MCP support. Open Settings (`Cmd+,` on macOS, `Ctrl+,` on Windows/Linux), search for “MCP,” and enable the Kiro: MCP setting. Without this, MCP servers will not connect.
  2. Approve environment variables. When you save the config file, Kiro shows a popup listing unapproved variables. Click Allow to approve UNLEASH_BASE_URL, UNLEASH_PAT, and UNLEASH_DEFAULT_PROJECT. Kiro only expands variables that are explicitly approved. This is a security feature that prevents MCP servers from accessing arbitrary environment variables.

Credentials come from environment variables. Create a credentials file and source it from your shell profile:


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

Add to your ~/.zshrc or ~/.bashrc:


if [ -f ~/.unleash/mcp.env ]; then
  source ~/.unleash/mcp.env
  export UNLEASH_BASE_URL UNLEASH_PAT UNLEASH_DEFAULT_PROJECT
fi

Restart Kiro. Navigate to the MCP Servers tab in the Kiro panel. You should see the Unleash server listed with nine available tools. If something goes wrong, right-click the server and select Show MCP Logs, or open the Output panel and choose Kiro – MCP Logs from the dropdown.

At this point you already have a working integration. You can ask Kiro 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 a chat session and tell Kiro:

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

Kiro calls evaluate_change with your description. For a payment integration, it will recommend 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 automatically 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 using the right prompt. Layer 2 makes the conventions automatic.

Layer 2: Encode policies with steering files

Kiro reads steering files from .kiro/steering/ and applies them based on inclusion modes. Four modes are available: always (every conversation), fileMatch (when specific files are touched), auto (Kiro decides based on context), and manual (only when explicitly requested).

For feature flag conventions, start with an always-included file:


---
inclusion: always
---

# 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`, `api-rate-limiting`.

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

4. **Prefer reuse** — Always 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 .kiro/steering/feature-flags.md.

For domain-specific rules, use fileMatch so the policies apply only when relevant files are touched:


---
inclusion: fileMatch
fileMatchPattern: ["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

Save as .kiro/steering/payments-flags.md.

Now when a developer works in the payments directory, Kiro automatically applies the domain-specific rules on top of the universal conventions. No prompting required. The policies travel with the codebase, so new team members get the same guidance from their first commit.

Layer 3: Automate with hooks

Steering files guide the agent when it is already active. Hooks go further: they trigger the agent automatically based on IDE events. Kiro supports eight trigger types. Two of them are especially useful for feature flags.

File Save hook: Evaluates changes automatically when a developer saves a file in a high-risk directory.


{
  "enabled": true,
  "name": "Evaluate payments changes for feature flags",
  "description": "Evaluates whether saved changes in the payments domain need a flag",
  "version": "1",
  "when": {
    "type": "fileSave",
    "filePattern": "src/payments/**/*.ts"
  },
  "then": {
    "type": "askAgent",
    "prompt": "The file $FILE_PATH was just saved with changes in the payments domain. Use the Unleash MCP server's evaluate_change tool to determine if these changes should be behind a feature flag. If yes, suggest a flag name following our payments naming convention (payments-{feature}-{variant}) and offer to create it."
  }
}

Save as .kiro/hooks/evaluate-payments-flag.kiro.hook.

Every time a developer saves a TypeScript file under src/payments/, this hook fires and asks Kiro to evaluate the change. If a flag is needed, Kiro offers to create and wrap it. The developer does not need to remember. The hook catches risky changes before they are committed.

Manual Trigger hook: Runs a flag audit on demand.


{
  "enabled": true,
  "name": "Feature flag audit",
  "description": "Audit all feature flags and identify cleanup opportunities",
  "version": "1",
  "when": {
    "type": "userTriggered"
  },
  "then": {
    "type": "askAgent",
    "prompt": "Run a feature flag audit using the Unleash MCP server. For each flag in the default project: 1) Use get_flag_state to check its current state, 2) Identify flags at 100% rollout for more than 14 days, 3) Identify flags that haven't been modified in 90 days, 4) Generate a prioritized cleanup report."
  }
}

Save as .kiro/hooks/flag-audit.kiro.hook.

Trigger this from the Hooks panel whenever you want a health check on your flags. It produces a cleanup report without anyone having to write a script or dig through the Unleash dashboard manually.

Hooks use the askAgent action, which sends a prompt to Kiro’s agent. This costs credits, so be mindful of how frequently File Save hooks fire. For directories with high edit frequency, consider moving to a Manual Trigger hook instead.

Layer 4: Package as a Power

You now have three pieces: an MCP server configuration, steering files, and hooks. Separately, they work well. Together, they need per-project setup. A Kiro Power bundles all of it into a single installable package.

Create a directory called power-unleash/ with this structure:


power-unleash/
├── POWER.md
├── mcp.json
└── steering/
    ├── feature-flag-conventions.md
    └── rollout-guidance.md

The POWER.md file is the entry point. It contains YAML frontmatter that tells Kiro when to activate the Power, plus onboarding instructions and steering file mappings:


---
name: "unleash"
displayName: "Unleash Feature Flags"
description: "Automate feature flag management with Unleash. Evaluate risk,
  create flags with consistent naming, generate SDK wrapping code, manage
  rollouts, and clean up stale flags."
keywords: ["feature flag", "feature toggle", "rollout", "unleash", "release",
  "experiment", "kill-switch", "canary", "progressive delivery", "featureops"]
---

# Onboarding

## Step 1: Verify prerequisites
- **Node.js 18+**: Verify with `node --version`
- **Unleash instance**: Cloud or self-hosted, with API access
- **Personal Access Token**: With permissions to create and manage flags

## Step 2: Set environment variables
Create `~/.unleash/mcp.env` with your credentials and source it
from your shell profile. See the README for details.

# When to Load Steering Files
- Setting up feature flags → `feature-flag-conventions.md`
- Configuring rollout strategies → `rollout-guidance.md`

The keywords array is what drives dynamic activation. When a developer mentions “feature flag,” “rollout,” “unleash,” or any of the listed terms, Kiro loads this Power into context. When the conversation moves to something unrelated, the Power unloads. This solves the context overload problem: five installed Powers do not mean 50 extra tools in every conversation.

The mcp.json file is the same configuration from Layer 1:


{
  "mcpServers": {
    "unleash": {
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "env": {
        "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
        "UNLEASH_PAT": "${UNLEASH_PAT}",
        "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT}"
      },
      "autoApprove": ["get_flag_state", "detect_flag", "evaluate_change"]
    }
  }
}

When someone installs the Power, Kiro auto-registers the MCP server in ~/.kiro/settings/mcp.json with a namespaced name (e.g., power-unleash-unleash). No manual configuration needed.

The steering/ directory contains the same files from Layer 2, stripped of the inclusion frontmatter since the Power’s activation keywords handle when to load them.

Share it

Push the power-unleash/ directory to a GitHub repository. Anyone on your team can install it from the Kiro Powers panel: click Add power from GitHub and enter the repository URL. One click, and they get the MCP server, steering files, and conventions. New projects, new hires, and new repositories all start with the same FeatureOps setup.

For local testing before publishing, use Add power from Local Path and point to your power-unleash/ directory.

The Kiro community powers repository already hosts Powers for popular products such as Stripe, Figma, Supabase, and more.

Kiro CLI: the same setup in the terminal

The Kiro CLI shares the same MCP configuration and steering files as the IDE. If you installed the Power in the IDE, it works in the CLI too. Run kiro-cli to start an interactive chat session where you can use the same Unleash MCP tools: evaluate changes, create flags, check state, and run cleanup workflows.

What you built

Four layers, each building on the last:

  1. MCP server gives Kiro the tools to create and manage feature flags
  2. Steering files encode your team’s conventions so Kiro follows them automatically
  3. Hooks trigger evaluation on file saves and manual audits without developer action
  4. A Power packages everything into a one-click install for the whole team

Start with Layer 1 and a few manual workflows. Add steering files when you see patterns forming. Introduce hooks for your highest-risk directories. Once it all works, wrap it in a Power and share it. Each layer is valuable on its own. Together, they make feature flag governance automatic.

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

Share this article