Feature Flags and Progressive Delivery
Pathrule2 Rules • 2 Memories • 1 Skill
Feature flags and progressive delivery let teams change exposure without rebuilding an artifact, but they also create a runtime control plane that can drift from code. This bundle defines typed evaluation, stable targeting context, safe defaults, cohort rollout, telemetry, rollback, and flag retirement. Unlike Vercel Deploy, it governs product exposure across deployment platforms rather than one hosting and release surface.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
run-progressive-rollout
src/
flags/
Evaluate flags through one typed boundary
Targeting context is a data contract
features/
Roll out by stable subjects with a measured rollback
Every flag has a removal state
Rules
2Evaluate flags through one typed boundary/src/flagshighstrictEvery flag has a declared type, stable key, owner, purpose, safe default, lifecycle, and evaluation adapter.
| 1 | Every flag has a declared type, stable key, owner, purpose, safe default, lifecycle, and evaluation adapter. Scattered provider calls and string keys produce inconsistent defaults, missing context, and behavior that cannot be found or retired reliably. Enforce this boundary in /src/flags so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Expose typed application functions instead of raw SDK calls or provider flag keys in feature code. |
| 4 | - Validate returned values and fall back to the declared safe default on missing, malformed, timeout, or provider error states. |
| 5 | - Emit evaluation reason, variant, provider, context class, and flag version without logging sensitive targeting attributes. |
| 6 | - Keep authorization and durable entitlement decisions outside feature flags unless a separate authoritative policy enforces them. |
| 7 | |
| 8 | Verification: Disable the provider and return missing, malformed, and wrong-type values; confirm every caller receives the same safe behavior and telemetry reason. |
Roll out by stable subjects with a measured rollback/src/featureshighstrictCohorts use server-derived stable targeting keys and each rollout step has success, failure, pause, and rollback signals.
| 1 | Cohorts use server-derived stable targeting keys and each rollout step has success, failure, pause, and rollback signals. Random or mutable client attributes move users between variants and can hide regressions by changing the population during measurement. Enforce this boundary in /src/features so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Choose the subject that owns the experience, such as user, account, device, or request, and keep it stable for the rollout's duration. |
| 4 | - Start with internal or low-risk cohorts, then expand only after a defined observation window meets product and reliability guardrails. |
| 5 | - Compare treatment and control on user outcomes, errors, latency, support, and data integrity, not only flag evaluation counts. |
| 6 | - Make kill-switch behavior fast, permissioned, audited, and tested before exposure begins. |
| 7 | |
| 8 | Verification: Replay the same subjects across devices and services, simulate provider failure and regression signals, and confirm assignment stability plus immediate safe rollback. |
Memories
2Targeting context is a data contract/src/flagsEvaluation context can include identity, tenant, locale, environment, or device data, so inconsistent naming and precedence change who receives a feature.
| 1 | Evaluation context can include identity, tenant, locale, environment, or device data, so inconsistent naming and precedence change who receives a feature. Define allowed fields, types, sources, sensitivity, and merge precedence centrally. |
| 2 | |
| 3 | Derive authoritative fields on the server and pass only the minimum attributes required by targeting rules. Use one canonical targeting key for deterministic allocation and never repurpose it mid-rollout. Version context changes that can alter cohorts and test them against recorded evaluation fixtures. Keep the decision explicit at /src/flags; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/features for product behavior and the progressive rollout skill for cohort decisions. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Every flag has a removal state/src/featuresA flag is temporary control-plane state unless it represents a long-lived operational setting with explicit ownership.
| 1 | A flag is temporary control-plane state unless it represents a long-lived operational setting with explicit ownership. Record creation reason, owner, expected decision date, cleanup condition, and code locations when the flag is introduced. |
| 2 | |
| 3 | After full rollout, remove the losing branch, provider configuration, telemetry, tests, and compatibility code in one tracked cleanup. After rollback, remove the failed branch or open a new experiment with a new hypothesis rather than leaving ambiguity. Review permanent operational flags separately for access, audit, defaults, and disaster behavior. Keep the decision explicit at /src/features; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/flags for registry metadata and /.github/workflows for cleanup enforcement. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Skills
1run-progressive-rollout/rootRun a feature rollout through readiness, stable cohorts, guardrail checks, pause, rollback, and flag retirement.
| 1 | --- |
| 2 | name: run-progressive-rollout |
| 3 | description: Run a feature rollout through readiness, stable cohorts, guardrail checks, pause, rollback, and flag retirement. |
| 4 | --- |
| 5 | |
| 6 | # Run Progressive Rollout |
| 7 | |
| 8 | Run this procedure whenever the governed surface changes or its operational evidence becomes stale. |
| 9 | |
| 10 | 1. Confirm the flag owner, safe default, targeting subject, treatment and control behavior, telemetry, support plan, and tested kill switch. |
| 11 | 2. Define cohort steps, observation windows, success metrics, reliability and safety guardrails, and the authority to pause or roll back. |
| 12 | 3. Expose internal and low-risk cohorts first, verify stable assignment and data quality, then expand one step at a time with recorded decisions. |
| 13 | 4. Choose ship or rollback, remove the unused branch and flag configuration, and verify no stale evaluation or targeting data remains. |
| 14 | |
| 15 | Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory. |
Why this pattern
Agents add boolean checks without owners or expiry, evaluate with unstable context, choose permissive defaults, and leave both code paths alive long after rollout.
Built for Teams using feature flags for staged release, experiments, operational control, or entitlements.
Keeps your assistant from:
- Different services evaluating the same flag with different context
- Provider outage enabling an unsafe or unreleased path
- Expired flags and dead branches accumulating permanently
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-08-25