bubbles-flag-lifecycle

Governs feature-flag introduction, maintenance, and retirement across release trains.

1|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-flag-lifecycle-pkirsanov
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bubbles-flag-lifecycle
Source: https://github.com/pkirsanov/bubbles/tree/main/skills/bubbles-flag-lifecycle
Command: npx skills add https://github.com/pkirsanov/bubbles --skill bubbles-flag-lifecycle-pkirsanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Feature flags accumulate as dead conditional code in trunk when no one owns their retirement, causing technical debt, confusing configuration bundles, and blocked release-train retirements. ## Core Features & Use Cases - Ownership Chain: Defines who introduces, maintains, and retires each flag, tied to the owning release train's lifecycle phases (active, maintained, frozen, retired). - Flag Dies + 1 Cycle Rule: Enforces that a flag must be retired within one cycle after its owning train graduates, with blocking violations at train retirement. - Cleanup Triggers and Audit: Supports calendar-based monthly audits, train-retire gates, and manual on-demand audits, plus a full cleanup checklist covering config bundles, service code, state.json, and tests. - Use Case: When retiring a release train, run the flag audit to find flags still declared in specs, then open cleanup specs to remove flag entries from config bundles, env var reads, conditionals, and tests before the retire gate passes. ## Quick Start Ask the agent to audit feature flags for a retiring release train and generate the cleanup spec covering config bundles, service code, and tests.

Frequently Asked Questions about bubbles-flag-lifecycle

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

FAQPage Schema
How do I retire a feature flag tied to a release train?▼

Run the flag audit to identify overdue flags, then open a cleanup spec that removes the flag from all train config bundles, the env var read in startup code, the conditional in business code, the flagsIntroduced entry in state.json, and flag-specific tests.

What is the flag dies plus one cycle rule?▼

A flag introduced by a spec on train X must be retired within one cycle after train X graduates from active to maintained and frozen. Once the train transitions to retired, any remaining live flag is a blocking violation that refuses the release-train-retire gate.

How should feature flags be named across services?▼

Use snake case verb-noun or feature-noun names without train names or version suffixes, such as enable_fast_checkout. Flags must be boolean switches only; use configuration instead of flags for enums or permanent settings.

Why does release-train-retire refuse to transition a train?▼

The retire mode refuses when any spec on the train still declares flagsIntroduced with live flags. Run the cleanup audit and complete a cleanup spec for each remaining flag before retrying the retirement.

Should flag reads in code have fallback defaults?▼

No. Flag reads must fail fast with expect() or KeyError so a missing flag causes startup failure rather than silently defaulting. A startup error like env required means the flag exists in code but not in the bundle.