Release Universal Video Speed
Publish a complete, verified GitHub Release. Treat a request such as “release” as authorization for the version commit, tag, push, GitHub Release creation, and ZIP upload described below.
Establish the release
- Work only in
/Users/tian/Developer/universal-video-speed.
- Read the repository instructions, including referenced instruction files that exist.
- Inspect
git status --short, the current branch and upstream, remotes, recent commits, existing tags, gh auth status, and any existing Release for the target tag. Never reuse remembered remote state.
- Preserve unrelated work. If the worktree is not clean or the target tag/Release already exists, diagnose the collision and stop before mutating release state unless the user explicitly directs how to proceed.
- Read the current versions from
package.json, package-lock.json, and public/manifest.json. Require them to agree before calculating the next version.
- If the user supplied a version, use it after validating SemVer. Otherwise increment the patch component by one (
0.1.1 becomes 0.1.2). Use the plain version in files and v<version> for the Git tag and Release tag.
Prepare and verify
- Identify the previous release tag from the live repository and review the actual commits and diff from that tag through
HEAD.
- Generate a concise user-facing changelog from that range. Use the
git-tag-changelog skill when it is available. Describe shipped behavior, fixes, and other user-relevant changes; do not invent changes from commit titles alone when the diff clarifies them.
- Update the version consistently in:
package.jsonpackage-lock.jsonpublic/manifest.json
- Run
npm run check and require it to pass.
- Run
npm run zip. Require universal-video-speed.zip to exist, inspect its file list, and verify that the archive's manifest.json contains the target version.
- Compute the ZIP SHA-256 for the final report.
- Review the diff and
git status --short. Do not include the generated ZIP in the commit; it is a regenerated Release asset.
Do not continue to publishing if version synchronization, tests, build, archive inspection, or changelog review fails.
Commit and publish
- Commit only the three version files with message
chore: release <version>, following the repository's atomic-commit rules.
- Recheck status, create tag
v<version> at that commit, and push the current release branch plus the tag to its configured upstream.
- Write the changelog to a temporary Markdown file with real newlines. Use a clear heading and Markdown bullets. Never pass escaped multiline text such as literal
\\n through --notes.
- Create a non-draft, non-prerelease GitHub Release titled
v<version> using the Markdown file via --notes-file, and attach universal-video-speed.zip.
- Re-read the live Release with
gh release view. Verify all of the following:
- the tag and title are correct;
isDraft and isPrerelease are false;- the rendered body has real headings, blank lines, and bullets rather than literal escape sequences;
universal-video-speed.zip is present as an asset.
- Confirm the final local worktree state. Leave the generated ZIP untracked when that matches the repository's established behavior.
If a push, tag, or GitHub operation fails, inspect the live state before retrying so that a retry cannot create conflicting release objects. Never delete or overwrite a tag or published Release without explicit user approval. Never print credentials or edit environment files.
Report completion
Report the released version, commit and tag, checks performed, ZIP filename and SHA-256, and clickable GitHub Release URL. Clearly identify anything that could not be verified; do not describe a local version bump as a completed release.
1---2name: release-universal-video-speed3description: Release the Universal Video Speed browser extension from /Users/tian/Developer/universal-video-speed. Use when the user asks to release, publish a release, create a GitHub Release, or ship a new version of this repository. By default increment the current version by 0.0.1, validate the project, build the ZIP, generate a changelog, commit and tag the version, push it, create the GitHub Release, upload the ZIP, and verify the published result.4---56# Release Universal Video Speed78Publish a complete, verified GitHub Release. Treat a request such as “release” as authorization for the version commit, tag, push, GitHub Release creation, and ZIP upload described below.910## Establish the release11121. Work only in `/Users/tian/Developer/universal-video-speed`.132. Read the repository instructions, including referenced instruction files that exist.143. Inspect `git status --short`, the current branch and upstream, remotes, recent commits, existing tags, `gh auth status`, and any existing Release for the target tag. Never reuse remembered remote state.154. Preserve unrelated work. If the worktree is not clean or the target tag/Release already exists, diagnose the collision and stop before mutating release state unless the user explicitly directs how to proceed.165. Read the current versions from `package.json`, `package-lock.json`, and `public/manifest.json`. Require them to agree before calculating the next version.176. If the user supplied a version, use it after validating SemVer. Otherwise increment the patch component by one (`0.1.1` becomes `0.1.2`). Use the plain version in files and `v<version>` for the Git tag and Release tag.1819## Prepare and verify20211. Identify the previous release tag from the live repository and review the actual commits and diff from that tag through `HEAD`.222. Generate a concise user-facing changelog from that range. Use the `git-tag-changelog` skill when it is available. Describe shipped behavior, fixes, and other user-relevant changes; do not invent changes from commit titles alone when the diff clarifies them.233. Update the version consistently in:24 - `package.json`25 - `package-lock.json`26 - `public/manifest.json`274. Run `npm run check` and require it to pass.285. Run `npm run zip`. Require `universal-video-speed.zip` to exist, inspect its file list, and verify that the archive's `manifest.json` contains the target version.296. Compute the ZIP SHA-256 for the final report.307. Review the diff and `git status --short`. Do not include the generated ZIP in the commit; it is a regenerated Release asset.3132Do not continue to publishing if version synchronization, tests, build, archive inspection, or changelog review fails.3334## Commit and publish35361. Commit only the three version files with message `chore: release <version>`, following the repository's atomic-commit rules.372. Recheck status, create tag `v<version>` at that commit, and push the current release branch plus the tag to its configured upstream.383. Write the changelog to a temporary Markdown file with real newlines. Use a clear heading and Markdown bullets. Never pass escaped multiline text such as literal `\\n` through `--notes`.394. Create a non-draft, non-prerelease GitHub Release titled `v<version>` using the Markdown file via `--notes-file`, and attach `universal-video-speed.zip`.405. Re-read the live Release with `gh release view`. Verify all of the following:41 - the tag and title are correct;42 - `isDraft` and `isPrerelease` are false;43 - the rendered body has real headings, blank lines, and bullets rather than literal escape sequences;44 - `universal-video-speed.zip` is present as an asset.456. Confirm the final local worktree state. Leave the generated ZIP untracked when that matches the repository's established behavior.4647If a push, tag, or GitHub operation fails, inspect the live state before retrying so that a retry cannot create conflicting release objects. Never delete or overwrite a tag or published Release without explicit user approval. Never print credentials or edit environment files.4849## Report completion5051Report the released version, commit and tag, checks performed, ZIP filename and SHA-256, and clickable GitHub Release URL. Clearly identify anything that could not be verified; do not describe a local version bump as a completed release.
debugtheworldbot