runtime-feature-flags

Add, roll out, and retire runtime feature flags across Kandev backend and frontend.

733|110|Updated Jan 9, 2026
One-click install
npx skills add https://github.com/kdlbs/kandev --skill runtime-feature-flags
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: runtime-feature-flags
Source: https://github.com/kdlbs/kandev/tree/main/.agents/skills/runtime-feature-flags
Command: npx skills add https://github.com/kdlbs/kandev --skill runtime-feature-flags

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Managing temporary release toggles across a Go backend and a web frontend is error-prone: flags can drift between profile defaults, typed config, registries, and UI gates, leaving disabled features reachable or stale flags impossible to remove safely. This Skill provides a complete checklist for adding, rolling out, promoting, graduating, and removing runtime feature flags in the Kandev codebase.

Core Features & Use Cases

  • End-to-end flag lifecycle: Covers adding a flag (profile defaults, backend config, registry binding, backend gates, frontend contract, tests), staged rollout, promotion to default-on, and full graduation with retired-identity registration.
  • Fail-closed invariants: Enforces that disabled features are unreachable through HTTP, WebSocket, MCP, agent-tool, and background-job entry points, with a single identity across features.<camelCaseKey>, KANDEV_FEATURES_<UPPER_SNAKE_CASE>, and frontend keys.
  • Verification workflow: Lists exact test, lint, typecheck, and E2E commands plus handoff reporting requirements.
  • Use Case: When a task asks to put a risky new feature behind a kill switch, use this Skill to wire the toggle through profiles.yaml, runtimeflags/registry.go, backend gates, and the frontend features slice in one consistent change.

Quick Start

Add a new runtime feature flag for the experimental dashboard feature, keeping it off in all shipped profiles and gated on every backend and frontend entry path.

Frequently Asked Questions about runtime-feature-flags

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new feature flag in Kandev?▼

Add the flag in one change across all layers: a `KANDEV_FEATURES_<NAME>` default in profiles.yaml, a bool field in the backend FeaturesConfig, one registry entry in runtimeflags/registry.go, backend gates at entry points, the frontend key in the features types, and enabled/disabled tests.

How do I graduate and remove a feature flag safely?▼

Make the new behavior unconditional, then remove the profile entry, config field, registry registration, backend conditionals, and frontend gates. Append the key and env var to the append-only retiredRuntimeFlagIdentities registry so stale operator overrides cannot reactivate a future feature.

What is the rollout process for a Kandev release toggle?▼

Merge with all shipped profile defaults off, enable it on one installation via Settings > System > Feature Toggles or an environment variable, then set only the prod profile value to true for the next release while keeping the gates as a kill switch.

Why must a disabled feature flag block backend entry points?▼

Hiding only the frontend leaves the feature reachable through HTTP, WebSocket, MCP, agent-tool, and background-job callers. The backend is authoritative, so the disabled path must fail closed before deriving data, writing state, or dispatching work.

Can I reuse a retired feature flag key or environment variable?▼

No. Retired identities are recorded in an append-only registry with collision and completeness tests. Reusing a key or env var could let stale runtime_flag_overrides rows reactivate an unrelated future feature.