Integrate Unleash with Kiro

View as Markdown

The Unleash MCP server connects Kiro to your Unleash instance, enabling AI-assisted feature flag management. You can evaluate code changes, create flags, generate wrapping code, manage rollouts, and clean up flags from within Kiro’s spec-driven development workflow.

Kiro supports MCP across two interfaces:

  • Kiro IDE — The primary interface, built on Code OSS with specs, steering files, hooks, and Powers
  • Kiro CLI — Interactive terminal-based chat (successor to Amazon Q Developer CLI)

Kiro’s structured primitives create a natural pipeline for feature flags: specs surface risk at the requirements stage, steering files encode your team’s conventions, hooks automate evaluation on file events, and Powers bundle everything into a shareable package.

Prerequisites

Before you begin, make sure you have the following:

  • Node.js 18 or later: The MCP server is distributed as an npm package
  • Kiro: IDE or CLI installed
  • An Unleash instance: Cloud or self-hosted, with API access enabled
  • A personal access token (PAT): With permissions to create and manage feature flags

Install the MCP server

The Unleash MCP server runs as a local stdio process. Configuration differs between the IDE and CLI, but both use the same npm package and credentials.

Kiro uses ${VAR} expansion for environment variables. Create a credentials file and source it from your shell profile:

1

Create 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
2

Source in shell profile

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
3

Reload your shell

$source ~/.zshrc # or ~/.bashrc
VariableDescriptionRequired
UNLEASH_BASE_URLYour Unleash instance API URL. Include /api at the end.Yes
UNLEASH_PATA personal access token with flag creation permissions.Yes
UNLEASH_DEFAULT_PROJECTThe default project for flag operations. If omitted, you must specify projectId in each tool call.No

Now configure your preferred interface:

Requirements: Kiro IDE installed.

Enable MCP support (one-time step):

MCP is disabled by default. Before configuring any MCP servers, enable it:

  1. Open Settings (Cmd+, on macOS, Ctrl+, on Windows/Linux)
  2. Search for MCP
  3. Enable the Kiro: MCP setting

Without this setting enabled, MCP servers will not connect and tools will not appear. This only needs to be done once.

You can add the Unleash MCP server using the Command Palette or by creating the configuration file manually.

1

Open the MCP configuration

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 in your workspace.

For user-scoped (global) configuration, run Kiro: Open user MCP config (JSON) instead. This opens ~/.kiro/settings/mcp.json.

2

Add the Unleash server

Paste the following configuration:

.kiro/settings/mcp.json
1{
2 "mcpServers": {
3 "unleash": {
4 "command": "npx",
5 "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
6 "env": {
7 "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
8 "UNLEASH_PAT": "${UNLEASH_PAT}",
9 "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT}"
10 }
11 }
12 }
13}

When you save this file, Kiro displays a popup listing unapproved environment variables. Click Allow to approve UNLEASH_BASE_URL, UNLEASH_PAT, and UNLEASH_DEFAULT_PROJECT. You can also manage approved variables later in Settings under Mcp Approved Env Vars.

3

Save and verify

Open the MCP Servers tab in the Kiro panel to confirm the Unleash server appears with its tools listed.

To view MCP logs, right-click the Unleash server in the MCP Servers tab and select Show MCP Logs. You can also open the Output panel and choose Kiro - MCP Logs from the dropdown.

ConfigureautoApprove and disabledTools**

Kiro supports two MCP configuration properties for controlling tool approval:

PropertyTypeDescription
autoApproveArray of stringsTool names that Kiro can invoke without asking for confirmation. Use "*" for all tools.
disabledToolsArray of stringsTool names to hide from the agent entirely.

Example with auto-approval for read-only tools:

.kiro/settings/mcp.json
1{
2 "mcpServers": {
3 "unleash": {
4 "command": "npx",
5 "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
6 "env": {
7 "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
8 "UNLEASH_PAT": "${UNLEASH_PAT}",
9 "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT}"
10 },
11 "autoApprove": ["get_flag_state", "detect_flag", "evaluate_change"],
12 "disabledTools": []
13 }
14 }
15}

Use autoApprove for read-only tools like get_flag_state, detect_flag, and evaluate_change. Keep write operations like create_flag and toggle_flag_environment behind manual approval for safety.

Configuration scopes:

LocationScopeUse case
.kiro/settings/mcp.json (project)WorkspaceTeam-shared, version controlled
~/.kiro/settings/mcp.jsonUserPersonal settings across all projects

Both are merged; workspace takes precedence on conflict. For team collaboration, use the workspace-level file.

Tool reference

The Unleash MCP server exposes nine tools. The following table summarizes each tool and when to use it.

ToolDescriptionWhen to use
evaluate_changeAnalyzes a code change and determines whether it should be behind a feature flag.Before implementing risky changes
detect_flagSearches for existing flags that match a description to prevent duplicates.Before creating new flags
create_flagCreates a new feature flag with proper naming, typing, and metadata.When no suitable flag exists
wrap_changeGenerates framework-specific code to guard a feature behind a flag.After creating a flag
get_flag_stateReturns the current state, strategies, and metadata for a flag.Debugging, status checks
set_flag_rolloutConfigures rollout percentages and activation strategies.Gradual releases
toggle_flag_environmentEnables or disables a flag in a specific environment.Testing, staged rollouts
remove_flag_strategyDeletes a rollout strategy from a flag.Simplifying flag configuration
cleanup_flagReturns file locations and instructions for removing a flag after rollout.After full rollout

Workflows

This section describes common workflows for using the Unleash MCP server with Kiro.

Evaluate and wrap a risky change

Use this workflow when implementing a change that might affect production stability, such as a payment integration, authentication flow, or external API call.

1

Evaluate the change

Tell Kiro what you are working on:

Evaluate whether the Stripe payment integration should be behind a feature flag.
The change modifies the checkout service and handles credit card processing.

Kiro calls evaluate_change and returns a recommendation with a suggested flag name.

2

Check for duplicates

Kiro automatically calls detect_flag to search for existing flags. If a suitable flag exists, Kiro suggests reusing it instead of creating a duplicate.

3

Create the flag

If no suitable flag exists:

Create a release flag for the Stripe payment integration.

Kiro calls create_flag with the appropriate name, type, and description. The flag is created in Unleash, disabled by default.

4

Wrap the code

Generate framework-specific guard code:

Wrap the Stripe checkout handler with the stripe-payment-integration flag.
This is a Node.js Express application.

Kiro calls wrap_change and returns code like this:

checkout.js
1const { isEnabled } = require('unleash-client');
2
3app.post('/checkout', async (req, res) => {
4 const context = { userId: req.user.id };
5
6 if (isEnabled('stripe-payment-integration', context)) {
7 // New Stripe payment flow
8 const result = await stripeService.processPayment(req.body);
9 return res.json(result);
10 } else {
11 // Existing payment flow
12 const result = await legacyPaymentService.process(req.body);
13 return res.json(result);
14 }
15});

Spec-driven flag creation

Use this workflow when a Kiro spec identifies a high-risk task during the design phase. Instead of flagging code after implementation, the spec surfaces risk before a single line is written.

1

Create a spec

Create a spec for your feature (for example, “Integrate Stripe payment processing”). During the Design phase, Kiro identifies the payment integration as high-risk based on the architectural analysis.

2

Steering files trigger evaluation

When Kiro begins implementing the payment task, a steering file targeting src/payments/** instructs it to evaluate risk:

Implement the payment integration task from the checkout spec.
Evaluate whether it needs a feature flag.

Kiro calls evaluate_change with the task description and context from the spec.

3

Create and wrap in one flow

If a flag is needed, Kiro calls detect_flag, create_flag, and wrap_change as part of the same task implementation. The flag is in place before the task is marked complete.

Spec-driven flag creation catches risk at the requirements stage rather than during code review. The flag becomes part of the implementation plan, not an afterthought.

Manage rollouts across environments

Use this workflow to enable a flag in staging for testing while keeping it disabled in production.

What is the current state and rollout strategies for stripe-payment-integration?

Kiro calls get_flag_state and returns the flag metadata, enabled environments, and active strategies.

Clean up after rollout

Use this workflow when a feature has been fully rolled out and the flag is no longer needed.

Clean up the stripe-payment-integration flag. The feature is fully rolled out.

Kiro calls cleanup_flag and returns:

  • All files and line numbers where the flag is used
  • Which code path to preserve (the “enabled” branch)
  • Suggestions for tests to run after removal

Review the list, remove the conditional branches, and delete the flag from Unleash.

Feature flags should be temporary. Regularly clean up flags after successful rollouts to prevent technical debt.

Steering file templates

Steering files encode your team’s FeatureOps policies, so Kiro considers feature flags automatically. Store them in .kiro/steering/ and choose the inclusion mode that matches the policy’s scope.

For more details on steering files, see the Kiro steering file documentation.

Always-included: universal conventions

This file loads into every Kiro interaction. Use it for organization-wide flag standards.

.kiro/steering/feature-flags.md
1---
2inclusion: always
3---
4
5# Feature Flag Conventions
6
7When making changes to this codebase, follow these feature flag practices:
8
91. **Always evaluate risk**: Before implementing high-risk changes (payments,
10 authentication, data migrations, external integrations), use the Unleash MCP
11 server to evaluate whether a feature flag is needed.
12
132. **Naming conventions**: Use the format `{domain}-{feature}-{variant}`.
14 Examples: `checkout-stripe-integration`, `auth-sso-google`, `api-rate-limiting`.
15
163. **Flag types**:
17 - `release`: For gradual feature rollouts
18 - `experiment`: For A/B tests and experiments
19 - `operational`: For system behavior toggles
20 - `kill-switch`: For emergency shutdowns
21 - `permission`: For role-based access
22
234. **Prefer reuse**: Before creating a new flag, check if a similar flag already
24 exists using the detect_flag tool.
25
265. **Clean up after rollout**: Once a feature is fully released (100% rollout for
27 2+ weeks), use cleanup_flag to remove dead code.
28
29## Unleash MCP Server
30
31This project uses the Unleash MCP server for feature flag management. Configuration
32is in `.kiro/settings/mcp.json`. Credentials are sourced from environment variables.
33
34Available tools: evaluate_change, detect_flag, create_flag, wrap_change,
35get_flag_state, set_flag_rollout, toggle_flag_environment, remove_flag_strategy,
36cleanup_flag.

fileMatch: domain-specific policies

This file loads only when the conversation involves files matching the glob pattern. Use it for high-risk domains that always require flags.

.kiro/steering/payments-flags.md
1---
2inclusion: fileMatch
3fileMatchPattern: ["src/payments/**/*.ts", "src/payments/**/*.tsx"]
4---
5
6# Payments Domain — Feature Flag Policy
7
8All changes in the payments domain require feature flags. No exceptions.
9
10- Use `kill-switch` type for external payment provider integrations
11 (Stripe, PayPal, etc.)
12- Use `release` type for internal payment logic changes
13- Naming: `payments-{feature}-{variant}`
14 (e.g., `payments-stripe-checkout`, `payments-refund-v2`)
15- Always include a fallback path for external provider calls
16- Evaluate risk with evaluate_change before writing implementation code

Auto-included: rollout guidance

This file loads automatically when Kiro detects the conversation is about rollout strategies.

.kiro/steering/rollout-guidance.md
1---
2inclusion: auto
3name: rollout-guidance
4description: Guidance for configuring feature flag rollout strategies. Use when
5 setting up rollouts, configuring milestones, or discussing gradual releases.
6---
7
8# Rollout Strategy Defaults
9
10When setting up rollouts with set_flag_rollout, use these defaults unless
11specified otherwise:
12
13- Start at 10% rollout
14- Wait 24 hours before advancing
15- Pause if error rate exceeds 1% or p95 latency increases by more than 20%
16
17## Standard milestones
18
19| Milestone | Percentage | Hold period | Advance condition |
20|-----------|-----------|-------------|-------------------|
21| Canary | 10% | 24 hours | Error rate < 1%, latency stable |
22| Beta | 50% | 48 hours | Error rate < 0.5%, no regressions |
23| GA | 100% | — | All metrics healthy for 48 hours |
24
25## Cleanup cadence
26
27Run cleanup_flag weekly for flags that have been at 100% for more than 14 days.

Hook examples

Hooks automate feature flag evaluation based on IDE events. Store them as .kiro.hook files in .kiro/hooks/.

For more details on hooks, see the Kiro hooks documentation.

Evaluate on file save

This hook fires whenever a file in the payments domain is saved. Kiro automatically evaluates whether the change needs a flag.

.kiro/hooks/evaluate-payments-flag.kiro.hook
1{
2 "enabled": true,
3 "name": "Evaluate payments changes for feature flags",
4 "description": "Automatically evaluates whether saved changes in the payments domain should be behind a feature flag",
5 "version": "1",
6 "when": {
7 "type": "fileSave",
8 "filePattern": "src/payments/**/*.ts"
9 },
10 "then": {
11 "type": "askAgent",
12 "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."
13 }
14}

Manual trigger for flag audit

This hook runs on demand when triggered by the user. It audits all flags in the project and generates a cleanup report.

.kiro/hooks/flag-audit.kiro.hook
1{
2 "enabled": true,
3 "name": "Feature flag audit",
4 "description": "Run an audit of all feature flags, identifying stale flags and cleanup opportunities",
5 "version": "1",
6 "when": {
7 "type": "userTriggered"
8 },
9 "then": {
10 "type": "askAgent",
11 "prompt": "Run a comprehensive 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 with recommendations for each stale flag."
12 }
13}

Adjust the filePattern in the File Save hook to match your project’s high-risk directories. You can create multiple hooks targeting different domains (e.g., src/auth/**, src/api/**).

Unleash Power

A Power bundles MCP tools, steering files, and hook definitions into a single installable package. The Unleash Power is the recommended way to distribute the integration across teams and projects.

Directory structure

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

POWER.md

The POWER.md file defines activation keywords and onboarding instructions. When a developer mentions “feature flag,” “rollout,” or “unleash” in chat, Kiro loads the Power’s tools and steering files into context.

power-unleash/POWER.md
1---
2name: "unleash"
3displayName: "Unleash Feature Flags"
4description: "Automate feature flag management with Unleash. Evaluate code changes for risk, create flags with consistent naming, generate SDK wrapping code, manage rollouts, and clean up stale flags."
5keywords: ["feature flag", "feature toggle", "rollout", "unleash", "release", "experiment", "kill-switch", "canary", "progressive delivery", "featureops"]
6---
7
8# Onboarding
9
10## Step 1: Verify prerequisites
11
12- **Node.js 18+**: Verify with `node --version`
13- **Unleash instance**: Cloud or self-hosted, with API access
14- **Personal Access Token**: With permissions to create and manage flags
15
16## Step 2: Set environment variables
17
18Create a credentials file and source it from your shell profile:
19
20\`\`\`bash
21mkdir -p ~/.unleash
22cat > ~/.unleash/mcp.env << 'EOF'
23UNLEASH_BASE_URL=https://your-instance.getunleash.io/api
24UNLEASH_PAT=your-personal-access-token
25UNLEASH_DEFAULT_PROJECT=default
26EOF
27chmod 600 ~/.unleash/mcp.env
28\`\`\`
29
30Add to `~/.zshrc` or `~/.bashrc`:
31
32\`\`\`bash
33if [ -f ~/.unleash/mcp.env ]; then
34 source ~/.unleash/mcp.env
35 export UNLEASH_BASE_URL UNLEASH_PAT UNLEASH_DEFAULT_PROJECT
36fi
37\`\`\`
38
39## Step 3: Add hooks (optional)
40
41Save a File Save hook to `.kiro/hooks/evaluate-payments-flag.kiro.hook`
42to automatically evaluate payments changes. Adjust the `filePattern` to
43match your project's high-risk directories.
44
45# When to Load Steering Files
46
47- Setting up feature flags → `feature-flag-conventions.md`
48- Configuring rollout strategies → `rollout-guidance.md`
49- Cleaning up stale flags → `cleanup-cadence.md`

mcp.json

power-unleash/mcp.json
1{
2 "mcpServers": {
3 "unleash": {
4 "command": "npx",
5 "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
6 "env": {
7 "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
8 "UNLEASH_PAT": "${UNLEASH_PAT}",
9 "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT}"
10 },
11 "autoApprove": ["get_flag_state", "detect_flag", "evaluate_change"]
12 }
13 }
14}

Steering files

1# Feature Flag Conventions
2
3## Naming
4Use the format `{domain}-{feature}-{variant}`.
5Examples: `checkout-stripe-integration`, `auth-sso-google`.
6
7## Flag types
8- `release` – Gradual feature rollouts
9- `experiment` – A/B tests
10- `operational` – System behavior toggles
11- `kill-switch` – Emergency shutdowns
12- `permission` – Role-based access
13
14## Rules
15- Always use detect_flag before creating a new flag
16- Evaluate risk with evaluate_change for changes in payments, auth,
17 data migrations and external integrations
18- Use kill-switch type for any external dependency integration
1# Rollout Strategy Defaults
2
3- Start at 10% rollout
4- Hold 24 hours before advancing
5- Pause if error rate > 1% or p95 latency increases > 20%
6- Standard milestones: 10% → 50% → 100%
7- Each milestone requires 24-48 hours of healthy metrics
1# Flag Cleanup Cadence
2
3- Flags at 100% rollout for more than 14 days should be cleaned up
4- Run cleanup_flag to get file locations and removal instructions
5- Preserve the "enabled" code path; remove the conditional and fallback
6- Run tests after removing flag code to catch regressions
7- Delete the flag from Unleash after code cleanup is merged

Install the Power

You can install the Unleash Power from a local path or from GitHub:

  • From local path: Open the Powers panel, select “Add power from Local Path,” and choose the power-unleash/ directory.
  • From GitHub: Open the Powers panel, select “Add power from GitHub,” and enter the repository URL.

When installed, the Power’s MCP server is auto-registered in ~/.kiro/settings/mcp.json under the “Powers” section with a namespaced server name (e.g., power-unleash-unleash).

For more details on creating and distributing Powers, see the Kiro Powers documentation.

Prompt patterns

The following prompt patterns help you use the MCP tools effectively.

Intent: Determine if a change requires a feature flag, then create and wrap it.

Prompt:

Evaluate whether the [description of change] should be behind a feature flag.
The change modifies [component/service].

Expected behavior: Kiro calls evaluate_change, then detect_flag, create_flag, and wrap_change as needed.

Intent: Avoid duplicate flags when similar functionality exists.

Prompt:

Before creating a new flag for [feature], check if a similar flag already exists
and suggest reusing it if appropriate.

Expected behavior: Kiro calls detect_flag and presents matches with confidence levels.

Intent: Enable, disable, or query a flag in a specific environment.

Prompts:

Enable [flagName] in the staging environment.
What is the current state and rollout strategies for [flagName]?

Expected behavior: Kiro calls toggle_flag_environment or get_flag_state.

Intent: Safely remove flagged code and delete unused flags.

Prompts:

Clean up the [flagName] flag now that the feature has fully shipped.
Clean up the [flagName] flag after the A/B testing experiment, only keep [variant].

Expected behavior: Kiro calls cleanup_flag and provides removal instructions.

Intent: Evaluate flag requirements as part of spec-driven task implementation.

Prompt:

Implement the payment integration task from the checkout spec.
Evaluate whether it needs a feature flag.

Expected behavior: Kiro reads the spec tasks, identifies high-risk ones based on steering file rules, and calls evaluate_change for each. Flags are created and wrapping code is generated as part of the task implementation.

Intent: Automatically evaluate code changes when files are saved.

Trigger: A File Save hook fires when source files in a target directory are saved.

Expected behavior: The hook sends an agent prompt that calls evaluate_change with the saved file’s context. If a flag is needed, Kiro notifies you and offers to create it. In Supervised mode, you approve each step. In Autopilot mode, the flag is created automatically.

Enterprise governance

Kiro provides enterprise controls through AWS IAM Identity Center (which can federate to external identity providers such as Okta and Microsoft Entra ID).

  • Extension registry governance — Point the IDE at a curated extension registry to control which extensions are available
  • Web tools toggle — Enable or disable web search and fetch per organization policy
  • Supervised mode enforcement — Require supervised mode for all users, preventing autonomous agent actions
  • Trusted commands list — Define which shell commands the agent can execute

For MCP server governance, commit .kiro/settings/mcp.json to version control. This ensures all team members use the same MCP servers with the same settings.

Use Supervised mode for high-risk flag operations (creation, rollout configuration, cleanup). Autopilot mode works well for read-only operations like checking flag state and evaluating changes.

Troubleshooting

  • Check .kiro/settings/mcp.json for syntax errors
  • Verify the file is in the correct location (workspace root under .kiro/settings/)
  • Restart Kiro after making changes
  • Right-click the server in the MCP Servers tab and select Show MCP Logs

If you see “Found unapproved environment variables in MCP config,” Kiro requires explicit approval before expanding variables.

  • When you first save the config, click Allow on the popup to approve the listed variables
  • Or open Settings, search for Mcp Approved Env Vars, and add UNLEASH_BASE_URL, UNLEASH_PAT, and UNLEASH_DEFAULT_PROJECT
  • After approving, restart Kiro or reload the window
  • Restart your terminal or IDE after modifying your shell profile
  • Run source ~/.zshrc to reload
  • Kiro inherits environment variables from the shell that launched it
  • Verify variables are exported: echo $UNLEASH_BASE_URL
  • Verify the variables are approved in Settings → Mcp Approved Env Vars
  • Confirm your Unleash PAT is valid and has not expired
  • Check that the PAT has permissions to create and manage feature flags
  • Verify that UNLEASH_BASE_URL includes /api at the end
  • Test directly: curl -H "Authorization: $UNLEASH_PAT" "$UNLEASH_BASE_URL/admin/projects"
  • Verify the hook file is in .kiro/hooks/ and has the .kiro.hook extension
  • Check that enabled is true in the hook JSON
  • Verify the filePattern matches the saved file’s path
  • For hooks documentation, see Kiro hook types
  • Check that keywords in the POWER.md frontmatter match what you are saying in chat
  • Powers activate on keyword matches — use terms like “feature flag,” “rollout,” or “unleash”
  • Verify the Power is installed in the Powers panel
  • The autoApprove array must use exact tool names
  • Use "*" to approve all tools, or list specific names like ["get_flag_state", "detect_flag"]
  • Verify the property is inside the server configuration object, not at the root level

Workspace configuration (.kiro/settings/mcp.json) takes precedence over user configuration (~/.kiro/settings/mcp.json). If a server is disabled in workspace config, it remains disabled even if enabled in user config.

Best practices

Follow these guidelines for effective feature flag management with Kiro.

Keep humans in the loop

While the MCP server can automate flag creation, high-risk changes should involve human review. Use Supervised mode for flag creation, rollout plans, and cleanup decisions.

Define naming conventions

Establish organization-wide standards for flag names (e.g., domain-feature-variant) and types. Encode these in steering files so Kiro applies them automatically.

Prevent duplication

Always use detect_flag before creating new flags. This keeps naming consistent and reduces fragmentation across services.

Keep flags temporary

Feature flags should be removed after successful rollouts. Use cleanup_flag regularly to prevent technical debt. Set up a Manual Trigger hook for periodic audits.

Use workspace scope for teams

Configure MCP servers at workspace scope (.kiro/settings/mcp.json) and commit to version control. All team members get the same configuration.

Encode policies in steering files

Write your feature flag guidelines in steering files with appropriate inclusion modes. Kiro reads these files and applies the guidance automatically based on context.