Pre Release Validation
aztfmod/terraform-provider-azurecaf
Run comprehensive pre-release checks: full test suite, E2E tests, coverage verification, CHANGELOG validation, and generated code freshness.
Cut a stable (or dev) release of the heygen CLI end to end: run RELEASE.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog…
Install Release CLI
$ npx skills add heygen-com/heygen-cli --skill release-cli -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install heygen-com/heygen-cli release-cli --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/release-cli .claude/skills/release-cli && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .claude/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cliType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add heygen-com/heygen-cli --skill release-cli -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install heygen-com/heygen-cli release-cli --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/release-cli .agents/skills/release-cli && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .agents/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add heygen-com/heygen-cli --skill release-cli -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install heygen-com/heygen-cli release-cli --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/release-cli .cursor/skills/release-cli && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .cursor/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/heygen-com/heygen-cli.git --path .agents/skills/release-cli--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add heygen-com/heygen-cli --skill release-cli -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install heygen-com/heygen-cli release-cli --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/release-cli .gemini/skills/release-cli && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .gemini/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install heygen-com/heygen-cli release-cliInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add heygen-com/heygen-cli --skill release-cli -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/release-cli .github/skills/release-cli && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .github/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add heygen-com/heygen-cli --skill release-cli -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install heygen-com/heygen-cli release-cli --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/heygen-com/heygen-cli.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/release-cli .opencode/skills/release-cli && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "release-cli" agent skill from https://github.com/heygen-com/heygen-cli/tree/main/.agents/skills/release-cli into .opencode/skills/release-cli/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release-cli", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
release-cli- GitHub stars
- 145
- Token cost
- ~1.9k tokens
- SKILL.md length
- 1,118 words
- Files
- 1
- Skills in repo
- 3
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
Cut a stable (or dev) release of the heygen CLI end to end: run RELEASE.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog…
- Works in 9 steps: Review commits since the last stable tag → Open PRs → CI on main → …
- The release workflow
- SKILL.md covers Stop points, Stable release, Dev release and Report
- Calls git, make and gh; reaches static.heygen.ai; needs HEYGEN_API_KEY
What it does
Release CLI is an agent skill from heygen-com/heygen-cli. Cut a stable (or dev) release of the heygen CLI end to end: run RELEASE.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog, trigger the release workflow, publish the notes, and verify the installer. Stops for the user at every decision. Use when asked to "cut a release", "ship a new version", or "release the CLI". Takes "stable" (the default) or "dev" as an optional argument.
Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Testing & QA, covering End-to-end testing, Feature launches and release readiness and Changelog and release notes. It works with HeyGen and Go. The repository describes itself as: Create AI videos from the terminal. Official CLI for the HeyGen video generation API. The licence is Apache-2.0.
When your agent uses it
- The release workflow
- Publish the notes
- Verify the installer
- Asked to cut a release
Example prompts
- “cut a release”
- “ship a new version”
- “release the CLI”
- “/release-cli”
Requirements
- A credential in HEYGEN_API_KEY
Workflow steps
9 steps, taken from the step headings in SKILL.md.
What it can do on your machine
Read from SKILL.md and the folder at commit 8cda12d. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
gitmakeghcurlbash
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
static.heygen.ai
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names these keys or tokens, usually read from environment variables:
HEYGEN_API_KEY
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Release CLI loads about 1.9k tokens when it runs. Until then it costs about 115 tokens; SKILL.md has 1,118 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from heygen-com/heygen-cli at commit 8cda12d, republished under its Apache-2.0 licence (© heygen-com). 1,118 words, ~1,857 tokens.
Download SKILL.mdSave it as
.claude/skills/release-cli/SKILL.md (or your agent's skills folder).- name
- release-cli
- description
- Cut a stable (or dev) release of the heygen CLI end to end: run RELEASE.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog, trigger the release workflow, publish the notes, and verify the installer. Stops for the user at every decision. Use when asked to "cut a release", "ship a new version", or "release the CLI". Takes "stable" (the default) or "dev" as an optional argument.
Release the heygen CLI
RELEASE.md is the source of truth for every step below; this skill runs it in order and adds where to stop and what tends to go wrong. When the two disagree, RELEASE.md wins, and fix this file.
Work from a fresh fetch, never from the local main checkout, which may be
behind. Set LAST_STABLE and RELEASE_COMMIT exactly as RELEASE.md's pre-release
checklist shows and keep them for the whole run: RELEASE_COMMIT is what every
step checks and what stop 4 releases. If a merge at step 2 moves origin/main,
fetch, set RELEASE_COMMIT again, and redo from step 1.
Stop points
Stop and ask the user before each of these, with what you found and a
recommendation. Never proceed on a guess. Each stop needs an explicit yes for
that specific action, in this session: the original request, a yes at an earlier
stop, or silence does not count. The one exception is stop 4, whose yes also
covers publishing its notes. If the action changes after the yes (a new head
after a rebase, a different commit on main, edited notes), ask again.
- Changing any open PR before the release (step 2): pushing to it (examples
for a sync PR, a rebase onto
main), approving it, or merging it. - Running E2E (step 5): it spends API credits and needs
HEYGEN_API_KEY. Ask which key to use; do not go looking for one. - The version (step 6), whenever step 4 found anything breaking or you are unsure between patch and minor.
- Triggering the release workflow. Show the version,
RELEASE_COMMIT, and the notes file step 9 will publish (a dev release has none), and record itsshasum -a 256. Dispatch with-f commit=<that SHA>so the workflow releases exactly that commit. A yes here also covers publishing that file at step 9 for this version. - Replacing the published release notes (step 9), unless re-running
shasum -a 256on the file then matches the hash recorded at the most recent stop 4 yes in this session for this version: show the final notes. A lost hash means asking. - Any recovery action (step 8) that changes the repository or a release: deleting a tag or release, dispatching again, or re-running a job. Say which job failed, what RELEASE.md prescribes, and what the action will change.
Reading, checking, building, and local edits need no approval. Anything else
visible outside this machine is a stop too, even if it is not listed above:
pushing any branch or tag, opening, closing, commenting on or labelling PRs or issues,
re-running or cancelling workflow runs, and changing variables, secrets, caches
or repository settings. Never bypass branch protection: no --admin, no direct
push to main.
Stable release
1. Review commits since the last stable tag
Follow RELEASE.md step 1. Flag anything that looks half-finished, and any PR that says it must not ship before something else is deployed: read the bodies of the merged PRs in the range for that.
2. Open PRs
Follow RELEASE.md step 2, then sort what you find:
- An open codegen sync PR (
codegen: resync gen/ from EF <sha>, opened by the sync bot) usually belongs in the release. If its CI fails onTestAllGeneratedCommandsHaveExamples, the fix is examples for the new commands incodegen/examples/<group>.yaml, regenerated withmake generate SPEC=<spec> STRICT=1. Use the spec from the EF commit the PR body names; first confirm that regenerating from it reproduces the bot'sgen/byte for byte, then add the examples, sogen/changes only by them. - Merging is serial.
mainrequires branches to be up to date, so merging one PR puts the next one behind. Rebase it, confirm its diff is unchanged, push, and get an approval on the new head. Never merge with--admin. - Merge with
gh pr merge <n> --squash --match-head-commit <sha>, pinned to the commit that was reviewed and green.
3. CI on main
Follow RELEASE.md step 3, after any merges from step 2.
Show full SKILL.md (459 more words)Show less
4. Command-surface regressions
Follow RELEASE.md step 4 and its Checking for Regressions
section, against RELEASE_COMMIT. Read every < line with the
table there. The deprecated check matches loosely: a hit whose help text only
mentions a deprecated value (for example an enum alias) is a false positive;
say so rather than putting it in the notes.
5. E2E smoke test (stop point 2)
With the user's key, run the e2e-cli-test skill. All phases must pass; a
Phase 3 WARN means the account lacks data, so check that the skipped commands'
lists really are empty before calling it fine.
6. Version (stop point 3 if anything is breaking)
Apply RELEASE.md step 6's rules. New command groups or significant new capability mean a minor bump; anything breaking from step 4 is at least a minor.
7. Changelog
Run the changelog-cli skill with the version. Then check every flag and command
it names against gen/: a flag that already existed in LAST_STABLE is not new.
Put step 4's breaking or deprecated findings at the top, as RELEASE.md says.
Save the notes to a file; you will publish them after the release.
8. Trigger (stop point 4)
Follow RELEASE.md's "Trigger the release", passing -f commit=<SHA> with the
commit the user approved at stop 4, and wait for the run to finish. Then fetch the
tag (git fetch origin tag <version>) and confirm git rev-parse <version>^{commit}
is that commit; if not, stop and tell the user before step 9. A re-dispatch under
stop 6 passes the same commit. If any
job fails, read If the release fails
to find the prescribed recovery, then stop (stop point 6) before acting on it.
Do not delete tags or releases by hand unless that section says to.
9. After the release
Follow RELEASE.md's "Post-release": confirm the release is published, replace its
body with the notes file from stop 4 (gh release edit <version> --notes-file <file>; stop point 5 unless its hash still matches) and read it back, and verify
the installer into a scratch directory rather than over the user's own heygen.
install.sh reads INSTALL_DIR, so it goes on bash, not curl: d=$(mktemp -d); curl -fsSL https://static.heygen.ai/cli/install.sh | INSTALL_DIR="$d" bash,
then run "$d/heygen" --version.
Dev release
Follow RELEASE.md's "How to Cut a Dev Release". There is no checklist, but
triggering it is stop point 4: confirm the user wants one, show the commit, and
dispatch with -f commit=<SHA> as for a stable release. If it fails, "If the release fails"
applies, except that dev releases have no publish-cdn job. Give the release
link to the user; sharing it with anyone else is theirs to do.
Report
End with: the version and tag commit, the release link, what merged first, the surface findings, the E2E result, and anything left open.
© heygen-com, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in .agents/skills/release-cli of heygen-com/heygen-cli.
Open the folder on GitHubat commit 8cda12d
Compare with similar skills
Release CLI next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Release CLI this skillheygen-com/heygen-cli | 145 | — | ~1.9k | Automated safety check: Pass | Apache-2.0 | |
| Pre Release Validationaztfmod/terraform-provider-azurecaf | 188 | — | ~367 | Automated safety check: Pass | MIT | |
| Go Redis Client Test Runnerredis/go-redis | 22k | — | ~786 | Automated safety check: Pass | BSD-2-Clause | |
| Security UpdatesSmilyOrg/photofield | 608 | — | ~808 | Automated safety check: Pass | MIT | |
| remindb Integration Testsradimsem/remindb | 129 | — | ~1.8k | Automated safety check: Pass | MIT | |
| E2E CoverageLanternOps/breeze | 131 | — | ~1.6k | Automated safety check: Pass | AGPL-3.0 |
Similar skills
- Official
Go Redis Client Test Runner
redis/go-redis
Explains how to run go-redis tests: the Docker Compose stack, make targets, focusing a single Ginkgo spec, the e2e suite and the version environment variables.
Security Updates
SmilyOrg/photofield
Check and apply security updates across the photofield project (api/Go, ui/npm, docs/npm, e2e/npm).
remindb Integration Tests
radimsem/remindb
Explains how to add an end-to-end test scenario to remindb, choosing between a direct API test and an MCP test and using the shared helpers and fixtures.
E2E Coverage
LanternOps/breeze
A skill your agent uses when running a broad manual/AI-driven end-to-end verification of Breeze RMM across many merged PRs or commits — "test everything since the last release", release-readiness…
- Official
Unblock Dependabot PR
kubernetes-sigs/cloud-provider-azure
Diagnose and unblock failed Dependabot pull requests in cloud-provider-azure by closing Kubernetes minor-version dependency bumps, classifying CI failures, syncing Go modules, retesting quota-flaked…
More from heygen-com/heygen-cli
Changelog CLI
heygen-com/heygen-cli
Generate a user-facing changelog for the next stable release.
E2E CLI Test
heygen-com/heygen-cli
End-to-end test of the heygen CLI against the live API. An agent skill from heygen-com/heygen-cli.
Related
Categories
Questions about Release CLI
What does Release CLI do?
Cut a stable (or dev) release of the heygen CLI end to end: run RELEASE.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog…. Release CLI is an agent skill from heygen-com/heygen-cli.md's pre-release checklist, land pending PRs, check the command surface, run E2E, pick the version, write the changelog, trigger the release workflow, publish the notes, and verify the installer.
When should I use Release CLI?
Release CLI fits situations like: the release workflow; publish the notes; verify the installer; asked to cut a release.
How do I install Release CLI in Claude Code?
Run `npx skills add heygen-com/heygen-cli --skill release-cli -a claude-code`. Or copy the skill folder (.agents/skills/release-cli in heygen-com/heygen-cli) into .claude/skills/release-cli in your project. Claude Code loads it when a task matches its description.
How do I install Release CLI in Codex?
Run `npx skills add heygen-com/heygen-cli --skill release-cli -a codex`. Or copy the skill folder (.agents/skills/release-cli in heygen-com/heygen-cli) into .agents/skills/release-cli in your project. Codex loads it when a task matches its description.
Can I use Release CLI in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add heygen-com/heygen-cli --skill release-cli -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-cli, .gemini/skills/release-cli, .github/skills/release-cli and .opencode/skills/release-cli in your project.
What does Release CLI need to run?
Going by SKILL.md and its folder, Release CLI needs the command-line tools its instructions call (git, make, gh, curl and bash) and credentials named HEYGEN_API_KEY. Our summary lists: A credential in HEYGEN_API_KEY.
Does Release CLI access the network?
SKILL.md names 1 domain. In commands or code: static.heygen.ai; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.
Is Release CLI safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Release CLI use?
Release CLI is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Release CLI use?
About 1.9k tokens (SKILL.md is roughly 7.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Release CLI?
Skills that share tags, products or a category with Release CLI: Pre Release Validation (aztfmod/terraform-provider-azurecaf, 188 stars), Go Redis Client Test Runner (redis/go-redis, 22k stars), Security Updates (SmilyOrg/photofield, 608 stars) and remindb Integration Tests (radimsem/remindb, 129 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Release CLI?
heygen-com (a GitHub organization) maintains it in heygen-com/heygen-cli, which has 145 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on October 8, 2026.
Source: heygen-com/heygen-cli on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.