ClaudeCodeMod

All shelves / Marketplaces

melodic-software/claude-code-plugins

melodic-software/claude-code-plugins · 89 plugins

Marketplace Claude Code plugin marketplace: repo-agnostic skills, hooks, agents, and MCP servers.

Install

The repo has no one-line install. Follow its README.

Open the repo

Plugins 89

After adding the marketplace, install one with /plugin install <name>@melodic-software.

  1. 1markdown-format/plugin install markdown-format@melodic-softwaredevelopment
  2. 2bash-format/plugin install bash-format@melodic-softwaredevelopment
  3. 3biome-format/plugin install biome-format@melodic-softwaredevelopment
  4. 4ruff-format/plugin install ruff-format@melodic-softwaredevelopment
  5. 5typos-format/plugin install typos-format@melodic-softwaredevelopment
  6. 6go-format/plugin install go-format@melodic-softwaredevelopment
  7. 7eol-normalizer/plugin install eol-normalizer@melodic-softwaredevelopment
  8. 8desktop-notification/plugin install desktop-notification@melodic-softwareclaude-code
  9. 9powershell-format/plugin install powershell-format@melodic-softwaredevelopment
  10. 10actionlint/plugin install actionlint@melodic-softwaredevelopment
  11. 11guardrails/plugin install guardrails@melodic-softwaresecurity
  12. 12bugs/plugin install bugs@melodic-softwaremaintenance
  13. 13debugging/plugin install debugging@melodic-softwaremaintenance
  14. 14architecture/plugin install architecture@melodic-softwaredesign
  15. 15mcp-tools/plugin install mcp-tools@melodic-softwarequality
  16. 16prototype/plugin install prototype@melodic-softwaredesign
  17. 17knowledge/plugin install knowledge@melodic-softwarediscovery
  18. 18context7/plugin install context7@melodic-softwarediscovery
  19. 19playbooks/plugin install playbooks@melodic-softwareclaude-code
  20. 20docs-hygiene/plugin install docs-hygiene@melodic-softwaremaintenance
  21. 21docs-naming/plugin install docs-naming@melodic-softwaremaintenance
  22. 22firecrawl/plugin install firecrawl@melodic-softwarediscovery
  23. 23harness-config/plugin install harness-config@melodic-softwareclaude-code
  24. 24harness-memory/plugin install harness-memory@melodic-softwareclaude-code
  25. 25work-items/plugin install work-items@melodic-softwareproject-management
  26. 26discovery/plugin install discovery@melodic-softwarediscovery
  27. 27playgrounds/plugin install playgrounds@melodic-softwarepresentation
  28. 28playwright/plugin install playwright@melodic-softwaretesting
  29. 29code-tidying/plugin install code-tidying@melodic-softwaremaintenance
  30. 30coupling/plugin install coupling@melodic-softwaremaintenance
  31. 31session-flow/plugin install session-flow@melodic-softwareworkflow
  32. 32multi-agent/plugin install multi-agent@melodic-softwareworkflow
  33. 33visualization/plugin install visualization@melodic-softwarepresentation
  34. 34tdd/plugin install tdd@melodic-softwaretesting
  35. 35evals/plugin install evals@melodic-softwaretesting
  36. 36harness-ops/plugin install harness-ops@melodic-softwareclaude-code
  37. 37rate-limit-guard/plugin install rate-limit-guard@melodic-softwareclaude-code
  38. 38context-guard/plugin install context-guard@melodic-softwareclaude-code
  39. 39context-budget/plugin install context-budget@melodic-softwareclaude-code
  40. 40plugin-quality/plugin install plugin-quality@melodic-softwareclaude-code
  41. 41songwriting/plugin install songwriting@melodic-softwareaudio
  42. 42retro-audio/plugin install retro-audio@melodic-softwareaudio
  43. 43speech/plugin install speech@melodic-softwareaudio
  44. 44pixel-art/plugin install pixel-art@melodic-softwarevisual-arts
  45. 45animation/plugin install animation@melodic-softwarevisual-arts
  46. 46explainer-video/plugin install explainer-video@melodic-softwarevisual-arts
  47. 47source-control/plugin install source-control@melodic-softwaredevelopment
  48. 48planning/plugin install planning@melodic-softwaredesign
  49. 49domain-driven-design/plugin install domain-driven-design@melodic-softwaredesign
  50. 50naming/plugin install naming@melodic-softwaredesign
  51. 51review/plugin install review@melodic-softwarequality
  52. 52implementation/plugin install implementation@melodic-softwaredevelopment
  53. 53toolchain/plugin install toolchain@melodic-softwaredevelopment
  54. 54testing/plugin install testing@melodic-softwaretesting
  55. 55verification/plugin install verification@melodic-softwareverification
  56. 56performance/plugin install performance@melodic-softwareverification
  57. 57kindle-dedrm/plugin install kindle-dedrm@melodic-softwarepersonal
  58. 58gaming/plugin install gaming@melodic-softwarepersonal
  59. 59codebase-health/plugin install codebase-health@melodic-softwarequality
  60. 60code-metrics/plugin install code-metrics@melodic-softwarequality
  61. 61discipline/plugin install discipline@melodic-softwarequality
  62. 62education/plugin install education@melodic-softwarelearning
  63. 63repo-hygiene/plugin install repo-hygiene@melodic-softwaremaintenance
  64. 64repo-fleet-hygiene/plugin install repo-fleet-hygiene@melodic-softwaremaintenance
  65. 65disk-hygiene/plugin install disk-hygiene@melodic-softwaremaintenance
  66. 66event-storming/plugin install event-storming@melodic-softwaredesign
  67. 67skill-quality/plugin install skill-quality@melodic-softwareclaude-code
  68. 68machine-health/plugin install machine-health@melodic-softwareoperations
  69. 69ai-briefing/plugin install ai-briefing@melodic-softwarepersonal
  70. 70ai-slop/plugin install ai-slop@melodic-softwarequality
  71. 71miro/plugin install miro@melodic-softwaredesign
  72. 72dometrain/plugin install dometrain@melodic-softwarediscovery
  73. 73dometrain-mcp/plugin install dometrain-mcp@melodic-softwarediscovery
  74. 74autonomy/plugin install autonomy@melodic-softwareautonomy
  75. 75adhd/plugin install adhd@melodic-softwarepersonal
  76. 76github/plugin install github@melodic-softwareoperations
  77. 77x/plugin install x@melodic-softwarediscovery
  78. 78wizard/plugin install wizard@melodic-softwaredevelopment
  79. 79mutation-testing/plugin install mutation-testing@melodic-softwaretesting
  80. 80computer-use/plugin install computer-use@melodic-softwareclaude-code
  81. 81fleet/plugin install fleet@melodic-softwareclaude-code
  82. 82overengineering/plugin install overengineering@melodic-softwarequality
  83. 83improvement/plugin install improvement@melodic-softwarequality
  84. 84instruction-placement/plugin install instruction-placement@melodic-softwareclaude-code
  85. 85attribution/plugin install attribution@melodic-softwarequality
  86. 86writing/plugin install writing@melodic-softwarepresentation
  87. 87user-interface/plugin install user-interface@melodic-softwarepresentation
  88. 88user-experience/plugin install user-experience@melodic-softwaredesign
  89. 89developer-experience/plugin install developer-experience@melodic-softwaredevelopment

Files

README.md

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

/plugin marketplace add melodic-software/claude-code-plugins
/plugin install <plugin-name>@melodic-software

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:

{
  "extraKnownMarketplaces": {
    "melodic-software": {
      "source": {
        "source": "github",
        "repo": "melodic-software/claude-code-plugins"
      }
    }
  },
  "pluginSuggestionMarketplaces": ["melodic-software"]
}

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-<helper>.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:

scripts/affected-tests.sh                 # list the suites covering your diff vs origin/main
scripts/affected-tests.sh --run           # ... and run them, sequentially
scripts/affected-tests.sh --explain       # ... and say why each one was selected
scripts/affected-tests.sh path/to/file.sh # explicit paths instead of a diff

--run is a Linux gate. On a Windows Git Bash host a standing set of suites
fails for reasons that belong to the host rather than to the tree: text-mode
CRLF translation (a native jq and Git Bash line-ending handling), no
unprivileged symlink right, MSYS drive-letter paths against the POSIX form in
fixture assertions, and a missing scc. Its exit code there reports host
capability, not whether your change is good, so Windows is not a supported host
for the full --run gate (#3966).
Selection itself is host-neutral: on Windows, use the listing forms above to see
what your change affects and run individual suites by hand. CI's Linux lanes are
the gate that decides.

It maps a changed file to its co-located suite, to any suite that names it, and
to its dependents transitively, and it fans a shared-lib change out to every
carrying plugin by reading the --print-manifest output of each
scripts/sync-*.sh script, the same manifests CI's sync steps enforce. The
fan-out is derived on every run, never transcribed, so a new carrying plugin is
covered the moment it exists.

All four ecosystems that carry suites here are selected, each by its own naming
convention: shell *.test.sh, Node *.test.js and *.test.mjs, Python
test_*.py, and Pester *.Tests.ps1. Only the shell suites are executed by
--run, because the others are driven by lane-specific invocations that cannot
be derived from a suite path; those are named as NOT RUN and --run exits 3
rather than reporting success over suites that never executed.

A changed file that maps to nothing is an error, not an empty selection.
"zero suites" must never be read as "nothing to run". Path classes that
genuinely carry no suite are recorded, with the CI lane that does cover them, in
scripts/affected-tests-no-suite.txt;
--allow-unmapped is the escape hatch for everything else. That list is for
prose and manifests, never for code: a source file with no coverage is supposed
to fail here. A deletion is the one exception: a changed path that no longer
exists and that nothing claims is reported as a visible deleted: note instead
of the error, because there is no content left to cover. A deletion that a
surviving suite still names (a co-located test left behind, a suite that
references the dead path) keeps selecting those suites, which are exactly what
fails loudly if the deletion broke something.

The runner is deliberately sequential: parallelising it measured sublinear
(the suites are spawn-bound), and several guardrails suites assert wall-clock
ceilings that fail spuriously under concurrency. Selection is the lever.

CI is unaffected, it still runs everything.

Local pre-flight for hygiene gates

Several hygiene findings only show up after a push because the gate name in CI is not the
local command
. The gap is discoverability, not a missing runner: every gate below has a local form.

CI gate / step id Local command Notes
plugin-options-docs python3 scripts/sync-plugin-options-docs.py --check Regenerates from plugin.json userConfig. Do not hand-edit the README block.
config-cascade-semantics python3 scripts/sync-config-cascade-semantics.py --check Regenerates the glance table from the Implementers rows; run it without --check after editing a row. Do not hand-edit the generated block.
typos typos --config _typos.toml Same config CI passes to the composite.
markdown markdownlint-cli2 Config: .markdownlint-cli2.jsonc.
purged-em-dashes scripts/check-purged-em-dashes.sh In-repo.
changelog-parity scripts/check-changelog-parity.sh --check In-repo; add --check-bump origin/main for the version-bump check. A bare run exits 2 with a usage message.
shell-portability scripts/check-shell-portability.sh origin/main In-repo; --all scans the whole tree. A bare run exits 2 with a usage message.
machine-specific-paths EXTENSIONS='<extensions>' EXCLUDE='<excludes>' bash <ci-workflows-checkout>/.github/actions/check-machine-paths/check-machine-specific-paths.sh Run from this repo's root. See Running machine-specific-paths locally.

There is no single script that runs the whole hygiene set. scripts/aggregate-hygiene-results.sh
consumes CI step outcomes; it does not run the gates. A pre-commit hook or a make target that
wraps the runnable rows is a later tooling decision, not this record.

  • Claim: every row of the mapping table is a local command; machine-specific-paths runs the
    pinned composite's own entry script.
  • Basis: the #3522 owner decision (document running the composite's script from a
    ci-workflows checkout). Verified: the script runs standalone and needs only EXTENSIONS and
    EXCLUDE.
  • As of: ci-workflows v0.39.3 (ab83b01273026ab5c23c6f3b40e946d97a863fa2), the pin in
    .github/workflows/pr-require-checks.yml.
  • Recheck: the pr-require-checks.yml pin moves, or the composite's entry script changes its environment
    contract.

Running machine-specific-paths locally

The gate is a composite in melodic-software/ci-workflows. Its entry script runs standalone, but it
sources machine-path-patterns.sh from its own directory, so run it in place from a ci-workflows
checkout.

  1. In the Check for machine-specific paths step of .github/workflows/pr-require-checks.yml, read the pinned SHA
    from the uses: line and the :(exclude)... pathspecs from the exclude: input.
  2. Check out ci-workflows at that SHA:
    git -C <ci-workflows-checkout> switch --detach <sha> (or add a worktree at the SHA).
  3. From this repo's root, run the row's command with EXTENSIONS set to the action's default,
    *.cs *.csproj *.json *.jsonc *.js *.jsx *.md *.props *.ps1 *.psm1 *.py *.sh *.slnx *.targets *.toml *.ts *.tsx *.yaml *.yml,
    and EXCLUDE set to the exclude: pathspecs joined by spaces.

The script uses git grep in the current directory: it scans tracked files only, so git add -N
or commit a new file before running. Exit 0 is clean, exit 1 means findings.

The check-script contract

scripts/check-*.sh is one family with one caller-visible interface, so a CI
lane, a wrapper, or an agent reads a run's outcome without knowing which member
produced it.

Exit Meaning
0 Clean. The check ran over its whole corpus and found nothing.
1 Findings. The check ran and something in the tree is wrong.
2 Environment or usage. The check could not run: a missing tool, a bad argument, a repo root or shared library that did not resolve, a git query that failed. Nothing was inspected, so this is never a pass.

Findings and diagnostics go to stderr; stdout carries the clean-run
statement and, for the discovery or list modes some members offer, the report
that mode exists to print.

Keeping 1 and 2 apart is the whole point: "your tree is wrong" and "I could
not look" are different answers, and a lane that reads only success or failure
collapses them into one. This is the mechanical form, for this family, of the
fail-loud rule in
docs/conventions/liveness-assertion/.
An environment failure is spelled out rather than left to set -e: resolving the
repo root and sourcing a shared library each end in || exit 2, because set -e
would exit with the failing command's own status and hand the caller a 1 that
reads as findings.

scripts/check-script-contract.test.sh
holds the contract. Every member is registered there and a new one fails as
unregistered. Each member that declares a prerequisite is run with that
prerequisite taken away and must exit 2 on stderr; each member with a fixture
recipe is also run clean (exit 0, statement on stdout) and against a seeded
violation (exit 1, finding on stderr and not on stdout). A member with no
recipe yet is held to those last two halves by its own co-located suite.

Three readings diverge on purpose and are recorded here rather than forced into
line:

  • scripts/check-hook-exec-form.sh treats a hook declaration it cannot parse as
    a finding (1), not an environment problem. The input is what is wrong, and
    clearing a file the gate never read is the silent no-op it exists to catch.
  • scripts/check-killswitch-hoist.sh stops at 1, not 2, when the hook corpus
    scans to empty or the inlined kill-switch predicate no longer agrees with the
    hook::is_enabled it duplicates. Both are statements about the tree, not about
    the host.
  • scripts/check-changelog-parity.sh discusses exit 128 and 141 at length
    and emits neither. Those are git's "no merge base" and a reader killed by
    SIGPIPE, each converted to an exit 2 or read correctly. Grepping the file for
    those numbers finds the guards, not divergence.

The contract governs the observable interface, not the option set: set -euo
and set -uo both appear in the family and neither is required, which is why
the prologue states its own || exit 2 instead of depending on which one is in
force. Members still resolving the repo root under set -e alone are aligned on
touch.

Official documentation

This repo tracks policy and wiring only; authoritative behavior lives in the official docs, which must
be read fresh rather than recalled. Start at the
Claude Code plugins overview.

What this marketplace actually publishes

This repository is the only authoritative listing of what this marketplace publishes. The plugins and
skills it ships are the ones present in plugins/ on the default branch, and the
marketplace manifest is the machine-readable form of that list.

Several third-party aggregator and directory sites republish Claude Code skill listings, and some of
them attribute skills to this publisher that have never existed here. A search of the full commit
history of this repository found no trace of them. If you find a skill credited to this marketplace
that you cannot locate in plugins/ on the default branch, it is not ours, whatever a directory
says. Install from the source above rather than from a mirror or a directory listing, and treat an
aggregator's metadata as unverified.

Inbound requests to list this marketplace on third-party awesome-lists
(including awesome-ai-plugins)
are declined here: this repository does not maintain those entries, and an
aggregator listing is not an install path.

License

MIT.

Facts

Kind
Marketplace
Repo
melodic-software/claude-code-plugins
Group
Uncategorized
Marketplace name
melodic-software
Owner
Melodic Software
License
MIT
Language
Shell
Created
2026-06-22
Forks
2
Topics
agents, ai-tools, claude-code, marketplace, mcp, plugins
Plugins
36

More on this shelf

  1. 1f/prompts.chatf/prompts.chatf.k.a. Awesome ChatGPT Prompts. Share, discover, and collect prompts from the community. Free and open source — self-host for your organization with complete privacy.
  2. 2affaan-m/everything-claude-codeaffaan-m/everything-claude-codeThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.
  3. 3obra/superpowersobra/superpowersAn agentic skills framework & software development methodology that works.
  4. 4anthropics/skillsanthropics/skillsPublic repository for Agent Skills
  5. 5anthropics/claude-codeanthropics/claude-codeClaude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.
  6. 6nextlevelbuilder/ui-ux-pro-max-skillnextlevelbuilder/ui-ux-pro-max-skillAn AI skill that provides design intelligence for building professional UI/UX across multiple platforms.