v2.1.3

Changed

• Pinned to project-flow v3.1.0.

v2.1.2

Added

• CI checks the changelog's link footer: every released version needs a [x.y.z]: <url> ref, and
  [Unreleased] must compare from the newest release. 2.1.1 shipped with no ref of its own and with
  [Unreleased] still comparing from 2.1.0; both listed plugins had the same drift, and nothing
  caught it in any of the three repositories.

Changed

• Pinned to project-flow v3.0.3 and web-launcher v0.3.3.

Fixed

• The link footer is repaired: [2.1.1] added, [Unreleased] compares from the newest release.
• 2.1.1 described strict as making an entry "require the plugin manifest to be present at the
  pinned ref". That is not what it does. strict: true is the default and makes plugin.json the
  authority, with any component fields in the catalog entry merged into it; strict: false makes
  the entry the whole definition and fails the load if the manifest also declares components.
  Neither entry declares components, so the flag states the default rather than adding a guarantee.

v2.1.1

Added

• Each entry now carries license, homepage, repository and keywords, and is marked
  strict. The catalog is the surface /plugin browses and searches, and it was carrying only a
  name, a description and a source — so a search for "seo" or "planning" matched neither plugin
  even though both manifests have listed those keywords all along. strict makes an entry require
  the plugin manifest to be present at the pinned ref rather than installing whatever is at that
  path.
• CI compares the description, licence and keywords in each catalog entry against the plugin.json
  it resolves to. Those fields are now stated in two repositories, which is exactly how one goes
  stale — the copy is checked rather than trusted, the same way the name and version already were.
• CI checks the changelog's structure: no section heading twice inside one version block, only
  Keep a Changelog section names, an [Unreleased] section, and one dated heading per version.

Changed

• Pinned to project-flow v3.0.2 and web-launcher v0.3.2.

Full changelog: https://github.com/voyvodka/claude-plugins/blob/main/CHANGELOG.md

v2.1.0

Pinned to project-flow v3.0.1 and web-launcher v0.3.1.

Both are patch releases fixing diagnostic checks that could report success on a failing site, and instructions that contradicted themselves. Pinned sources mean a plugin release reaches nobody until the catalog follows — that is the cost pinning accepted, and the CI three-way version check is what turns forgetting it into a build failure.

v2.0.1

Added

• The cross-repo validator now compares the plugin name, not just the version. name is the install key: if it drifts between marketplace.json and plugin.json, claude plugin validate passes on both (each file is internally consistent), the version and ref checks pass, and the only thing that breaks is the install. That is the exact failure the project → project-flow rename could have caused.

Fixed

• The v1.1.0 changes had no version heading and sat under [2.0.0], so the changelog claimed the tag-pinning work shipped in 2.0.0 when it shipped a release earlier, and v1.1.0 documented nothing. Split apart, compare links corrected.

v2.0.0

⚠️ Breaking: project is now project-flow

/plugin install project-flow@voyvodka

A top-level renames entry maps the old name to the new one, so Claude Code v2.1.193+ rewrites enabledPlugins and pluginConfigs in your user, project and local settings automatically and tells you it did.

What it does not cover:

• The source is remote (git-subdir), so you get one plugin-cache-miss and need a single /plugin install to fetch it under the new name.
• Managed and policy settings are read-only to Claude Code, so the notice recurs there until an administrator updates them.
• Older Claude Code ignores renames and reports plugin-not-found for the old name.

The entry now points at plugins/project-flow at ref: v3.0.0.

renames is append-only history — the entry stays after everyone has migrated, because it is what makes the old name resolvable at all.

v1.1.0

Changed

• Both plugins are pinned to a release tag (ref: v2.8.0, ref: v0.3.0) instead of resolving against whatever main held at install time. An update now gives you a version that was tagged and released.
  This adds a release step: a newly tagged plugin does not reach anyone until its version and ref are bumped here — and the new version check turns forgetting that into a CI failure rather than a silent no-op.

Added

• CI clones each git-subdir source at its pinned ref, checks the path exists, runs claude plugin validate --strict inside it, and asserts the tag, the catalog entry and the plugin's own plugin.json all name the same version. Validating this repo's manifest said nothing about whether the plugins it pointed at still existed — a renamed or deleted path would have kept CI green until someone hit the broken install.

v1.0.0

First tagged release of the catalog. Nothing about how you install changes — this exists so there is something to diff against next time.

Added

• LICENSE. The README claimed MIT with no file behind it, so GitHub and licence scanners saw an unlicensed repository.
• .github/workflows/validate.yml — claude plugin validate . --strict on every push and pull request. A malformed marketplace.json previously would have shipped silently.
• .github/dependabot.yml — monthly github-actions updates for the pinned action SHAs.

Fixed

• $schema pointed at a URL that redirects to a marketing page rather than a schema. Now the real SchemaStore entry, so editors can validate the file.
• The plugin table in the README was a hand-maintained paraphrase of marketplace.json and had drifted from it. It now quotes the manifest verbatim.