warpdotdev/warp · Archived

add-feature-flag

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

First seen May 11, 2026

Installation

$ npx skills add warpdotdev/warp --skill add-feature-flag

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from warpdotdev/warp · top by installs.

npx skills add warpdotdev/warp

Browse all from warpdotdev/warp

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 64.9K
License LICENSE-AGPL
Default branch master
Open issues 3,847
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,495 B
  • docs SUMMARY.md 89 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 8 installs

SKILL.md

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 (warpcore/src/features.rs) and the runtime FeatureFlag::X.isenabled() check are SHARED by both front-ends: the GUI desktop app (app/) and the headless TUI (crates/warptui). The Cargo-feature steps in this skill (app/Cargo.toml, app/src/lib.rs) are GUI-app-specific. Prefer runtime isenabled() 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