Patrick WozniakandGitHub
0f6fc17816
Add a release/deployment skill and record contributors in the 0.4.1 changelog.
103 lines
3.2 KiB
Markdown
103 lines
3.2 KiB
Markdown
---
|
|
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:
|
|
|
|
```md
|
|
## 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:
|
|
|
|
```sh
|
|
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:
|
|
|
|
```sh
|
|
npm publish --tag latest --access public
|
|
```
|
|
|
|
Verify:
|
|
|
|
```sh
|
|
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:
|
|
|
|
```txt
|
|
Shipped in `pi-commandcode-provider@<version>` / GitHub release `v<version>`.
|
|
```
|