OpenParable
Skip to content
← Back to skills

Add Feature Flag

Development
add-feature-flag

Add Feature Flag is an Agent Skill for development published in the warpdotdev/warp repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Add a new feature flag to gate code changes in the Warp codebase.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/warpdotdev/warp/blob/HEAD/.agents/skills/add-feature-flag/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/add-feature-flag, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

add-feature-flag

Add a new feature flag to gate code changes in the Warp codebase.

Overview

Feature flags in Warp are compile-time flags that allow features to be selectively enabled for different channels (e.g.: Dev, Stable). They use a small runtime plumbing layer that checks if a flag is enabled.

TUI note

The FeatureFlag enum (warp_core/src/features.rs) and the runtime FeatureFlag::X.is_enabled() check are SHARED by both front-ends: the GUI desktop app (app/) and the headless TUI (crates/warp_tui). The Cargo-feature steps in this skill (app/Cargo.toml, app/src/lib.rs) are GUI-app-specific. Prefer runtime is_enabled() checks so a flag works in both front-ends with no per-binary wiring. Only if you truly need a compile-time Cargo feature in the TUI, wire it into crates/warp_tui/Cargo.toml as well. Test the TUI with ./script/run-tui.

Steps

1. Add to Cargo.toml

Add the feature to app/Cargo.toml under the [features] section, but NOT under the default nested stanza:

[features]
your_feature_name = []

2. Add to FeatureFlag enum

Add a new variant to the FeatureFlag enum in warp_core/src/features.rs:

#[derive(Sequence)]
pub enum FeatureFlag {
    YourFeatureName,
}

3. Add conditional compilation directive

Add the feature to app/src/lib.rs with a corresponding #[cfg(feature = "...")] attribute to ensure it's only included when enabled:

#[cfg(feature = "your_feature_name")]
YourFeatureName,

4. Gate code with runtime checks

In your code, use the runtime check to conditionally execute feature-gated code:

if FeatureFlag::YourFeatureName.is_enabled() {
    // feature-gated behavior
}

5. (Optional) Enable for dogfood builds

To enable the feature by default for Dev/dogfood builds, add it to the DOGFOOD_FLAGS array in features.rs:

pub const DOGFOOD_FLAGS: &[FeatureFlag] = &[
    FeatureFlag::YourFeatureName,
];

6. Running with feature flags

To test locally with the feature enabled:

cargo run --features your_feature_name

# Multiple features:
cargo run --features your_feature_name,another_feature

Keybindings with Feature Flags

If adding an EditableBinding or FixedBinding that's part of a gated feature, include an enabled predicate that checks the feature flag. This prevents the keybinding from appearing in keyboard settings when the feature is disabled.

Example:

EditableBinding::new(
    "action:name",
    "Action description",
    YourAction::Variant
)
.with_enabled(|| FeatureFlag::YourFeatureName.is_enabled())
.with_key_binding("cmdorctrl-key")

Rolling Out to Stable

When ready to enable the feature for all Warp Stable users, add it to the default array in app/Cargo.toml:

[features]
default = [
    "your_feature_name",
    # other default features...
]

Best Practices

  • Prefer runtime checks over cfg directives: Use FeatureFlag::YourFeatureName.is_enabled() instead of #[cfg(...)] when possible, so flags can be toggled without recompilation and are easier to clean up later
  • Use #[cfg(...)] only when code cannot compile without the flag (e.g., platform-specific code or missing dependencies)
  • Keep flags high-level and product-focused rather than per-call-site
  • Remove flags and dead branches after launch has stabilized