melodic-software/claude-code-plugins

A public Claude Code plugin marketplace of reusable, repo-agnostic
skills, hooks, and agents. Each plugin is designed to work in any repository and to be customized by
consumers without editing the plugin itself.
Use this marketplace
Browse and manage with /plugin. To refresh after updates: /plugin marketplace update melodic-software.
An install from GitHub is a copy keyed on the plugin's semver version, not the commit, so a change
reaches it only when a release raises that version; until then plugin update reports "already at
the latest version". A marketplace added from a local clone loads each plugin in place, so edits
apply at the next session or /reload-plugins. See
docs/migration-playbook.md ("Same-version commit drift").
Enable plugin suggestions for an organization
Some catalog entries declare relevance signals so Claude Code can suggest the plugin when a
session's work matches (matching runs locally; nothing is reported anywhere). Suggestions are
opt-in per marketplace: they surface only after an administrator allowlists the marketplace in
managed settings. Declare the
marketplace source AND allowlist its name in the same file:
The source declaration is required for any non-official marketplace: the allowlisted name is
ignored if the locally registered marketplace came from a different source. That rule stops an
unrelated catalog from registering under an allowlisted name to get its plugins suggested.
Reference: Recommend plugins for your org.
A plugin whose catalog entry sets defaultEnabled: false installs disabled until the user opts in
with /plugin enable. The flag is set per plugin, not per category: most domain, personal,
harness-maintenance, and external-service plugins carry it, and a few general-purpose ones in
those categories do not. A plugin another enabled plugin depends on starts enabled
regardless, and an existing install keeps its setting when the catalog default changes.
Finding your way
- Not sure which skill to invoke? Start at the skill cheat sheet. A
scan-and-go map from what you are doing to the skill that does it.
- Plugin catalog. Every plugin by category, generated from the manifests and
kept in sync by CI. New plugins clear the per-plugin migration gate in
docs/migration-playbook.md.
- Catalog taxonomy. The category vocabulary the catalog is grouped by.
What's here
- .claude-plugin/marketplace.json, the marketplace catalog.
- plugins/, one directory per plugin.
- lib/, single source of truth for the shared shell helpers; the self-contained copies vendored
under plugins/, into hook and skill-script directories alike, are synced from here by
each helper's own scripts/sync- .sh and CI rejects drift, so never edit a copy.
- scripts/, repo-level CI checks, sync scripts, and catalog generators, with their tests
alongside.
- prompts/, launch-prompt templates meant to be filled in and pasted into a session; unlike
lib/, nothing copies them, and plugin skills cite them by path.
- .claude/, this checkout's own Claude Code configuration (session and PR-linkage hooks, the
source-control convention). It governs work done here and ships to no one.
- .github/, workflows plus the policy files they read (runner policy, security paths, recurring
schedule).
- docs/migration-playbook.md, design charter, extensibility model, the per-plugin migration
gate, and the local development loop.
- docs/, further design records and audits (CI runner routing, extensibility-contract smoke
tests, migration audits).
- CLAUDE.md, operating rules for AI agents working in this repo (fresh-docs mandate + plugin
design rules).
- docs/official-docs.md, canonical index of the official Claude Code doc pages the mandate
sends you to.
Validate a change
The shell suites here are spawn-bound, and Git Bash on Windows pays roughly
140 ms per process spawn against roughly 3 ms on Linux, so running every
**/*.test.sh locally is an hours-long wall on a Windows box and nobody does
it. Run the suites that actually cover your change instead: