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.