// For command `/tinymist-dev:release version`, prepare a tinymist release with an inspect-first workflow that reuses the repository's existing release scripts and stops before external side effects until the maintainer explicitly approves them.
| name | tinymist-release |
| description | For command `/tinymist-dev:release version`, prepare a tinymist release with an inspect-first workflow that reuses the repository's existing release scripts and stops before external side effects until the maintainer explicitly approves them. |
| license | Apache-2.0 |
| compatibility | Requires Node.js, rg (ripgrep), git, a POSIX sh, the repository checkout, and optionally gh for GitHub handoff commands. |
| metadata | {"author":"tinymist","version":"1.0"} |
Prepare a tinymist release in three phases:
This workflow is intentionally conservative. It should help a maintainer inspect release readiness, prepare reviewable local edits, and then stop before any command that would mutate GitHub, publish crates, or push tags until the maintainer explicitly approves that exact action.
The user should provide a target version such as v0.14.12-rc1, 0.14.12, or 0.14.11.
If the version is missing, ask for the exact version before doing anything else.
Announce the release target and infer the release type
vrelease-candidate when it ends with -rcNnightly when the patch number is oddstable when the patch number is even and there is no -rcNdocs/tinymist/release-instruction.typRun the repo-native release helper
node scripts/release-preflight.mjs <target-version> --json
Use the JSON output as the primary machine-readable source for:
expectedBranch, branch.current, branch.ready)Cargo.toml and package.json fileseditors/neovim/bootstrap.sh and editors/neovim/samples/lazyvim-dev/Dockerfilenode scripts/link-docs.mjs for crates/typlite/README.mdRead the release policy and the relevant automation entry points
Always read:
docs/tinymist/release-instruction.typscripts/release.mjsscripts/draft-release.mjsWhen the target is nightly, also read:
.github/workflows/release-nightly.ymlscripts/nightly-utils.mjsWhen the target is a regular or release-candidate build, prefer the repository's existing release path:
scripts/release.mjs.github/workflows/release-asset-crate.yml.github/workflows/auto-tag.yml.github/workflows/announce.ymlReport inspection results before making edits
Summarize:
bump-version-<version> branch and whether the current branch matches it and is pushed to remote.editors/vscode/CHANGELOG.md, which are omitted for maintainer review, or why the helper could not compute that summaryLocal preparation is allowed without a separate approval prompt
Reversible, reviewable checkout-local work is allowed, for example:
editors/vscode/CHANGELOG.mdnode scripts/link-docs.mjsbuild: bump version to <version>After local preparation:
node scripts/release-preflight.mjs <target-version> --jsonreadiness.ready: true, explicitly tell the maintainer that the local checkpoint is ready and that yarn release <version> is the next external commandExternal actions require explicit maintainer approval immediately before execution
Never run any of the following until the maintainer explicitly approves that exact action:
yarn release <target-version>yarn draft-release v<release-notes-version>cargo publish ...gh workflow run ...gh pr create ...gh release ...git tag ...git push --tagWhen you reach that boundary:
Fall back gracefully when automation cannot continue
If credentials, tools, or permissions are missing:
node scripts/release-preflight.mjs <target-version> --jsonscripts/release.mjs and scripts/draft-release.mjs as external-action entry points, not inspect-mode helpersyarn release <version> after the local checkpoint commitUse when authoring or validating Typst documents from canonical grammar examples, especially when you need compile, HTML, or SVG-based validation workflows.
GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line.