Record a Flag's Automated Release

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.

This is the release step of the PR flag workflow, and it's deliberately atomic:

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 orchestrator.

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.

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.

Prerequisites