$npx -y skills add launchdarkly/ai-tooling --skill flag-and-release-changeDrive a pull request's change end to end: decide it's flag-worthy, create the guarding flag, wire the new code path behind it on the PR branch, and record an automated release so the change ships safely when the PR merges. A portable orchestrator that composes should-flag-change,
| 1 | # Flag & Release a PR Change |
| 2 | |
| 3 | You're using a skill that takes a pull request whose change should ship behind a feature flag and drives it end to end: decide it needs a flag, create the guarding flag, wire the new behavior behind it on the PR's branch, and record an **automated release** so the change ships safely once the PR merges. |
| 4 | |
| 5 | **The deploy is not the release.** The merge ships the control path — the flag is created OFF, so deployment always serves the pre-change behavior. The *release* is the flag operation the automated rollout performs afterward, governed by the environment's policy. Creating the flag OFF and recording the release are deliberately separate things. |
| 6 | |
| 7 | This skill is a **portable PR orchestrator**. It doesn't own the flag mechanics or the release mechanics — it composes three focused skills and adds the PR workflow (read the diff, work in a clone, push to the branch) plus the plan→implement sequencing: |
| 8 | |
| 9 | | Step | Owned by | This skill's role | |
| 10 | |------|----------|-------------------| |
| 11 | | Decide *whether* to flag | [`should-flag-change`](../should-flag-change/SKILL.md) (advisory, read-only) | Act on a "yes"; make the call yourself if it wasn't run | |
| 12 | | Create the flag + wire the code | [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md) | Invoke it against the change; don't re-teach flag creation or SDK patterns | |
| 13 | | Record the release | [`flag-release`](../flag-release/SKILL.md) | Hand off once the flag exists and the code is pushed; don't re-teach rollout mechanics | |
| 14 | |
| 15 | Don't duplicate any composed skill's mechanics here. This skill's only unique content is the **PR wrapper** (clone, three-dot diff, commit/push to the branch) and the **plan→implement** flow that stitches the three together. |
| 16 | |
| 17 | > **Automation note.** An orchestrating harness (e.g. a PR pipeline) can skip this skill and invoke the three composed skills directly — `should-flag-change` → `launchdarkly-flag-create` → `flag-release` — driving the git and sequencing itself. This skill is the portable, human-in-the-loop path for a developer working a PR by hand. |
| 18 | |
| 19 | You work in two phases — **plan**, then **implement** — and you check in with the user in between. **Never create or modify anything during the plan phase.** |
| 20 | |
| 21 | ## Prerequisites |
| 22 | |
| 23 | - The remotely hosted LaunchDarkly MCP server. |
| 24 | - A `git` CLI that can read and push to the PR's repository. |
| 25 | - The composed skills available: [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md) (flag creation + code wiring) and [`flag-release`](../flag-release/SKILL.md) (recording the rollout). [`should-flag-change`](../should-flag-change/SKILL.md) is used if the flag decision hasn't been made. |
| 26 | |
| 27 | MCP tools are used *via the composed skills* — `create-flag`/`get-flag` through flag-create, `match-release-policies`/`create-automated-rollout-config` through flag-release. This skill calls none directly. |
| 28 | |
| 29 | ## Working With the Pull Request |
| 30 | |
| 31 | Work from a clone so you can read the change and push the flag wiring back to its branch. Credentials are provided by the environment — never ask for, print, or store tokens. |
| 32 | |
| 33 | ```bash |
| 34 | git clone https://github.com/<owner>/<repo>.git && cd <repo> |
| 35 | git fetch origin pull/<pr_number>/head |
| 36 | git diff origin/HEAD...<head_sha> # three-dot: change relative to the PR's base |
| 37 | ``` |
| 38 | |
| 39 | The three-dot diff (`base...head`) shows exactly what the PR introduces. Read the changed files you need to understand the change and its risk. Stay in this clone through both phases — in implement you edit, commit, and push here. Full PR mechanics (clone, three-dot diff, commit/push to the branch): [references/pr-wiring.md](references/pr-wiring.md). |
| 40 | |
| 41 | ## Plan Phase |
| 42 | |
| 43 | **Create nothing in this phase.** |
| 44 | |
| 45 | 1. **Confirm it should be flagged.** If [`should-flag-change`](../should-flag-change/SKILL.md) already ran, act on its verdict. Otherwise apply the same judgment: favor a flag for user-facing or risky changes; skip config-only, dependency-bump, infra, test-only, or docs changes. If a flag clearly isn't warranted, say so and stop. |
| 46 | 2. **Understand the change and conventions.** Read the three-dot diff and changed files — what does it do, what's the blast radius? Then follow **flag-create's Step 1** to learn how this codebase already uses flags (SDK, wrapper, key constants, naming). Don't reinvent that ex |