quarto-dev Make Release
Command-only helper that follows an existing release checklist. This skill does not restate the release steps; the checklists below are the source of truth. Read the applicable checklist, verify the current state, and request confirmation at the required points.
1. Determine which checklist applies
There are three release types, each with its own checklist. Branch-existence alone doesn't distinguish all three — a routine prerelease and a first-stable-of-cycle release can both start with no v1.x branch yet — so first establish intent, then verify with git where that disambiguates:
- Routine dev prerelease off
main(no version bump beyond the prerelease counter, no new branch) → drivedev-docs/checklist-make-a-new-quarto-prerelease.md - First stable release of a new major.minor cycle (cuts a new
v1.xbranch) → drivedev-docs/checklist-make-a-new-quarto-release.md - Patch release on an already-cut stable branch (e.g. another
v1.9.x) → drivedev-docs/checklist-make-a-new-stable-quarto-release.md
If the user's request doesn't make the type unambiguous, ask. For a stable release, use the repository state to determine whether it is the first release in the cycle or a patch release:
git ls-remote --heads origin v1.x # substitute the target major.minor, e.g. v1.10
An absent branch indicates the first stable release of the cycle. An existing branch indicates a patch release.
Backporting an individual merged PR to a stable branch is outside this skill's scope. Follow
dev-docs/checklist-backport-a-pr.md directly instead.
Always confirm the selected checklist before starting, even when the release type appears
obvious. State it plainly, e.g. "I will follow this checklist:
dev-docs/checklist-make-a-new-quarto-release.md", and wait for the user's confirmation.
2. Drive the checklist top to bottom, verifying real state, narrating as you go
Read the matching checklist and follow it in order. Before each step, not only the confirmation gates in section 3, state in one line what you are about to do and why. Allow the user to review each step before proceeding to the next.
At each step, use git or gh to verify that the expected action occurred. For example,
confirm that a branch or tag exists, a workflow run succeeded (gh run view <id>), a release
has the expected flags, or a version field has the expected value. A step is complete only
after this verification.
3. Hard-confirm gates (stop and get explicit human OK before running)
Do not perform these actions without confirmation. State the exact action and target repository, then wait for explicit approval:
- Pushing the new stable branch (
git push origin v1.x) - Pushing version-bump / release-checklist commits to
main - Any
workflow_dispatchcarrying a publish flag (e.g.publish-release=true, chocolatey publish checkbox, Cloudsmithdry-run=false) - Editing a live GitHub release's flags (pre-release / "Set as latest release")
- Pushing the release tag
- Production package-registry publishes: pypi (
Production Release), chocolatey, Cloudsmith manual publish
Dry-runs and read-only verification don't need a gate — run them freely.
4. Cross-repo flow
Three repos are involved, with real ordering dependencies:
quarto-dev/quarto-cli— the release build and tagquarto-dev/quarto-web— quarto.org site, downloads, highlights, announcementquarto-dev/quarto-cli-pypi— pypi publish
Ordering matters: e.g. quarto-cli's release build must fully publish before quarto-web's update-downloads.yml will pick it up, and chocolatey waits on the quarto.org download page updating. State which repo each step targets. Use gh --repo <owner>/<name> ... so verification works even without a local clone of every repo.
No local quarto-web clone: if a step needs local content edits to quarto-web (e.g. the docs/prerelease/<version>/ highlights .qmd files, or _quarto.yml edits) and no local quarto-web clone is present, stop and ask the user for the clone path or to make the edit themselves. Do not attempt the edit through the GitHub API and do not silently skip the step.
Release announcement: the matching checklist step already documents where and how it's published. Follow that step rather than restating the mechanism yourself.
5. When the checklist doesn't match reality
If the state described by a step does not match the current state (for example, a stale path, incorrect ordering, completed step, or renamed workflow), report the discrepancy and ask the user how to proceed. Do not work around it silently or edit the checklist during the release; suggest a follow-up documentation PR instead.
6. Non-blocking gaps found along the way
If you spot a non-blocking gap during the release (e.g. a CI automation that only covers one branch, a doc-archival gap), don't try to fix it inline. Tell the user to track it in whatever task tracker they/their project use, and continue the release.