From pubm-plugin
Sets up pubm in JS/TS and Rust projects: analyzes structure, installs pubm, configures registries (npm, jsr, crates.io, private), and integrates CI workflows.
npx claudepluginhub syi0808/pubm --plugin pubm-pluginThis skill is limited to using the following tools:
Set up pubm in the current project.
Scaffolds pubm plugins by gathering name, hooks like beforePublish/afterRelease, and form (inline config, single file, or full package) with TypeScript templates.
Sets up CI/CD pipelines for publishing Python packages to PyPI using GitHub Actions or GitLab CI. Includes testing, linting with ruff/ty/pytest, and automated releases on tags.
Configures release-it for automated releases: version bumping, changelog generation, npm publishing, GitHub/GitLab releases, git tagging, plugins, and CI/CD pipelines. Triggers on .release-it configs and CLI usage.
Share bugs, ideas, or general feedback.
Set up pubm in the current project.
pubm can publish to npm, jsr, crates.io, and private registries in one run. It supports JavaScript/TypeScript and Rust projects with automatic detection.
Start by mapping out the project layout so the rest of the setup matches the repo.
Scan the following:
package.json, jsr.json, deno.json, deno.jsonc, Cargo.toml to detect the ecosystem (JS, Rust, or both)pnpm-workspace.yaml, package.json workspaces, Cargo.toml [workspace] to detect monorepo structurebun.lockb, pnpm-lock.yaml, package-lock.json, yarn.lock) to determine install commandspubm.config.ts / .js / .mjs to check if pubm is already configured.github/workflows/, .gitlab-ci.yml, etc. for existing CI setupplugin.jsondist/, build/, bin/ to understand build outputspackage.json, Makefile, and similar filesPresent findings to the user:
Use this analysis to decide which registries to suggest, whether a config file is needed, and whether custom plugins are required.
Check package.json devDependencies for pubm. If it is missing, ask whether to install:
npm install -D pubm or pnpm add -D pubm (detect package manager from lock files)Run pubm inspect packages to show the detected ecosystem, packages, and target registries.
pubm auto-detects:
Show the output and ask:
If the user wants changes (add/remove registries, add/remove packages), note them for config generation in Step 6.
Show the available official plugins and ask which, if any, to use:
| Plugin | Package | Description |
|---|---|---|
externalVersionSync() | @pubm/plugin-external-version-sync | Sync version to non-manifest files (plugin.json, README badges, etc.) |
brewCore() | @pubm/plugin-brew | Open PR to homebrew-core on release |
brewTap() | @pubm/plugin-brew | Update formula in a custom Homebrew tap repo on release |
If externalVersionSync selected:
npm install -D @pubm/plugin-external-version-sync (or pnpm/bun equivalent)pubm sync --discover to scan for version references outside manifest filesversion callback for configIf brewCore selected:
npm install -D @pubm/plugin-brewFormula/<package-name>.rb)packageName filter (for monorepo per-package releases)If brewTap selected:
npm install -D @pubm/plugin-brewFormula/<package-name>.rb)user/homebrew-tap)packageName filterBased on the project analysis in Step 1, if the user needs something that pubm's built-in features or official plugins do not cover, guide them to create a custom plugin.
Signals that a custom plugin is needed:
When a custom plugin is needed:
/create-plugin skill to scaffold the pluginAsk the user:
Store the answers for subsequent steps.
If any package targets jsr, check package.json devDependencies for jsr. If not installed, install it using the project's package manager.
Only create pubm.config.ts when needed. Create one when:
When config is NOT needed: Tell the user that pubm's auto-detection covers the setup and no config file is required.
When creating config:
Use defineConfig() from pubm for type safety. Use packages array with per-package path and registries. Read references/config-examples.md for templates.
Example with plugins:
import { defineConfig } from 'pubm'
import { externalVersionSync } from '@pubm/plugin-external-version-sync'
export default defineConfig({
packages: [
{ path: 'packages/core', registries: ['npm', 'jsr'] },
{ path: 'packages/cli', registries: ['npm'] },
],
plugins: [
externalVersionSync({
targets: [
{ file: 'plugins/.claude-plugin/plugin.json', jsonPath: 'version' },
],
}),
],
})
For each registry a package targets, check whether its required config file exists. If not, generate it from whichever source file is available.
Generation rules:
| Target registry | Required file | Source file | Reference |
|---|---|---|---|
jsr | jsr.json | package.json or deno.json/deno.jsonc | references/registry-jsr.md |
npm or custom URL | package.json | jsr.json or deno.json/deno.jsonc | references/registry-npm.md |
crates | Cargo.toml | package.json | references/registry-crates.md |
Read the corresponding registry reference file for the template and constraints.
Behavior:
v* tag to trigger publishreferences/ci-templates.md for the appropriate template. Create .github/workflows/publish.yml.GITHUB_TOKEN for GitHub Releases (automatically available as secrets.GITHUB_TOKEN; no manual setup needed)NODE_AUTH_TOKEN for npm (create at npmjs.com > Access Tokens > Automation)JSR_TOKEN for jsr (create at jsr.io/account/tokens/create)CARGO_REGISTRY_TOKEN for crates.io (create at crates.io > Account Settings > API Tokens)Run the CLI to set up the changesets workflow:
pubm init
This creates:
.github/workflows/changeset-check.yml - PR changeset detection with bot comments
After running, tell the user:pubm changesets add)no-changeset label skips the check for docs/CI-only changesThen write the following section to the project's CLAUDE.md (append if file exists, create if not):
## Changesets Workflow
This project uses pubm changesets to track changes and automate versioning.
### Rules
- Every PR that changes runtime code must include a changeset file
- Add a changeset: `pubm changesets add`
- Changeset identifiers use package path (e.g., `packages/core`), not registry name. Package names are also accepted and auto-resolved to paths.
- Changeset summaries should be written from the user's perspective
- PRs with `no-changeset` label skip the changeset check (use for docs, CI config, etc.)
### Workflow
1. Make changes on a feature branch
2. Run `pubm changesets add` to select packages, bump type, and summary
3. Commit the generated `.pubm/changesets/<id>.md` file with your PR
4. On merge, changesets accumulate on main
5. When releasing, `pubm` consumes pending changesets to determine versions and generate CHANGELOG
### Bump Type Guide
- **patch**: Bug fixes, internal refactors with no API changes
- **minor**: New features, backward-compatible additions
- **major**: Breaking changes, removed/renamed public APIs
### Review Checklist
- [ ] Changeset file included (or `no-changeset` label applied)
- [ ] Bump type matches the scope of changes
- [ ] Summary is clear and user-facing
Add to package.json. The release script depends on whether CI was set up:
If CI was configured (publishing is handled by CI):
{
"scripts": {
"release": "pubm --mode ci --phase prepare",
"release:ci": "pubm --mode ci --phase publish"
}
}
--phase prepare collects tokens and validates registry access. --phase publish handles the actual publishing in CI.
If CI was NOT configured (publishing is done locally):
{
"scripts": {
"release": "pubm"
}
}
List all files created or modified and remind them about required authentication. Show only the lines for registries the user selected:
npm login locally, or set NODE_AUTH_TOKEN secret in GitHubpubm locally (interactive token prompt), or set JSR_TOKEN secret in GitHubcargo login locally, or set CARGO_REGISTRY_TOKEN secret in GitHubRemind the user they can run pubm inspect packages at any time to check the detected setup.
defineConfig() from pubm for type safety in config files.packages array with per-package registries; there is no top-level registries field on PubmConfig."release": "pubm --mode ci --phase prepare" if CI is configured, or "release": "pubm" if it is not. Always use "release:ci": "pubm --mode ci --phase publish" for CI.--mode ci --phase publish for publish plus GitHub Release, or --phase publish for publish only./create-plugin skill to scaffold a custom plugin before generating the config file.references/registry-jsr.md -- JSR-specific constraints and templatesreferences/registry-npm.md -- npm-specific constraints and templatesreferences/registry-crates.md -- crates.io-specific constraints and templatesreferences/config-examples.md -- Config file templates and type referencereferences/ci-templates.md -- CI/CD pipeline templates (package manager-specific setup blocks)references/official-plugins.md -- Official plugin API reference (externalVersionSync, brewTap, brewCore)references/homebrew-setup.md -- Homebrew distribution setup and CI installation guide