Name: marketplace-dev
Author: daymade

Creates and maintains Claude Code plugin marketplaces, consolidates standalone skills into a new or existing suite, and moves skills between suites. Converts any Claude Code skills repository into an official plugin marketplace, generates spec-conforming .claude-plugin/marketplace.json, validates wi

marketplace dev Convert a Claude Code skills repository into an official plugin marketplace so users can install skills via claude plugin marketplace add and get auto updates. Input : a repo with skills/ directories containing SKILL.md files. Output : .claude plugin/marketplace.json + validated + installation tested + PR ready. Route the task before editing User intent Route Create marketplace support for a repo that does not have it Follow Phases 0–4 below Add or update an ordinary plugin entry Follow “Maintaining an existing marketplace,” then Phase 3 Consolidate standalone skills into a suite, create a suite from existing skills, move a skill between suites, or rename a skill while moving it Read [references/suite consolidation workflow.md](references/suite consolidation workflow.md) completely and follow it instead of the generic Phase 4 constraints Reconcile installed caches after a merged suite migration Invoke daymade skill:skill governance and use its post migration workflow; do not mutate cache state here Audit the whole repository across code, docs, security, PRs, issues, and manifest integrity Invoke marketplace health check:marketplace health check only when the user requested a broad health check; it is not a prerequisite for a targeted suite migration Phase 0: Evidence Intake Before editing an existing marketplace, collect evidence instead of relying on the default template: 1. Read the current .claude plugin/marketplace.json . 2. Read this repo's marketplace rules ( CLAUDE.md , README install section, changelog). 3. Read official docs for marketplace/plugin path semantics. 4. Use the current conversation as evidence. Mine earlier local Claude Code sessions only when the user explicitly asks for or approves that private source. When that history source is approved, each project's sessions live under ~/.claude/projects/<escaped cwd / : Top level files: <session id .jsonl Subagent transcripts: <session id /subagents/agent .jsonl Useful search patterns (adjust keywords to the failure you are debugging): Extract lessons as evidence backed rules: command attempted, observed output, root cause, final working command/config. Do not encode guesses from memory. Phase 1: Analyze the Target Repo Step 1: Discover all skills For each skill, extract from SKILL.md frontmatter: name — the skill identifier description — the ORIGINAL text, do NOT rewrite or translate Step 2: Read the repo metadata VERSION file (if exists) — this becomes metadata.version README.md — understand the project, author info, categories LICENSE — note the license type Git remotes — identify upstream vs fork ( git remote v ) Step 3: Determine categories Group skills by function. Categories are freeform strings. Good patterns: business diagnostics , content creation , thinking tools , utilities developer tools , productivity , documentation , security Ask the user to confirm categories if grouping is ambiguous. Step 4: Choose plugin boundaries Claude Code has three separate levels: Marketplace name is used for install identity: plugin@marketplace . Plugin name is the slash namespace: /plugin name:skill name . Skill name comes from SKILL.md frontmatter when the skill path points to a directory containing SKILL.md directly. Choose each plugin boundary by installation/update/cache intent: Single skill plugin : use when the skill should install, update, and roll back independently with a narrow cache. Suite plugin : use when related skills should share one namespace and one install command, for example /daymade docs:mermaid tools . For detailed source/cache patterns and pitfalls, read references/cache and source patterns.md before changing source or skills . Phase 2: Create marketplace.json The official schema (memorize this) Read references/marketplace schema.md for the complete field reference. Key rules that are NOT obvious from the docs: 1. $schema field is REJECTED by claude plugin validate . Do not include it. 2. Use the valid metadata fields : description , version , pluginRoot . metadata.homepage does NOT exist — the validator accepts it silently but it's not in the spec. 3. metadata.version is the marketplace catalog version, NOT individual plugin versions. It should match the repo's VERSION file (e.g., "2.3.0" ). 4. Plugin entry version is independent. For first time marketplace registration, use "1.0.0" . 5. strict: false is required when there's no plugin.json in the repo. With strict: false , the marketplace entry IS the entire plugin definition. Having BOTH strict: false AND a plugin.json with components causes a load failure. 6. source defines the installed plugin root . For single skill plugins, point source directly at the skill directory (e.g., "./tunnel doctor" ) and omit skills entirely. For suite plugins, use source: "./<suite " with explicit skills array listing subdirectories. Avoid source: "./" (installs full repo as cache) and skills: ["./"] (rejected by Claude Code 2.1.x path escape validator). 7. Reserved marketplace names that CANNOT be used: claude code marketplace , claude code plugins , claude plugins official , anthropic marketplace , anthropic plugins , agent skills , knowledge work plugins , life sciences . 8. tags vs keywords : Both are optional. In the current Claude Code source, keywords is defined but never consumed in search. tags only has a UI effect for the value "community managed" (shows a label). Neither affects discovery. The Discover tab searches only name + description + marketplaceName . Include keywords for future proofing but don't over invest. Generate the marketplace.json Use this template, filling in from the analysis: Naming the marketplace The name field is what users type after @ in install commands: claude plugin install dbs@<marketplace name Choose a name that is: Short and memorable kebab case (lowercase, hyphens only) Related to the project identity, not generic Description rules Use the ORIGINAL description from each SKILL.md frontmatter Do NOT translate, embellish, or "improve" descriptions If the repo's audience is Chinese, keep descriptions in Chinese If bilingual, use the first language in the SKILL.md description field The metadata.description at marketplace level can be a new summary Maintaining an existing marketplace Use this section for ordinary entry additions or metadata updates. For a suite consolidation, source relocation, suite membership transfer, or standalone to suite migration, use the dedicated workflow linked in the routing table; those operations have a wider breaking change and documentation surface than an ordinary entry addition. When adding a new plugin to an existing marketplace.json: 1. Bump metadata.version — this is the marketplace catalog version. Follow semver: new plugin = minor bump, breaking change = major bump. 2. Update metadata.description — append the new skill's summary. 3. Set new plugin version to "1.0.0" — it's new to the marketplace. 4. Bump existing plugin version when its SKILL.md content changes. Claude Code uses version to detect updates — same version = skip update. Pair the bump with a CHANGELOG entry in the same commit; nothing checks it for you, and the Pre flight Checklist is the only checklist item that asks for it. 5. Bump existing plugin version when its source or skills changes. The installed cache path and component resolution changed even if SKILL.md did not. 6. Audit metadata for invalid fields — metadata.homepage is a common mistake (not in spec, silently ignored). Remove if found. Adding a member skill to an existing suite Update the following together when adding a member to an existing suite: 1. The suite's skills array in marketplace.json lists the new member ( ./skill name ). check marketplace.py fails when a member dir with a SKILL.md exists on disk but is absent from the array. 2. metadata.version strictly increases. A new member changes the suite's layout signature (source + skills); check version progression.py rejects any layout change without a metadata bump above base — rule 5 above (bump the plugin version ) is necessary but not sufficient here. 3. README.md and README.zh CN.md each gain a skill name detail section. check doc skill lists.py is a required check that extracts every name heading from both READMEs and fails if a marketplace skill is missing (and flags the reverse as GHOST). 4. The suite's invocation list ( /suite:skill name ) in both READMEs. Every new file must also avoid absolute user paths ( /Users/<name /… ) — the PII guard blocks the push. Write ~/ relative and verify by re running the real detector, not by eye. Follow [Skill Creator's versioning contract](https://github.com/daymade/claude code skills/blob/main/daymade skill/skill creator/SKILL.md) and [release readiness](https://github.com/daymade/claude code skills/blob/main/daymade skill/skill creator/references/release readiness.md) for release bookkeeping and review. Include the CHANGELOG entry with the bump; a passing structural check does not establish that the release is documented. The checkers take their base differently, and a usage error is not a verdict: command base argument a usage error gives check version progression.py base <ref candidate HEAD (see below) exit 2 — argparse, a refused candidate index with nothing staged, or an unreadable base/manifest validate changed skills.sh positional <base ref (defaults to origin/main ) exit 1 , printing base ref '<x ' is unknown here check marketplace.py none n/a So the code that means "my invocation was wrong" is per script : exit 2 for check version progression.py , exit 1 for validate changed skills.sh . In both cases the repo was never judged — the same state as not having run it at all. Do not read either code as "the checker found a problem": across the pair, exit 1 is a usage error in validate changed skills.sh but a real finding in check version progression.py — which is exactly why the printed message, not the number, is what you read. The post edit sync check hook only catches "SKILL.md edited but plugin version not bumped". Items 2–4 have no hook, and the CHANGELOG entry has neither a hook nor a checker — run check version progression.py and check doc skill lists.py locally before pushing rather than discovering them across CI rounds. Pass base <base ref candidate HEAD . The script also accepts candidate index , which reads the manifest blob out of the git index and diffs staged paths only; with nothing staged that blob is HEAD's copy, so it re verifies the commit you already have and reports "no regression" about work it never saw. The green is real about the index and silent about your edit. The version gate in CI re runs only when the PR head moves, and it resolves its base to origin/$BASE REF at run time. A PR whose base branch has since advanced therefore keeps the green it earned against the older base, while its version number can already be a regression against the current one. Re run the gate against the current origin/main immediately before merging, not only before pushing, and rebase if it fails. Phase 3: Validate Step 1: One shot pre flight check Run the bundled validator. It runs the following checks and exits non zero on any required failure: What it checks: Check Failure means 1 JSON syntax of .claude plugin/marketplace.json file is not parseable JSON 2 claude plugin validate . (skipped if claude CLI missing) schema level rejection (e.g. Unr