> Markdown version of https://www.getunleash.io//blog/kiro-power-from-setup-to-distribution > For clean Markdown of any blog post, append .md to its URL. > For a site index, see https://www.getunleash.io//llms.txt. # Building an Unleash Power for Kiro: Feature Flags from Setup to Distribution _Published 2026-03-26 by Alex Casalboni in How to._ The [first post in this series](https://www.getunleash.io/blog/spec-driven-feature-flags-kiro) 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: ```json { "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: ```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 ``` Add to your **~/.zshrc** or **~/.bashrc**: ```shell 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: ```js 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: ```markdown --- 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: ```markdown --- 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. ```json { "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. ```json { "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: ```shell 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: ```markdown --- 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: ```json { "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](https://github.com/kirodotdev/powers) already hosts Powers for popular products such as Stripe, Figma, Supabase, and more. ### Kiro CLI: the same setup in the terminal The [Kiro CLI](https://kiro.dev/docs/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](https://docs.getunleash.io/integrate/kiro) and the [Unleash MCP server repository](https://github.com/Unleash/unleash-mcp).