mcpField
F
flag-rules

flag-rules

github.com/growthbook开发2539 次安装4 周前更新
代码仓库

关于 flag-rules

flag-rules 是用于管理 GrowthBook 功能标志规则的 Skill，可查看、删除和调整规则顺序，并将创建或编辑需求转交给专用 Skill。它强调规则评估顺序及草稿发布流程。

主要功能

  1. 01按评估顺序列出规则
  2. 02通过草稿删除规则
  3. 03调整完整规则列表顺序
  4. 04将编辑需求转给专用 Skill
  5. 05将变更交由发布流程处理

适用场景

  1. 01检查哪条规则会优先匹配
  2. 02发布前移除过期规则
  3. 03调整规则的评估优先级

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/growthbook/skills --skill flag-rules

安装后在 Claude Code 中输入/flag-rules确认已加载。

详细介绍

flag-rules

GrowthBook 功能开关规则操作的入口。使用此技能检查规则、删除规则或重新排序规则。若要创建或编辑规则，此技能会识别合适的规则类型，并转交给专用技能。

所有 API 调用都通过捆绑的辅助程序完成：${CLAUDE_PLUGIN_ROOT}/scripts/gb-call。需要在环境中设置 GB_API_KEY，或由 /growthbook:gb-setup 写入 ~/.config/growthbook/.env。

规则类型参考

类型功能技能
force / rollout提供特定值，可选择仅面向随机比例的用户。rollout 与 force 类型相同，但 coverage < 1 且必须设置 hashAttribute — 服务器会根据实际覆盖率自动在两者之间切换。flag-targeting
experiment-ref通过关联的实验运行 A/B 测试flag-experiment

规则按从上到下的顺序评估，首个匹配项优先。顺序很重要。

工作流

路径 A — 列出功能开关上的规则
gb-call GET /api/v2/features/<flag-id>

按评估顺序用编号列表展示 rules 数组：

Rules on `<flag-id>` (top-to-bottom evaluation):
  1. [force]          all environments              value="true"    "Beta testers" (saved group)
  2. [rollout]        production                    coverage=10%    hash=id
  3. [experiment-ref] production, staging           → exp_abc123    "Checkout experiment"
  4. [force]          staging                       value="false"   "Kill switch"

对每条规则，显示：编号、类型、范围（allEnvironments 或特定环境）、启用状态、对规则效果的一行摘要，以及供参考的规则 ID（UUID）。

路径 B — 将创建／编辑规则的请求转交给合适的技能

询问用户想要实现什么，并进行转交：

用户意图转交给
“向符合条件 Y 的用户提供 X”flag-targeting
“向 N% 的用户逐步推出”flag-targeting
“运行 A/B 测试”（实验已存在）flag-experiment
“运行 A/B 测试”（从头开始）experiment-launch — 它会创建实验，并端到端地复用或创建功能开关
“早上 9 点开启，下午 5 点关闭”flag-schedule
“将流量从 5% 逐步提高到 100%”flag-ramp
“逐步发布并监控护栏指标”flag-monitoring
“仅当功能 Y 已启用时”（整个功能开关）flag-prerequisites
“仅当功能 Y 已启用时”（一条规则）flag-targeting

如果用户的描述含糊不清，转交前先提出一个澄清问题。

路径 C — 删除规则

展示编号列表（路径 A），让用户按编号选择。确认：

“删除规则 <N>（<type>、<scope>、<summary>）？此操作会进入草稿，只有发布后才会生效。”

gb-call DELETE /api/v2/features/<flag-id>/revisions/new/rules/<rule-id>

记录返回的 version。转交给 flag-publish。

移除 safe-rollout： 如果规则仍处于草稿状态且发布尚未开始，服务器会清理 SafeRollout 实体。如果发布已经开始，SafeRollout 实体会保留（不会丢失数据），但规则会从功能开关中移除。

移除 experiment-ref： 不会影响关联的实验。从功能开关中移除规则不会停止或修改实验。

路径 D — 重新排序规则

展示当前顺序（路径 A）。询问用户需要的新顺序（按编号说明，或描述期望的顺序）。

echo '{"ruleIds":["<id-1>","<id-2>","<id-3>"]}' \
  | gb-call POST /api/v2/features/<flag-id>/revisions/new/rules/reorder -

提供包含所有规则 ID 的完整有序数组 — 这会替换整个顺序，而非仅交换两条规则。记录返回的 version。转交给 flag-publish。

提醒用户，规则按从上到下的顺序评估，首个匹配项优先 — 列表中位置靠前的规则优先级更高。

Guardrails

  • 规则按顺序求值；位置很重要。 如果将宽泛规则（例如，没有条件的 50% 灰度发布）放在前面，它会先于下方更具体的规则匹配。用户添加或重新排序规则时，请指出这一点。
  • 规则 ID 是字符串 UUID（fr_...），不是位置编号。 调用编辑／删除／重新排序端点前，务必先从 rules 数组中解析出 UUID。
  • 重新排序需要完整数组。 如果重新排序请求中缺少某个规则 ID，就会导致错误或丢失规则。先获取当前的 rules 数组，在内存中重新排序，然后发送所有 ID。
  • 沿用草稿版本。 如果本次会话中先前的写入技能已提供版本号，请明确使用该版本，而不是 new。若为全新操作，则使用 new。
  • version=new 是规范的草稿模式。 不要先手动 POST /revisions——new 这一特殊值会以原子方式创建或复用草稿。
  • 这里只能删除 experiment-ref 规则。 若要编辑 experiment-ref 规则的定向条件或范围，请使用 flag-targeting。若要更改关联的实验，请提醒用户并使用 flag-experiment。

使用的端点

  • GET /api/v2/features/:id — 列出当前规则和功能标志状态
  • DELETE /api/v2/features/:id/revisions/new/rules/:ruleId — 删除规则
  • POST /api/v2/features/:id/revisions/new/rules/reorder（请求体：{ "ruleIds": ["<id>", ...] }）

移交

  • flag-targeting — 设置带有条件、已保存群组或规则级前置条件的强制启用／灰度发布规则
  • flag-experiment — experiment-ref 和内联实验规则
  • flag-schedule — 规则的定时激活时段
  • flag-ramp — 多阶段渐进式灰度发布计划
  • flag-monitoring — 受监控的灰度发布和安全灰度发布规则
  • flag-prerequisites — 功能级前置条件门控（非规则级）
  • flag-publish — 删除或重新排序后发布草稿

评论

支持 Markdown