walterchengandClaude Opus 5
c8c80f4133
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
Common Agent Marketplace Workflows
Public reusable GitHub Actions workflows and validation actions for repositories that publish agent skills and plugins.
This repository intentionally contains only generic marketplace automation:
- skill and plugin manifest validation
- pull-request preview archives
- release archives and installation summaries
- optional catalog metadata published beside release artifacts
- optional npm registry publishing for agents that support npm catalogs
Container, infrastructure, deployment, and environment-specific workflows are
kept in the private Walter0697/common-workflow repository.
Reuse
Reference the workflows from a repository workflow with a version tag or commit SHA, for example:
jobs:
validate:
uses: walter-base/common-workflow/.github/workflows/agent-marketplace-ci.yaml@master
The validator is also available as:
uses: walter-base/common-workflow/actions/validate-agent-marketplace@master
Publishing to an npm registry
The generic archive and its installer are opaque to coding agents: something has to download and unpack them, which is what the generated installer script does. Agents can, however, resolve npm packages on their own, so publishing the same release contents to an npm registry lets them install and update without an installer.
Release callers may pass catalog_file to publish a validated catalog.json
beside the Generic package archive and installer. The file is also included in
the archive when its path is listed in package_paths.
Enable it on the release workflow:
with:
publish_npm: true
npm_package_name: "@acme/agent-skills"
# npm_registry defaults to the Gitea npm registry for gitea_user
secrets:
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
Notes:
- the package is built from the same staged directory as the generic archive, so the two can never drift apart
package.jsonis generated at publish time with the release version, which keeps it in step with the plugin manifest versions that release-please bumpsnpm_package_namemust be scoped, because the scope is what routes installs to the registry in.npmrc. The scope does not have to match the registry owner: Gitea's own example maps an@testscope to atestuserregistry URLNPM_TOKENis used when set; otherwiseGITEA_TOKENis reused- publishing fails if any released path is absent from the packed tarball, which
guards against npm's ignore rules silently dropping
.agents/or.claude-plugin/