Add Feature Flag
Developmentadd-feature-flagAdd 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.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
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