Update to BillDog

{
  "description": "Run BillDog paywall A/B experiments and feature flags. Use when the user asks to test two paywalls against each other, start, pause, end or ship the winner of a BillDog experiment, read experiment results, or create, roll out, turn off or read a BillDog feature flag.",
  "included_files": [],
  "name": "billdog-experiments",
  "skill_md_contents": "---\nname: billdog-experiments\ndescription: Run BillDog paywall A/B experiments and feature flags. Use when the user asks to test two paywalls against each other, start, pause, end or ship the winner of a BillDog experiment, read experiment results, or create, roll out, turn off or read a BillDog feature flag.\n---\n\n# BillDog experiments and feature flags\n\nBoth are managed over the BillDog MCP server. Anything that changes what live\nusers see needs the user's go-ahead first; ask before each such call.\n\n## Paywall A/B experiments\n\nAn experiment shows a different paywall per variant at the same place in the\napp. The app code does not change: the SDK resolves the placement and BillDog\nassigns the variant.\n\n1. **Look first.** `list_placements`, `list_paywalls` and `list_experiments`.\n   Only one experiment can run on a paywall at a time.\n2. **Every variant's paywall must be published** before the experiment can\n   start. Build one with `list_templates` → `create_paywall_from_template` or\n   `design_paywall`, then `preview_paywall`, then `publish_paywall` (ask first).\n3. **Create** with `create_experiment`. It is saved as a draft and serves\n   nothing. The first variant is the control unless one says `is_control`.\n   Traffic splits evenly unless every variant gives `traffic_percent`, which must\n   add up to 100.\n4. **Start** with `start_experiment` (ask first). On a live project the start\n   waits for an owner or admin to approve it: when the result says\n   `awaiting_approval`, give the user its `approve_url`.\n5. **Read results** with `get_experiment_results`: users, conversions, revenue\n   per user, lift against the control, p-value and a verdict of `winner`,\n   `loser`, `keep_running` or `no_data`. A result is significant only at\n   p < 0.05 with 100+ users per arm. Do not call a winner on `keep_running`.\n6. **Finish** with `stop_experiment` (ask first):\n   - `pause` sends everyone back to the control and can be started again.\n   - `end` does the same and cannot be restarted.\n   - `ship_winner` with `winner_variant_id` serves the winner to everyone.\n\nResults read production unless you pass `sandbox: true`. An experiment tested\nonly on a development build will show `no_data` in production.\n\n## Feature flags\n\n1. **Look first.** `list_feature_flags`. Reuse an existing key rather than\n   creating a near-duplicate.\n2. **Create** with `create_feature_flag`. It is created off: every user gets\n   false. For a multivariate flag give two or more `variants` whose\n   `rollout_percentage` adds up to 100, each with an optional JSON payload.\n3. **Wire it into the app** by key. Look up the flag getter for the platform in\n   https://billdog.io/docs/feature-flags or with `get_sdk_integration_guide`;\n   do not guess a method name. Handle the \"off\" value as the default path.\n4. **Roll out** with `update_feature_flag` (ask first). Turning it on needs a\n   `rollout_percentage` above 0; 100 means everyone. Start small when the user\n   has not said otherwise. On a live project the change may wait for approval.\n5. **Check exposure** with `get_feature_flag_results`: users and evaluations per\n   value over the last 1–90 days, counted from the `$feature_flag_called` events\n   the SDKs send. Zero evaluations after a release usually means the app does\n   not read the flag yet, or reads a different key.\n\nAudience rules (release conditions) are edited in the BillDog dashboard, not over\nMCP. If the user asks for targeting, say so and link\nhttps://billdog.io/docs/feature-flags.\n"
}