The comment said a release of an existing plugin leaves the catalogue
byte-identical "because entries carry no version and npm resolves latest",
so the dispatch existed only to surface a *new* plugin promptly.
The generator now records the resolved version in the codex manifest, so a
release does change the catalogue's bytes. That was the point of pinning:
without a version, codex compared byte-identical documents, concluded the
catalogue had not moved, and left the installed plugin on whatever it first
resolved.
Comment only — the step already behaved correctly for both cases. Worth
fixing because the old wording invites the reader to skip wiring up
marketplace_dispatch_url unless they are adding a plugin, which is how one
consumer ended up without it.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MgsFmepr9FxbFkax5Y2h6z
Three defects, all of which surfaced flattening the first repository.
The two reusable workflows described the same layout differently: CI left
codex_plugin_root and cursor_plugin_root empty while release defaulted both to
a scaffold path. A repository that stopped shipping a nested plugin therefore
passed CI and failed release, on a directory it had never had. Both now default
to the repository itself, with cursor validation off unless asked for.
claude_marketplace_file defaulted to a manifest that a plugin repository no
longer carries, because the marketplace is generated centrally from the package
registry rather than committed to each repo.
The installation notes documented the flow this replaces — a per-release
installer URL, or a marketplace add against the repo at a tag. With a central
marketplace the instructions no longer mention the version at all: the manifest
names the package and npm resolves the newest.
Adds a dispatch step so a newly published plugin reaches the marketplace
promptly. Gitea's registry_package event cannot serve here — it only fires for
packages linked to the repository, and these are published from GitHub — so the
generator is called over Gitea's API instead. The step never fails the release:
the package is already published, and the generator's schedule catches up.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MgsFmepr9FxbFkax5Y2h6z
The scope routes installs to the registry via .npmrc; it does not have to
match the registry owner. Gitea's own example maps an `@test` scope to a
`testuser` registry URL.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Jm9AfbCJBD4tkxnxxnq7Wm
The generic archive and its installer are opaque to coding agents: something
external has to download and unpack them, which is why the generated installer
script exists. Agents can resolve npm packages on their own, so publishing the
same release contents to an npm registry lets them install and update without
an installer in the loop.
Opt in with `publish_npm`. The package is built from the same staged directory
as the generic archive, so the two cannot drift, and `package.json` is generated
with the release version so it stays in step with the plugin manifest versions
that release-please already bumps.
Two npm behaviours are handled explicitly:
- `npm pack <path>` without a leading `./` is parsed as a GitHub owner/repo
spec, so npm attempts a clone instead of packing the directory.
- npm's ignore rules can drop dot-directories, and the agent catalogs live in
`.agents/` and `.claude-plugin/`. The packed tarball is verified to contain
every released path before publishing, rather than shipping a package that
installs but has no catalog.
The generic archive, installer, and GitHub Release paths are unchanged, so
existing consumers are unaffected.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Jm9AfbCJBD4tkxnxxnq7Wm
walterchengandClaude Opus 5