pi-commandcode-release

name	pi-commandcode-release
description	Use when preparing, validating, publishing, or documenting a pi-commandcode-provider release/deployment, including version bumps, changelog entries, npm publish, GitHub releases, tags, and release follow-up comments.

pi-commandcode-provider Release Skill

Use this skill for every pi-commandcode-provider release.

Core rule

Keep release work explicit and auditable. Do not publish, tag, push, or merge unless the user explicitly asks in the current conversation.

Required release order

Preferred order for stable releases:

1. Create a release branch with the version/changelog changes.
2. Open a release PR.
3. Wait for CI to pass.
4. Create a local annotated git tag for the release commit while the PR is still open.
5. Publish the npm package from the release branch/commit.
6. Create the GitHub Release from the release tag.
7. Verify npm and the GitHub Release.
8. Merge the release PR into main.
9. Move/recreate the git tag on the merge commit if the project requires tags to point at main, then force-update only after explicit user approval. Prefer documenting the tag target instead of force-updating.
10. Comment on included PRs/issues after the package and GitHub Release are live.

If branch protection or repository policy requires tags to point at main, ask before changing the order or force-updating a tag.

Version and changelog

• Increase semver appropriately; for a patch release use npm version patch --no-git-tag-version.
• Update CHANGELOG.md in the same PR.
• Add a dated section for the new version.
• Include user-facing changes and dependency/security fixes.
• Include a Contributors subsection for every release that had external reports, PRs, testing, or issue validation.

Example changelog structure:

## 0.4.1 - 2026-06-16

- Fix provider registration for newer pi versions.
- Resolve npm audit findings.

### Contributors

- @user-a — fixed provider registration.
- @user-b — reported/validated retry behavior.

Validation

Run the checks from RELEASE.md. For this repo, at minimum:

npm test
npm run typecheck
npm run format:check
npm audit --audit-level=moderate
npm pack --dry-run
git diff --check

If local pi auth makes test:pi-local use the wrong provider state, rerun the suite with a harmless mock Command Code API key in the environment instead of real auth.

If a live-auth test is needed and the user explicitly approves using local/server auth, use the repo helper if present. Never print API keys.

GitHub Release notes

Always include:

• Summary of changes.
• Contributors section with GitHub handles.
• Validation section.
• Links to relevant PRs/issues.

npm publish

Publish manually/local from the checked-out release commit:

npm publish --tag latest --access public

Verify:

npm view pi-commandcode-provider version dist-tags --json
npm view pi-commandcode-provider@<version> version --json

If npm auth fails, stop and ask the user to log in; do not read token files.

Follow-up comments

After npm and GitHub Release are live, comment only on PRs/issues actually included in the release:

Shipped in `pi-commandcode-provider@<version>` / GitHub release `v<version>`.