Skip to main content

audit-feature-flags

Audit feature flags for purpose, ownership, state coverage, exposure, stale code, operational risk, and safe removal. Use when a flag inventory has grown, ownership is unclear, or rollout controls may no longer match production behavior.

来源信息

仓库
protosphinx/sphinxstack
最近来源活动
2026年7月29日 13:55
检测到的 SKILL.md 语言
英语
星标
3
Forks
0

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
2 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
audit-feature-flags
category
code
description
Audit feature flags for purpose, ownership, state coverage, exposure, stale code, operational risk, and safe removal. Use when a flag inventory has grown, ownership is unclear, or rollout controls may no longer match production behavior.
# audit-feature-flags Reconcile flag-service configuration with code and runtime behavior. Distinguish release, experiment, operational, permission, and long-term configuration flags because their lifecycles differ. ## Inputs - Gather flag-provider exports, code references, defaults, environments, targeting, history, telemetry, and owners. - Identify sensitive attributes, kill switches, experiments, dependencies, and offline or degraded behavior. - Confirm retention, approval, and removal rules. ## Procedure 1. Build a canonical inventory with key, type, purpose, owner, created date, expiry, default, and environments. 2. Reconcile provider records with code, configuration, tests, documentation, and deployed artifacts. 3. Identify missing, orphaned, duplicated, stale, permanently on, permanently off, and ownerless flags. 4. Review targeting attributes, audience size, privacy, fairness, and environment drift. 5. Test on, off, missing-provider, stale-cache, invalid-value, and dependency combinations. 6. Verify kill switches fail in the intended safe direction and remain operable. 7. Classify retain, repair, conclude experiment, convert to configuration, or remove. 8. Plan removal across code, provider, tests, metrics, documentation, and data analysis in safe order. 9. Execute a representative cleanup and verify behavior plus rollback. 10. Add creation requirements, expiry alerts, ownership review, and inventory checks. ## Boundaries Do not expose targeting rules or personal attributes beyond approved access. Never delete a flag before proving code behavior for all relevant states. Obtain authority before changing production targeting or kill switches. ## Done - Provider, code, runtime, owner, and environment inventories reconcile - Every flag has a type, purpose, state evidence, risk, and lifecycle decision - State combinations and critical degraded behavior are tested - Cleanup or retained-risk actions have owners, verification, rollback, and review dates
在 GitHub 查看