fix(create-plugin): document valid marketplace entry fields

[abhinavgautam01]

Closes #281

Summary

• Document name and source as required marketplace plugin-entry fields.
• Document description and minClientVersions as optional fields.
• Clarify that keywords, category and tags belong in the plugin's .cursor-plugin/plugin.json manifest and are invalid in marketplace entries.

Why

The create-plugin-scaffold skill previously recommended fields that are rejected by schemas/marketplace.schema.json. Following those instructions could produce a marketplace entry that fails repository validation.

Validation

• git diff --check
• Validated SKILL.md YAML frontmatter
• Verified the documented fields match the marketplace schema
• Ran node scripts/validate-plugins.mjs
  • Result: All plugins validated successfully.

---

Note

Low Risk
Documentation-only change to a scaffold skill; no runtime or schema behavior is modified.

Overview
Updates the create-plugin-scaffold skill so step 6 matches schemas/marketplace.schema.json instead of suggesting fields that fail validation.

Marketplace plugin entries are documented as requiring name and source, with optional description and minClientVersions. The skill now states that keywords, category, and tags belong in .cursor-plugin/plugin.json, not in marketplace entries.

^{Reviewed by Cursor Bugbot for commit 256bd2b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[yangfan-yf-yf]

I verified 256bd2b1df6fdd427aca0a5378303dc80ea36c6f: node scripts/validate-plugins.mjs passes. I also checked the schemas with minimal fixtures: name/source and the documented optional fields pass; adding keywords, category, or tags to a marketplace entry fails; those three fields pass in plugin.json.

Could the last sentence of step 6 scope “not valid marketplace entry fields” to this repository's schema? The official plugin entry reference currently lists all three as supported marketplace fields. The skill also supports creating plugins in other repositories, so the unconditional statement could be read as a Cursor-wide restriction.

For example: “For this repository, keep keywords, category, and tags in .cursor-plugin/plugin.json; schemas/marketplace.schema.json rejects them in marketplace entries.” This preserves the repository validation fix without claiming that the general Cursor format forbids these fields. I have not tested the Cursor runtime parser.