flag-release

Name: flag-release
Author: launchdarkly

20stars6forks

How to install flag-release?

launchdarkly/ai-tooling/flag-release

$npx -y skills add launchdarkly/ai-tooling --skill flag-release

Installs into the current project.

Summary

Record an automated rollout for an existing LaunchDarkly flag that guards a pull request's change, so the change releases safely when the PR merges. Honors a stated release intent (release now / hold / notBefore / segment / prerequisite) and defers per-environment to the project'

Files · 1

View on GitHub

SKILL.md

1	# Record a Flag's Automated Release
2
3	You're using a skill that takes an existing feature flag (created OFF) that guards a pull request's change, and records an automated rollout so the change releases safely once the PR merges — no human toggling a flag. It defers per-environment to the team's release policies and honors any human-stated release intent.
4
5	This is the release step of the PR flag workflow, and it's deliberately atomic:
6
7	\| Step \| Owned by \|
8	\|------\|----------\|
9	\| Decide whether to flag \| [`should-flag-change`](../should-flag-change/SKILL.md) (advisory) \|
10	\| Create the flag + wire the code \| [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md) \|
11	\| Record the release \| this skill \|
12
13	By the time this skill runs, the flag exists (OFF) and the guarding code is wired and pushed. This skill only records the rollout — it never creates flags or edits code. It can be driven directly by an automation harness, or as the final step of the [`flag-and-release-change`](../flag-and-release-change/SKILL.md) orchestrator.
14
15	The deploy is not the release. The merge ships the control path (flag OFF); the release is the flag operation this rollout performs afterward, governed by the environment's policy.
16
17	> Honoring a hold is the one thing you must get right. There is no "hold" release type, and `policy` is NOT a manual gate. On merge, `policy` automatically performs the environment's release (immediate, progressive, or guarded) with no human promotion step — a guarded rollout still starts on its own the moment the PR merges. So recording a held environment as `policy` does not hold it; it releases it on merge, before any `notBefore` date. The only way to hold an environment is to omit it from the `environments` array entirely, which leaves the flag OFF there. If the user wants an environment held (or not released until a date), exclude it from the call and report it as held. When in doubt, omit.
18
19	## Prerequisites
20
21	- The remotely hosted LaunchDarkly MCP server.
22	- The guarding flag already exists in LaunchDarkly, created OFF, with the agreed key/tags.
23	- A pull-request reference (`repoFullName` + `prNumber`, or `prUrl`) so the rollout binds to the right merge.
24
25	MCP tools this skill uses:
26	- `create-automated-rollout-config` — record the rollout for the flag against the PR (the deliverable)
27	- `match-release-policies` — resolve which release policy governs each environment (call before proposing the plan)
28	- `list-release-policies` — see the project's release policies and the metrics they auto-attach
29	- `get-flag` — confirm the flag exists and is OFF before recording
30
31	Full release model — `simple` vs `policy`, precedence, previewing, prerequisites, metric adequacy: [references/auto-release.md](references/auto-release.md).
32
33	## Plan Phase
34
35	Record nothing in this phase.
36
37	1. Confirm the flag. `get-flag` to verify the guarding flag exists and is OFF. If it doesn't exist yet, stop — creation is [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md)'s job, and recording a rollout for a missing flag fails confusingly.
38	2. Pick the target environments. Use the environments named by the user or harness. Don't hardcode a set — a given change can't always release to every environment. If none are named, enumerate the project's real keys and confirm the set rather than assuming.
39	3. Preview each environment's policy. Call `match-release-policies` (by `flagKey` + `environmentKey`) to resolve, deterministically, what a `policy` release will do per environment — `winningReleaseMethod` (immediate / progressive / guarded / none). Don't reason about policy scope by hand. For a guarded winner, check the auto-attached metrics can actually compare this change (see the metric-adequacy note in [references/auto-release.md](references/auto-release.md)).
40	4. Capture the human's release intent. Ask (briefly, only if not already stated): release on merge, hold (recorded but not released yet), or wait until a `notBefore` date? A cohort/segment to target first? A prerequisite parent flag this must not precede? Intent sits above the policy in precedence and

People who liked this also viewed

6 picks

Type

flag-release

20stars6forks

View on GitHub

How to install flag-release?

launchdarkly/ai-tooling/flag-release

$npx -y skills add launchdarkly/ai-tooling --skill flag-release

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Record a Flag's Automated Release
2
3	You're using a skill that takes an existing feature flag (created OFF) that guards a pull request's change, and records an automated rollout so the change releases safely once the PR merges — no human toggling a flag. It defers per-environment to the team's release policies and honors any human-stated release intent.
4
5	This is the release step of the PR flag workflow, and it's deliberately atomic:
6
7	\| Step \| Owned by \|
8	\|------\|----------\|
9	\| Decide whether to flag \| [`should-flag-change`](../should-flag-change/SKILL.md) (advisory) \|
10	\| Create the flag + wire the code \| [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md) \|
11	\| Record the release \| this skill \|
12
13	By the time this skill runs, the flag exists (OFF) and the guarding code is wired and pushed. This skill only records the rollout — it never creates flags or edits code. It can be driven directly by an automation harness, or as the final step of the [`flag-and-release-change`](../flag-and-release-change/SKILL.md) orchestrator.
14
15	The deploy is not the release. The merge ships the control path (flag OFF); the release is the flag operation this rollout performs afterward, governed by the environment's policy.
16
17	> Honoring a hold is the one thing you must get right. There is no "hold" release type, and `policy` is NOT a manual gate. On merge, `policy` automatically performs the environment's release (immediate, progressive, or guarded) with no human promotion step — a guarded rollout still starts on its own the moment the PR merges. So recording a held environment as `policy` does not hold it; it releases it on merge, before any `notBefore` date. The only way to hold an environment is to omit it from the `environments` array entirely, which leaves the flag OFF there. If the user wants an environment held (or not released until a date), exclude it from the call and report it as held. When in doubt, omit.
18
19	## Prerequisites
20
21	- The remotely hosted LaunchDarkly MCP server.
22	- The guarding flag already exists in LaunchDarkly, created OFF, with the agreed key/tags.
23	- A pull-request reference (`repoFullName` + `prNumber`, or `prUrl`) so the rollout binds to the right merge.
24
25	MCP tools this skill uses:
26	- `create-automated-rollout-config` — record the rollout for the flag against the PR (the deliverable)
27	- `match-release-policies` — resolve which release policy governs each environment (call before proposing the plan)
28	- `list-release-policies` — see the project's release policies and the metrics they auto-attach
29	- `get-flag` — confirm the flag exists and is OFF before recording
30
31	Full release model — `simple` vs `policy`, precedence, previewing, prerequisites, metric adequacy: [references/auto-release.md](references/auto-release.md).
32
33	## Plan Phase
34
35	Record nothing in this phase.
36
37	1. Confirm the flag. `get-flag` to verify the guarding flag exists and is OFF. If it doesn't exist yet, stop — creation is [`launchdarkly-flag-create`](../launchdarkly-flag-create/SKILL.md)'s job, and recording a rollout for a missing flag fails confusingly.
38	2. Pick the target environments. Use the environments named by the user or harness. Don't hardcode a set — a given change can't always release to every environment. If none are named, enumerate the project's real keys and confirm the set rather than assuming.
39	3. Preview each environment's policy. Call `match-release-policies` (by `flagKey` + `environmentKey`) to resolve, deterministically, what a `policy` release will do per environment — `winningReleaseMethod` (immediate / progressive / guarded / none). Don't reason about policy scope by hand. For a guarded winner, check the auto-attached metrics can actually compare this change (see the metric-adequacy note in [references/auto-release.md](references/auto-release.md)).
40	4. Capture the human's release intent. Ask (briefly, only if not already stated): release on merge, hold (recorded but not released yet), or wait until a `notBefore` date? A cohort/segment to target first? A prerequisite parent flag this must not precede? Intent sits above the policy in precedence and

People who liked this also viewed

6 picks

Type