Prepare an Rslint npm Release PR

Prepare a reviewable version and metadata PR, following the shape of PR #2080. Use the current pnpm sync:version-info command introduced in #2078; #2080 used the older sync:rule-releases command and data filename.

Establish the release state

Follow the repository's AGENTS.md for branches and local verification. Read these current sources before choosing commands or file scope:

• scripts/version.mjs and the root package.json: version calculation and package selection.
• scripts/sync-version-info/: rule history and the pinned TypeScript commit/release mapping.
• Sync release information: the manual preparation sequence.

Resolve the intended stable version or major, minor, or patch bump from the request. Ask for the target if it cannot be inferred. The version script bumps from the highest base version in its selected manifests, so inspect those versions before predicting the result.

Fetch the main branch and release tags. Determine the previous stable vX.Y.Z tag, excluding prerelease tags, and check for an existing branch or PR for the requested release. Start new preparation from current origin/main on a branch such as chore/release-<version>; resume an existing release branch instead of bumping again. If the target is already released, report that state rather than silently choosing another version.

Update versions and metadata

Run commands from the repository root. For an agreed patch release:

pnpm run version patch
pnpm sync:version-info

Use the requested bump type in place of patch. If the intended version bump is already present, skip the first command and review or refresh the metadata. version is not idempotent: running it again advances the version again. A failed metadata lookup is a reason to retry the sync after resolving the failure, not to repeat the bump.

The version script owns the unified package selection: the root manifest, packages/*/package.json except packages/tsgo/package.json, and npm/rslint/*/package.json. This includes private workspace packages. Derive the current selection from the script rather than hardcoding #2080's package count. Preserve workspace: dependency ranges. The independent tsgo packages and Rust crate versions are outside this workflow.

The sync writes website/releases.json for the new stable version. It reads the indexed typescript-go gitlink and queries upstream TypeScript tags. Record the compiler already pinned for this release; preparing a release does not imply a compiler upgrade. Stage any separately authorized submodule revision change before syncing. The sync can read the pin without initializing the submodule.

The default sync skips when the package version equals the latest stable tag. An unexpected skip during new release preparation is not successful generation: check the package version and fetched tags. Use incremental sync for normal preparation; full rebuilds historical rule records and belongs to a separate history repair request.

Review the generated diff

Check these invariants before committing:

• Every selected manifest has the intended version. Ordinary version changes affect only its version field; investigate unrelated dependency, script, formatting, or lockfile changes.
• The new release appears once in website/releases.json. Earlier records and compiler bindings are unchanged, and no main entry or compiler backfill is introduced.
• New rule IDs are unique and sorted. The list equals the registered rules added since the previous stable release, excluding IDs recorded in earlier releases. Cross-check implementations and the relevant core/plugin all.go aggregators for both missing and spurious entries; a helper or fixture directory is not a rule. A release with no new rules is valid.
• typescript.commit equals the indexed gitlink. typescript.releaseVersion is an exact upstream tag match, including peeled annotated tags, or null when no tag matches. Do not substitute the latest TypeScript release or a version reported by upstream source files.
• A second pnpm sync:version-info run leaves the generated file unchanged.

For version and metadata-only changes, follow #2080's focused verification: run pnpm run check-spell with every changed text path explicitly, run pnpm run format:check, and run git diff --check. Apply AGENTS.md's affected package rules if source or build behavior also changes. The generic build/test suggestions printed by version.mjs are not a request for full local suites.

Deliver the preparation PR

Commit the version manifests and release metadata together, with a message and PR title such as chore: release npm <version>. Push the release branch and open a PR targeting main, or update the existing release PR. Include the version transition, actual manifest count, new rule count, TypeScript binding, and the verification commands/results. Keep temporary verification artifacts outside the commit.

This workflow ends at the preparation PR. Actual publication is a separate manual release.yml workflow; merging a version PR does not publish npm packages. Its npm-only selection is to_release=npm. Draft release notes, when requested, use the separate create-draft-release-notes skill.