用途：该技能针对一个应通过功能开关发布的 PR 变更，端到端地驱动流程：判断是否需要开关、创建守护开关、在 PR 分支上把新行为接入开关，并记录自动化发布，使变更在 PR 合并后安全上线。部署不等于发布：合并只上线控制路径，开关创建时为 OFF，因此部署始终提供变更前行为；发布是自动化 rollout 随后执行的开关操作，受环境策略约束。
主要能力：作为可移植的 PR 编排器，它不拥有开关机制或发布机制，而是组合三个技能并补充 PR 工作流（读取 diff、在克隆中工作、推送到分支）以及“先计划后实现”的顺序。三个组合技能为：should-flag-change（只读建议，判断是否值得加开关）、launchdarkly-flag-create（创建开关并接入代码）、flag-release（记录发布）。
使用方式：分计划与实现两阶段，中间需与用户确认。计划阶段不创建或修改任何内容：确认是否应加开关、阅读三点 diff 与变更文件、按 flag-create 第一步了解代码库现有开关用法、设计开关（通常为单个布尔 kill-switch）、按 flag-release 计划阶段选择目标环境并捕获发布意图，然后呈现合并计划并等待批准。实现阶段仅在批准后：用 launchdarkly-flag-create 创建 OFF 开关并接入代码，添加开关开/关配对测试并跑绿，提交并推送到 PR 现有分支，再交给 flag-release 实现阶段记录自动化 rollout 并返回 config_id，最后报告已验证内容。
前置条件：远程托管的 LaunchDarkly MCP 服务器；可读取并推送到 PR 仓库的 git CLI；可用的组合技能。凭据由环境提供，不得询问、打印或存储令牌。
限制与边界：计划阶段不得创建任何内容；不要重复文档化开关创建、SDK 守护或 rollout 机制；不要自行打开开关；不要过度加开关；创建失败（除“已存在”外）须硬停止，不得接入代码或声称成功；代码库无 LaunchDarkly SDK 时无法接入；需要多于布尔值时仅在服务不同变体时才用多变量。发布相关边界情况由 flag-release 处理。具体命令与代码示例以原技能文档为准。