完成 rollout 后安全移除代码中的…

当 feature flag 的 rollout 已完成，需要从代码中删除 flag 引用、清理死分支并硬编码正确的前向值时使用。

适用场景

解决思路

1. 如果尚未确定要清理哪个 flag，先使用 flag discovery skill（../launchdarkly-flag-discovery/SKILL.md）审计并找出候选 flag。
2. 确认环境中已配置远程托管的 LaunchDarkly MCP server，并可用必需 MCP 工具 check-removal-readiness 和 get-flag；可选工具为 archive-flag 和 delete-flag，其中 delete-flag 不可逆，优先 archive-flag。
3. 遵循核心原则：安全优先，始终保留当前生产行为；以 LaunchDarkly 为事实来源，绝不猜测前向值；遵循现有代码风格和结构；最小变更，只移除 flag 相关代码。
4. Step 1 探索代码库：在改动 LaunchDarkly 或删除代码前，先理解该 flag 在代码库中的使用方式。
5. Step 1.1 查找 flag key 的所有引用：搜索 flag key 字符串（例如 new-checkout-flow），检查直接 SDK 求值调用（variation()、boolVariation()、useFlags() 等）、引用该 key 的 constants/enums、抽象 SDK 的 wrapper/service 模式、配置文件、测试和文档；参考 references/sdk-patterns.md 查看按语言分类的完整模式列表。
6. Step 1.2 理解分支：对每个引用，识别 flag 为 true（或 variation A）时运行什么代码，flag 为 false（或 variation B）时运行什么代码，以及是否存在副作用、提前返回或嵌套条件。
7. Step 1.3 记录范围：确定该 flag 触及多少文件、组件或模块；一个 if 块中的 flag 比贯穿多层的 flag 更简单。
8. Step 2 运行移除就绪检查：使用 check-removal-readiness 获取详细安全评估；该工具并行编排多个检查：flag 配置和 targeting 状态、跨环境状态、依赖 flags（prerequisites）、即将过期的 targets、代码引用统计。
9. Step 2.1 处理就绪结论：safe 表示无阻塞或警告，可继续移除；caution 表示无硬阻塞但有警告（例如其他仓库中的代码引用、已计划的 expiring targets、flag 被标记为 permanent），应向用户展示警告并让用户决定；blocked 表示有硬阻塞阻止安全移除（例如依赖 flags、正在接收请求、targeting 开启且有活跃规则），应向用户展示阻塞项，用户必须先解决。
10. Step 3 确定前向值：使用 get-flag 获取每个关键环境中的 flag 配置；前向值是将在代码中替换该 flag 的 variation。
11. Step 3.1 当所有关键环境为 ON、fallthrough 相同且无 rules/targets 时，使用 fallthrough.variation。
12. Step 3.2 当所有关键环境为 OFF 且 offVariation 相同时，使用 offVariation。
13. Step 3.3 当关键环境 ON/OFF 状态不同时，标记为 NOT SAFE：停止并告知用户。
14. Step 3.4 当关键环境提供不同 variations 时，标记为 NOT SAFE：停止并告知用户。
15. Step 4 展示清理计划：在修改任何代码前，向用户展示摘要并等待确认。
16. Step 4.1 摘要中说明前向值是什么，以及为什么基于该 flag 当前状态是正确的。
17. Step 4.2 摘要中列出 Step 1 找到的所有代码引用，包括文件路径和行号。
18. Step 4.3 摘要中列出计划变更：对每个引用描述将删除什么、将保留什么。
19. Step 4.4 摘要中列出就绪结论（safe、caution 或 blocked）以及任何警告。
20. Step 4.5 摘要中确认 LaunchDarkly 操作：代码变更完成后将归档该 flag。
21. Step 4.6 在用户明确确认前，不得继续修改代码。
22. Step 5 从代码中移除 flag：使用 Step 1 了解到的信息执行移除。
23. Step 5.1 用前向值替换 flag 求值：保留匹配前向值的代码分支，完全删除死分支；如果 flag 值被赋给变量，用字面量替换该变量或将其内联。
24. Step 5.2 清理死代码：删除仅为该 flag 存在的 imports、constants 和类型定义；删除仅为死分支存在的 functions、components 或 files；检查孤立的 exports、hooks、helpers、styles 和 test files；如果 repo 使用 unused-export 工具（Knip、ts-prune、lint rules），运行它并移除任何与该 flag 相关的孤立项。
25. Step 5.3 不要过度清理：只删除与该 flag 直接相关的代码；不要重构、优化或“改进”周边代码；不要更改未触及代码的格式或风格。
26. Step 5.4 参考示例转换：boolean flag 且前向值为 true 时，将 const showNewCheckout = await ldClient.variation('new-checkout-flow', user, false); if (showNewCheckout) { return renderNewCheckout(); } else { return renderOldCheckout(); } 变换为 return renderNewCheckout();。
27. Step 6 创建 Pull Request：使用 references/pr-template.md 中的模板撰写结构化 PR 描述。
28. Step 6.1 PR 应清楚说明移除了什么 flag 及原因。
29. Step 6.2 PR 应说明前向值是什么以及为什么它正确。
30. Step 6.3 PR 应包含就绪评估结果（来自 check-removal-readiness）。
31. Step 6.4 PR 应说明删除了什么代码以及保留了哪些行为。
32. Step 6.5 PR 应说明其他 repos 是否仍引用该 flag。
33. Step 7 验证：在认为任务完成前执行以下检查。
34. Step 7.1 代码可编译且通过 lint：运行项目的 build 和 lint 步骤。
35. Step 7.2 测试通过：如果该 flag 在测试中使用，更新测试以反映硬编码后的行为。
36. Step 7.3 无剩余引用：再次搜索代码库中的 flag key，确保没有遗漏。
37. Step 7.4 PR 完整：描述涵盖就绪评估、前向值理由以及任何跨 repo 协调需求。
38. 处理 edge case：如果 flag 在 LaunchDarkly 中不存在，告知用户并检查 key 是否拼写错误。
39. 处理 edge case：如果 flag 已归档，询问是否仍需要代码清理（flag 已从 LD 消失，但代码可能仍引用它）。
40. 处理 edge case：如果代码库有多种 SDK 模式，搜索所有模式：variation()、boolVariation()、variationDetail()、allFlags()、useFlags()，以及任何 wrappers。
41. 处理 edge case：如果使用动态 flag keys（flag-${id}），警告自动移除可能不完整，需要手动审查。
42. 处理 edge case：如果代码与 LaunchDarkly 中的默认值不同，在 PR 描述中标记该不一致。
43. 处理 edge case：如果移除后仍残留孤立 exports/files，运行 unused-export 检查并删除死文件。
44. 不要做：不要更改与 flag 清理无关的代码。
45. 不要做：不要重构或优化超出 flag 移除范围的内容。
46. 不要做：不要移除仍在积极 rollout 的 flags。
47. 不要做：不要猜测前向值，始终查询 LaunchDarkly。
48. 清理后：一旦 PR 已合并并部署，使用 archive-flag 在 LaunchDarkly 中归档该 flag；归档可逆，删除不可逆，始终先归档。
49. 清理后：如果 check-removal-readiness 报告其他仓库中有代码引用，通知其他团队。
50. 清理后：如果该 flag 有待处理的 targeting changes，可以忽略，因为该 flag 正在被移除。
51. 参考资源：使用 references/pr-template.md 获取结构化 PR 描述；使用 references/sdk-patterns.md 获取按语言/框架分类的 flag 求值模式；需要先找候选时使用 ../launchdarkly-flag-discovery/SKILL.md；如果需要更改 targeting 而不是移除，使用 ../launchdarkly-flag-targeting/SKILL.md。

适用边界 · 注意事项

• 关键环境 ON/OFF 状态不同，或关键环境提供不同 variations 时，不应继续，必须停止并告知用户。
• 仍在积极 rollout 的 flag 不应移除。
• 没有配置远程 LaunchDarkly MCP server，或无法访问 check-removal-readiness/get-flag 时，不应执行该技能。