First read ../comet-github/references/maintainer-contract.md. This Skill is responsible for preparing release assets; commit, push, tag, GitHub Release, and npm publishing still require separate authorization.
Determine Release Scope
- Read
package.json, lockfile metadata, the current top Changelog heading, the current branch,origin/master, the previous release tag, and the release/hotfix branch scope. - Determine whether the current branch already has a version higher than master. If so, append to or rewrite the same version; do not create a duplicate version.
- List candidate changes based on the actual release scope, retaining only content that users can perceive after upgrading from the previous version.
- Classify entries as Added, Changed, Fixed, Removed, or Security. Only user issues that already existed in the released baseline are classified as Fixed.
Write Release Content
Use a professional, neutral, user-facing English Changelog. Describe behavior and value, not the implementation process, bundle/cache details, generated filenames, Git object IDs, review follow-ups, or ordinary test refactors.
When the website release documentation is in scope, call comet-bilingual-docs, synchronize the confirmed user-visible semantics in the main repository with D:\Project\comet-website-docs , and keep the Chinese and English structures consistent.
Verify Release Readiness
Run checks based on release risk: for documentation-only changes, run affected tests and format checks; for Runtime, installation, routing, or release metadata changes, also run build, generated asset checks, package dry-run, and the full test suite. Run the available Mintlify commands for the website from its own repository, and mark timeouts as unverified.
Show the final version, included user-visible changes, verification results, and remaining unknowns. Use comet-safe-deliverywhen the user explicitly authorizes commit or push. This Skill is not responsible for npm publishing.