release-package

Prepare a package release PR

Read RELEASING.md first. The deliverable is an open pull request against microsoft/coreai-design-system:main, not a local plan. Do not merge it, create tags/releases, publish locally, or change repository variables, environment protections, or credentials. Once enabled, Actions publishes the version-changing main commit after CI succeeds and tags it vVERSION.

1. Check the remote, worktree, GitHub account, and existing release PRs. Follow the github-accounts skill before using gh. Use arniebradfo for this repository. Preserve unrelated edits; do not include them in the release. Start from current origin/main on release/vVERSION. If unrelated work prevents a clean release, use a separate worktree or ask the user rather than resetting their work.
2. Read the manifest, root lockfile, changelog, publishing workflow, Git tags, and public npm version metadata. Confirm the requested version; if unspecified, propose the appropriate semver increment and ask before bumping. The first public release is 0.12.0, not the manifest's historical 0.11.1 plus a patch.
3. Establish the last released source baseline. Review every merged PR and commit since it, including first-parent merges and package source differences. Reconcile user-visible changes with [Unreleased] and give explicit consumer migrations for breaking changes. No tags exist before the first public release: document that limitation and review the available history rather than inventing a baseline/tag. Historical 0.11.2 includes provider circular-dependency fix 567dc9a, merged in PR #9; its exact privately published source baseline is unconfirmed.
4. Run npm version VERSION --workspace packages/react-components --no-git-tag-version. Update the package manifest and root lockfile together. Roll [Unreleased] into [VERSION] - YYYY-MM-DD, add a fresh [Unreleased], and update heading anchors. For 0.12.0, retain the first-public-npm-release statement and historical fixes. Do not add comparison links to tags that do not exist yet.
5. Run the release guide's local checks with existing dependencies. Install/restore dependencies only if needed after a dependency change or missing-dependency error. Verify an actual tarball; never ship font binaries or rely on publishConfig to rewrite exports. Do not claim checks passed unless they ran successfully.
6. Check release readiness without reading secret values: the repository's NPM_PUBLISH_ENABLED variable, main review/CI rules, npm-production main-only environment, presence of the NPM_TOKEN secret, and Actions tag/release permissions. Missing publishing setup must be reported in the PR; never enable it yourself. Distinguish a confirmed npm package 404 from an authentication/network failure.
7. Commit only release-scoped changes, including the required Copilot co-author trailer, push the release branch, and use gh pr create targeting main. Follow the create-pr skill. Include version, baseline evidence/limitations, changelog reconciliation, checks and results, and publishing readiness blockers. Explain that merging authorizes automatic publication when enabled. Never use --admin or bypass checks. Report the PR URL and stop; the user reviews/merges.

For a cold-start test, perform this same PR-opening workflow. Do not stop after describing what you would do. An incorrect test PR can be closed without publishing. If blocked, report the exact blocker rather than claiming the release is ready.