القائمة
Prepare and verify an ARS package release, including semver choice, migration notes, release gate, npm dist-tag guidance, and tag/publish safety checks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run a single-episode coherence checklist after Studio review edits and before prepare/publish; diagnose or patch thesis drift, step seams, stale arguments, visual rhythm, and publish readiness.
Apply Studio intents back into the episode source and validate the result.
Generate 3 YouTube metadata candidates (title/description/tags) grounded in episode context, let the user pick one, then mark the artifact ready.
Usage guide for generating MiniMax TTS audio and subtitles for an episode.
Validate repo bootstrap readiness, ARS config, providers, and environment readiness with npx ars doctor.
Create a new episode scaffold for a series with npx ars episode create.
| name | ars:release |
| description | Prepare and verify an ARS package release, including semver choice, migration notes, release gate, npm dist-tag guidance, and tag/publish safety checks. |
| argument-hint | [patch|minor|major|prerelease|0.x.y] |
| model | claude-sonnet-4-6 |
| effort | medium |
Use this skill when the user wants to cut, prepare, verify, or reason about an ARS release.
Read docs/release-process.md first. It defines the public version policy, release-sensitive compatibility surface, release gate, and npm dist-tag rules.
Read CONTRIBUTING.md when preparing a release from merged PRs or checking whether a contributor change included the expected verification and migration notes.
Read AGENTS.md when merged changes were agent-authored. Agent PRs should include compatibility, migration, verification, Studio notes, and known-risk evidence.
Also inspect:
package.jsonpackage-lock.jsonplugin/.claude-plugin/plugin.jsongit status --short --branchgit tag --list --sort=-v:refname0.1.x.0.1.0.0.x, breaking workflow or generated-repo changes bump the minor version.next for beta/dogfood prereleases.latest only when the README recommends npm as the primary install path.Refuse to release from a dirty tree unless the dirty files are exactly the release edits being prepared and the user asked you to make them.
Identify the latest tag. If no tag exists, compare against the initial public baseline or the user's chosen baseline.
Review commits since the baseline and classify the bump:
patch: fixes, docs, skill wording, package surface corrections with no migration.minor: new CLI/Studio/card/generated-repo capability, or any 0.x breaking workflow contract change.major: post-1.0 breaking changes only.prerelease: beta or release candidate, usually published with --tag next.Check whether ars update needs a migration:
.ars/config.json, workstate, Studio intent, or .ars/.ars-version.json shape changedFor merged contributor PRs, confirm the PR met CONTRIBUTING.md expectations or document the maintainer follow-up:
AGENTS.mdUpdate versions consistently:
package.jsonpackage-lock.jsonplugin/.claude-plugin/plugin.jsonDraft release notes with:
Run the release gate:
npm run lint
npm run build:studio
npm test
npx ars episode validate template/ep-demo
npm pack --dry-run
Inspect npm pack --dry-run output. Confirm the tarball includes CLI/plugin/template/runtime files and excludes repo-local artifacts such as .ars/, .codex/, .cache/, output/, and local tests.
Ask for explicit confirmation before npm publish, git tag, or pushing tags. These are public release actions.
Use exact version when the user already chose it:
npm version 0.1.0 --no-git-tag-version
Use prerelease for beta candidates:
npm version prerelease --preid beta --no-git-tag-version
Publish channels:
npm publish --tag next
npm publish --tag latest
Do not publish automatically. Show the command and wait for explicit user confirmation.
Report: