universal-plugin 0.6.0 → 0.8.0

package/skills/migrate-plugin/SKILL.md

@@ -1,15 +1,17 @@
 ---
 name: migrate-plugin
-description: "Move a repository-root universal agent plugin into its npm package so the package distributes its manifest, vendor manifests, skills, and agents. Use this skill when packaging an existing plugin for npm, relocating a top-level plugin into a package, or fixing a package that omits plugin assets, even if the user says only 'ship this plugin through npm' or 'move the plugin into the package.'"
+description: "Move a repository-root or sibling-workspace universal agent plugin into its npm package so the package distributes its manifest, vendor manifests, skills, and agents, and bundle the package's CLI with tsdown so it runs from an installed plugin directory with no node_modules. Use this skill when packaging an existing plugin for npm, relocating a top-level or plugins/<name> plugin into a package, fixing a package that omits plugin assets, or making a plugin's bundled CLI self-contained, even if the user says only 'ship this plugin through npm', 'move the plugin into the package', or 'the CLI can't find its dependencies when installed as a plugin.'"
 ---
 
 # Migrate Universal Plugin to npm
 
 ## Scope
 
-Move one existing universal plugin from a repository root into its owning npm
-package. The package becomes the plugin root and must contain every runtime
-artifact it needs after installation.
+Move one existing universal plugin into its owning npm package. The plugin may
+sit at the repository root or in its own workspace member such as
+`plugins/<name>/`. The package becomes the plugin root and must contain every
+runtime artifact it needs after installation — including a CLI that runs
+without `node_modules`.
 
 This skill does not create a plugin from scratch, publish a package, or move
 project-local agent configuration unrelated to the plugin.
@@ -22,34 +24,44 @@ Before changing manifest fields or component compatibility behavior, consult the
 and its versioned specification: it is the canonical reference for the current
 standard. Keep an existing schema version pinned unless the user explicitly
 requests a standards upgrade.
-Inventory these root-level plugin assets when they exist:
+Inventory these plugin assets in the source root when they exist:
 
 - `plugin.json`
 - vendor manifest directories for Claude Code, Cursor, Codex, and Copilot CLI
+- `.plugin/` (for example a `pins.json` that skills read at runtime)
 - `skills/`, `agents/`, `commands/`, `hooks/`, `rules/`, `output-styles/`
 - `.mcp.json`, `.lsp.json`, and plugin-owned `assets/`
 
+Also inventory what exists only to host the plugin in its old place: a
+workspace-member `package.json` (for example a private `@scope/<name>-plugin`),
+and the `pnpm-workspace.yaml` or `workspaces` glob that includes it.
+
 Leave project configuration in place unless it is required solely to maintain
 the moved plugin. In particular, do not move `.agents/skills/`, plans, or a
-marketplace catalog such as `.claude/marketplace.json`.
+marketplace catalog such as `.claude-plugin/marketplace.json`.
 
 Before modifying files, report the exact source-to-destination mapping and any
-destination collisions. Ask for confirmation if a destination contains a
-different file that would be overwritten.
+destination collisions. A `readme.md` on both sides is the usual one: merge the
+plugin readme into the package readme as its own section rather than
+overwriting either. Ask for confirmation if a destination contains a different
+file that would be overwritten.
 
 ## 2. Move the plugin root
 
-Move each inventoried asset under the package directory, preserving its path.
-A package receives these relative paths:
+Move each inventoried asset under the package directory with `git mv`,
+preserving its relative path, so history follows the files:
 
 ```text
 the canonical manifest
 vendor manifests
+.plugin/
 skills
 agents
 ```
 
 The source root must no longer retain duplicate distributable plugin assets.
+When the source was its own workspace member, delete its `package.json`, drop
+the now-empty workspace glob, and reinstall so the lockfile loses the member.
 Do not move a project-local skill merely because it is under `.agents/skills/`.
 
 ## 3. Configure npm packaging
@@ -68,6 +80,7 @@ configuration is:
     ".claude-plugin",
     ".cursor-plugin",
     ".codex-plugin",
+    ".plugin",
     "skills",
     "agents"
   ]
@@ -77,30 +90,131 @@ configuration is:
 Retain existing package entries such as `bin`, `dist`, and `governances`.
 Never replace the allowlist wholesale.
 
-## 4. Preserve release synchronization
-
-If the repository runs `universal-plugin publish sync-version`, move its
-plugin-specific configuration beside the new `plugin.json` and change
-`packagePath` to `"."`. Update the root release script to run the command from
-the destination package, for example:
-
-```sh
-pnpm exec universal-plugin publish sync-version --root .
+## 4. Bundle the CLI with tsdown
+
+An installed agent plugin is a copy of a source checkout, not an npm install,
+so its directory has no reliable `node_modules`. A CLI whose build leaves
+dependencies external fails there. When the package ships a CLI, build it so
+every runtime dependency is inlined into the CLI entry, while any library entry
+keeps its dependencies external.
+
+Split `tsdown.config.ts` into two configs that share an `outDir`:
+
+```ts
+import { defineConfig } from 'tsdown'
+
+// Two configs, because the entries want opposite dependency treatment. They share an
+// `outDir`, which is safe: tsdown hoists `clean` and runs it once across every config
+// before any build writes, so neither wipes the other.
+const shared = {
+	outDir: 'dist',
+	format: 'esm',
+	platform: 'node',
+	clean: true,
+} as const
+
+export default defineConfig([
+	{
+		// Library entry. Dependencies stay EXTERNAL: their types surface in the public
+		// `.d.ts`, and a consumer that also uses them must share one copy.
+		...shared,
+		entry: { index: 'src/index.ts' },
+		dts: true,
+	},
+	{
+		// CLI entry. Every runtime dependency is inlined so it runs with no node_modules.
+		...shared,
+		entry: { cli: 'src/cli.ts' },
+		dts: false,
+		deps: {
+			alwaysBundle: [/^commander(\/|$)/, /^some-dep(\/|$)/],
+			onlyBundle: false,
+		},
+	},
+])
 ```
 
+Rules for the CLI config:
+
+- **`alwaysBundle` lists exactly the package's own `dependencies`.** Those are
+  the only ones tsdown externalizes by default; their transitive dependencies
+  are inlined automatically. Use `^name(\/|$)` regexes so subpath imports
+  (`some-dep/worktree`) are caught too.
+- **Omit a dependency consumed only through `import type`.** TypeScript strips
+  it before bundling, and a package whose entry is raw `.ts` cannot be bundled.
+- **`onlyBundle: false`** silences the "bundled a dependency" warnings that are
+  the point of this config.
+- **Keep the existing output extensions.** If `bin` and `exports` already name
+  `.mjs`, leave tsdown's default; if they name `.js`, add
+  `outExtensions: () => ({ js: '.js' })` to `shared`. Never move published
+  paths as a side effect.
+- **Keep the entry's invocation contract.** When `bin` points straight at the
+  CLI output, `src/cli.ts` must keep its `#!/usr/bin/env node` shebang (tsdown
+  preserves it and sets the execute bit). When `bin` is a wrapper that imports
+  the output and calls an exported function, leave the wrapper as is.
+- **Resolve runtime files relative to the output.** A CLI that reads
+  `../package.json` through `import.meta.url` still works only if `src/` and
+  `dist/` sit at the same depth and `package.json` ships — confirm both.
+
+Verify the bundle, not just the build:
+
+1. `grep -En "from ['\"](dep-a|dep-b)" dist/cli.*` prints nothing, while the
+   library output still imports them.
+2. Pack into a scratch directory, extract, confirm the extracted `package/` has
+   no `node_modules`, then run the CLI through its `bin` path: `--version` and
+   one read-only command. Do not run it from the workspace, where hoisted
+   `node_modules` hides a missing inline.
+
+Skills that invoke the CLI through `npx <cli>@<version>` can then prefer the
+shipped CLI. That changes skill behavior and often a frozen spec, so offer it
+as a follow-up instead of doing it inside this migration.
+
+## 5. Preserve release synchronization
+
+Point every version and build step at the new plugin root:
+
+- Set the manifest extension's `packagePath` to `"."`.
+- `universal-plugin publish sync-version --root <pkg>` reads `packagePath` from
+  `<pkg>/.agents/universal-plugin.json`, not from the manifest extension. To use
+  it, create that file with `{ "packagePath": "." }`. If the repository instead
+  runs its own sync script, repoint that script's manifest path and leave it.
+- Change every `universal-plugin plugin build --root <old>` in `package.json`
+  scripts to the package directory, then run it and confirm it reports the
+  vendor manifests as built and the catalog as unchanged or refolded.
+- Repoint a local-directory `source` in the repository's marketplace catalog to
+  the package directory.
+
 Update any checked-in skill lockfile that records an absolute source path for a
 moved skill. Do not modify unrelated agent configuration.
 
-## 5. Verify the result
+## 6. Repoint tooling and prose
+
+Search the repository for the old plugin path and update live references:
 
-1. Run the package's focused tests and typecheck/lint commands.
+- lint and format excludes for generated vendor manifests (for example
+  `biome.json` `files.includes` negations), knip workspaces, turbo filters
+- `AGENTS.md`, `CONTRIBUTING.md`, readmes, docs pages, and spec frontmatter
+  such as `project-path`
+- guards scoped to the package directory, such as a vocabulary or lint check —
+  confirm moved skills did not enter a scope that rejects their wording
+
+Leave historical records as written: changelogs, ADRs, research notes, and
+decision or gate ledgers describe the layout at the time.
+
+## 7. Verify the result
+
+1. Run the repository's full verification (lint, build, typecheck, test).
 2. Run `npm pack --dry-run` from the destination package. Confirm it lists
-   `plugin.json`, every required vendor manifest, `skills/`, and `agents/`.
-3. If the manifest declares build targets, run `universal-plugin plugin build`
-   from the destination package and confirm generated paths stay inside it.
-4. Search the repository for stale references to the old top-level asset paths.
+   `plugin.json`, every required vendor manifest, `.plugin/` when present,
+   `skills/`, `agents/`, and the bundled CLI.
+3. Confirm step 4's no-`node_modules` run passed.
+4. Search the repository again for stale references to the old asset paths.
 5. Review the diff to confirm no project-local `.agents` content or marketplace
-   catalog was included in the package.
+   catalog was moved into the package.
+6. Add a changeset for the package when the repository uses changesets.
+
+Commit the move and the CLI bundling as separate commits: each is revertable on
+its own.
 
 Report the package path, files added to the npm tarball, checks run, and any
 intentionally retained root-local files.

package/skills/migrate-plugin/evals/evals.json

@@ -6,6 +6,12 @@
 			"prompt": "Move the top-level universal plugin into packages/universal-plugin so npm distributes it.",
 			"expected_output": "Inventories and relocates only distributable plugin assets, adds them to package.json files, updates version synchronization, verifies npm pack --dry-run, and preserves project-local .agents content.",
 			"files": []
+		},
+		{
+			"id": 2,
+			"prompt": "Convert plugins/my-tool into an npm-distributed plugin inside packages/my-tool. The package already has a CLI built with tsdown that depends on commander.",
+			"expected_output": "Moves the plugin assets with git mv, merges colliding readmes instead of overwriting, removes the old workspace member and its glob, extends package.json files, sets packagePath to '.', repoints plugin build and the marketplace source, splits tsdown.config.ts so the CLI entry inlines commander via alwaysBundle while the library entry keeps it external, and proves the CLI runs from an extracted tarball with no node_modules.",
+			"files": []
 		}
 	]
 }

package/skills/migrate-plugin/evals/trigger-queries.json

@@ -19,6 +19,24 @@
 			"should_trigger": true,
 			"split": "val"
 		},
+		{
+			"id": 6,
+			"query": "Convert plugins/cyberlegion to an npm distributed plugin in packages/cyberlegion.",
+			"should_trigger": true,
+			"split": "train"
+		},
+		{
+			"id": 7,
+			"query": "Our plugin's CLI crashes with 'Cannot find package commander' when Claude Code installs the plugin. Bundle it so it runs without node_modules.",
+			"should_trigger": true,
+			"split": "val"
+		},
+		{
+			"id": 8,
+			"query": "Switch this library's build from tsup to tsdown.",
+			"should_trigger": false,
+			"split": "train"
+		},
 		{
 			"id": 4,
 			"query": "Upgrade all npx universal-plugin pins to version 0.3.0.",

package/skills/publish-plugin/README.md

@@ -0,0 +1,35 @@
+# publish-plugin skill
+
+List an already-packaged plugin in a shared marketplace repository by opening a pull request against
+its vendor catalogs.
+
+## What it does
+
+Four steps: locate the plugin and the marketplace, validate the plugin is ready, prepare the entry
+for each vendor catalog that exists, then open one PR that updates all of them together.
+
+## Two repos, either one could be the cwd
+
+The plugin being published and the marketplace it is going into are different repos, and the current
+working directory could be either. The skill checks the cwd's remote against the target marketplace
+repo (`cyberuni/marketplace` by default) before doing anything else:
+
+- cwd is the plugin → the marketplace repo gets cloned or forked, as it always did.
+- cwd is already the marketplace → work happens in place; the plugin's metadata is read from wherever
+  the user points to instead (a local path, or a URL cloned to a scratch directory).
+
+Every check and every entry field in Steps 1–2 reads from the plugin location this step finds, never
+from the cwd by assumption. Getting this wrong means the marketplace entry ends up pointing at the
+marketplace repo's own URL instead of the plugin's.
+
+## Why this is not the `marketplace` skill
+
+`marketplace` generates a repository's own local catalog — no submission, no shared listing, no PR.
+This skill is the opposite case: putting a plugin into someone else's shared catalog, which only a
+pull request can do. They compose rather than overlap: a plugin can have both a local catalog for
+`git clone`-and-go installs and a listing here.
+
+## References
+
+- [Spec](https://github.com/cyberuni/universal-plugin/blob/main/packages/universal-plugin/.agents/spec/spec.md)
+- `references/vendor-requirements.md` — required fields and hook casing rules per runtime

package/skills/publish-plugin/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: publish-plugin
-description: Use this skill whenever the user wants to publish, release, submit, or share a plugin to the universal plugin marketplace so it works across Claude Code, Cursor, Codex, and GitHub Copilot CLI. Trigger on phrases like "publish my plugin", "submit to marketplace", "release plugin", "list my plugin", "share my plugin", or any mention of getting a plugin into the universal registry. The plugin should already be packaged before using this skill.
+description: Use this skill whenever the user wants to publish, release, submit, or share a plugin to the universal plugin marketplace so it works across Claude Code, Cursor, Codex, and GitHub Copilot CLI. Trigger on phrases like "publish my plugin", "submit to marketplace", "release plugin", "list my plugin", "share my plugin", or any mention of getting a plugin into the universal registry. Works whether the current repo is the plugin being published or the marketplace it is going into. The plugin should already be packaged before using this skill.
 ---
 
 # Publish Universal Plugin
@@ -15,8 +15,9 @@ two compose, and neither replaces the other.
 
 ## Overview
 
-Publishing has three steps:
+Publishing has four steps:
 
+0. **Locate** — work out which repo is which, and where the plugin and the marketplace each live
 1. **Pre-flight** — validate the plugin is ready
 2. **Prepare entries** — build the entry for each vendor marketplace file that exists
 3. **Submit PR** — one PR that updates all relevant marketplace files
@@ -25,9 +26,48 @@ Work through each step in order. Do not skip pre-flight even if the user says th
 
 ---
 
+## Step 0: Locate the plugin and the marketplace
+
+Two repos are in play — the plugin being published and the marketplace it is going into — and the
+current working directory could be either one. Do not assume it is the plugin repo just because that
+is the common case.
+
+### 0a. Identify the marketplace repo
+
+Default to `cyberuni/marketplace` unless the user names another one.
+
+### 0b. Identify which repo the cwd is
+
+```bash
+gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null
+```
+
+Compare the result against the marketplace repo from 0a.
+
+- **Matches the marketplace repo** → cwd *is* the marketplace. The plugin lives elsewhere: ask the
+  user for its location if they have not given one — a local path, or a git URL to clone. Resolve a
+  git URL with `gh repo clone <url> /tmp/<plugin-name>` (or a scratch directory) so pre-flight has a
+  checkout to read; do not guess metadata from the URL alone.
+- **Does not match, or `gh repo view` fails** (no `origin`, not a GitHub repo, detached checkout) →
+  cwd is the plugin repo. This is the default path described in Steps 1–3 below.
+- **User states their role explicitly** ("I'm already in the marketplace repo", "publish the plugin
+  at ../foo") — trust that over the remote check; it exists to catch the unstated case, not to
+  override what the user already told you.
+
+Name two locations going forward and keep them distinct in your own reasoning and in what you tell
+the user:
+
+- **plugin location** — the directory holding the plugin's root `plugin.json`, wherever it is
+- **marketplace location** — the directory holding the marketplace's vendor catalog files
+
+Every pre-flight check and entry field in Steps 1–2 reads from the plugin location, not the cwd.
+Step 3 branches on whether the marketplace location is already the cwd.
+
+---
+
 ## Step 1: Pre-flight validation
 
-Run these checks against the plugin directory. Stop and fix any failures before continuing.
+Run these checks against the **plugin location** from Step 0. Stop and fix any failures before continuing.
 
 ### 1a. Required metadata
 
@@ -74,7 +114,9 @@ List what passed and what failed. Do not proceed to Step 2 until all checks pass
 
 ### 2a. Detect which vendor marketplace files exist
 
-Clone or check out the marketplace repo locally, then look for vendor marketplace files:
+Get the **marketplace location** locally if it is not already the cwd — see Step 3a, which this step
+can run ahead of when you need the files present before drafting entries. Then look for vendor
+marketplace files:
 
 | File | Runtime |
 |---|---|
@@ -83,17 +125,39 @@ Clone or check out the marketplace repo locally, then look for vendor marketplac
 
 Only prepare entries for files that actually exist — do not create new vendor marketplace files.
 
-### 2b. Claude Code entry (`.claude-plugin/marketplace.json`)
+### 2b. Determine the source/distribution type
+
+Before writing any entry, decide how the plugin is actually distributed — do not default to a
+root-clone `url`. Read the signals from the plugin's own repository, in this order:
+
+1. **`npm`** — the CLI reports a `packagePath`, and `<packagePath>/package.json` is not
+   `"private": true`. The plugin ships as an npm package. Ask the CLI rather than reading
+   `.agents/universal-plugin.json` yourself; the path it prints is relative to the plugin root:
 
-The richer format. Use this shape:
+   ```bash
+   npx universal-plugin config get --key packagePath --format json --root <plugin-root>
+   ```
+
+   `null` means no npm package is declared.
+2. **`git-subdir`** — the plugin's `plugin.json` (or its vendor manifests) live below the
+   repository root, e.g. `packages/<name>/plugin.json`, and there is no `packagePath`/npm
+   distribution. This is the common monorepo case: the repository root holds no plugin manifest at
+   all, only a `marketplace.json` catalog or unrelated packages, so a root-clone `url` source
+   resolves nothing.
+3. **`url` / `github`** — `plugin.json` sits at the repository root. `url` for a plain clone,
+   `github` when a sparse/shallow checkout is preferred.
+
+Only ask the user when these signals genuinely conflict or are missing (e.g. no `plugin.json` found
+at any candidate path). Otherwise decide from the signals and state which one you picked and why.
+
+### 2c. Claude Code entry (`.claude-plugin/marketplace.json`)
+
+The richer format. Use this shape, filling `source` per the type decided in 2b:
 
 ```json
 {
   "name": "<plugin-name>",
-  "source": {
-    "source": "url",
-    "url": "<git-clone-url>.git"
-  },
+  "source": { "source": "url", "url": "<git-clone-url>.git" },
   "description": "<one-line description>",
   "author": { "name": "<author>" },
   "homepage": "<URL>",
@@ -103,7 +167,17 @@ The richer format. Use this shape:
 }
 ```
 
-**`source`** — use `"source": "url"` with the `.git` clone URL for public repos. Other options: `github` (sparse checkout), `git` (with ref/path), `file`, `directory`.
+**`<git-clone-url>`** — the plugin's own repo URL, read from the **plugin location** (`gh repo view --json url -q .url`, or the `repository` field in its `plugin.json`) — never the marketplace repo's URL.
+
+**`source` shapes** — pick the one matching 2b's decision:
+
+| Type | Shape | When |
+|---|---|---|
+| `url` | `{ "source": "url", "url": "<git-clone-url>.git" }` | `plugin.json` at repo root |
+| `github` | `{ "source": "github", "repo": "<owner>/<repo>" }` | repo root, sparse checkout |
+| `git-subdir` | `{ "source": "git-subdir", "url": "<git-clone-url>.git", "path": "<repo-relative-path-to-plugin-dir>" }` | plugin lives in a monorepo subdirectory, e.g. `packages/<name>` |
+| `npm` | `{ "source": "npm", "package": "<npm-package-name>" }` | plugin ships as an npm package (`packagePath` present, not private) |
+| `file` / `directory` | see the marketplace schema | local-only entries |
 
 **`category`** — choose closest: `research`, `skills`, `setup`, `productivity`, `plugin-authoring`.
 
@@ -116,29 +190,40 @@ The richer format. Use this shape:
 
 Omit optional fields rather than leaving them empty.
 
-### 2c. Cursor entry (`.cursor-plugin/marketplace.json`)
+### 2d. Cursor entry (`.cursor-plugin/marketplace.json`)
 
 The simpler format — only three required fields:
 
 ```json
 {
   "name": "<plugin-name>",
-  "source": {
-    "source": "url",
-    "url": "<git-clone-url>.git"
-  },
+  "source": { "source": "url", "url": "<git-clone-url>.git" },
   "description": "<one-line description>"
 }
 ```
 
-The `source` field supports the same options as Claude Code (`url`, `github`, `git`, `file`, `directory`).
+The `source` field supports the same shapes as Claude Code (`url`, `github`, `git-subdir`, `npm`,
+`file`, `directory`) — pick per 2b, same as the Claude Code entry.
 
-### 2d. Update scenario
+### 2e. Update scenario
 
 If the plugin is already listed (this is an update), find its existing entry, update changed fields, and preserve any curator-added fields not in the standard shape. Do not overwrite `publishedAt` if present — add `"updatedAt": "<today>"` instead.
 
 Show all prepared entries to the user and ask them to confirm before proceeding.
 
+### 2f. Validate the catalogs
+
+Before moving to Step 3, run the validator against the marketplace repo's working copy (the same
+checkout the entries were just written into):
+
+```bash
+npx universal-plugin marketplace validate --root .
+```
+
+This is the same check `marketplace init`/`build` rely on — it catches an entry shape no runtime can
+load (a bad `source`, a missing required key) before it reaches a PR. Fix any reported issue and
+re-run before continuing. Do not open the PR while validation fails.
+
 ---
 
 ## Step 3: Submit PR
@@ -147,7 +232,15 @@ Use the `gh` CLI. Confirm commands that affect shared state before running.
 
 ### 3a. Get the marketplace repo locally
 
-If the user has write access (org member), work directly:
+Skip this whole step when Step 0 already found the cwd to be the marketplace location — work
+directly in it, but bring it up to date first:
+
+```bash
+git fetch origin && git merge origin/main
+```
+
+Otherwise, the marketplace repo is elsewhere and needs a working copy. If the user has write access
+(org member), work directly:
 
 ```bash
 gh repo clone cyberuni/marketplace
@@ -162,6 +255,9 @@ cd marketplace
 git fetch upstream && git merge upstream/main
 ```
 
+From here on, "the marketplace repo" means whichever of these is now the working directory —
+including the original cwd, when Step 0 found it already was the marketplace.
+
 ### 3b. Create a branch
 
 ```bash
@@ -240,6 +336,9 @@ Return the PR URL to the user when done.
 | PR rejected: missing source link | Add `homepage` or `repository` to plugin.json |
 | Name conflict in marketplace | Check existing entries in each marketplace file first |
 | Plugin loads but skills missing | Add `skills` array to the Claude Code marketplace entry |
+| Entry installs nothing for a monorepo plugin | `source` was `url`/root-clone instead of `git-subdir` — redo 2b/2c with the plugin's actual repo-relative path |
+| `marketplace validate` fails after 2f | Fix the reported shape before opening the PR — do not open it while validation fails |
+| Entry's `repository`/`source.url` points at the marketplace repo | Step 0 role detection was skipped or overridden wrongly — re-check which repo the cwd is |
 
 ---
 

package/skills/publish-plugin/evals/evals.json

@@ -18,6 +18,18 @@
 			"prompt": "My plugin 'ai-commit' is already published in the universal marketplace at version 1.0.0. I've just released v1.1.0 with some new hooks. How do I update the marketplace listing?",
 			"expected_output": "Recognizes this as an update scenario, reads existing registry entry, runs pre-flight on new version, prepares updated entry preserving existing fields (especially curator_note and original publishedAt), adds updatedAt, submits an update PR.",
 			"files": []
+		},
+		{
+			"id": 4,
+			"prompt": "My plugin 'foo' lives at packages/foo/plugin.json inside a monorepo (the repo root only has a marketplace.json catalog, no plugin.json). Publish it to cyberuni/marketplace.",
+			"expected_output": "Determines the plugin is not at the repo root and has no npm packagePath, so decides source type git-subdir rather than a root-clone url. Writes { \"source\": \"git-subdir\", \"url\": \"<clone-url>.git\", \"path\": \"packages/foo\" } in the marketplace entry. Runs marketplace validate against the marketplace working copy before opening the PR, and does not proceed if it fails.",
+			"files": []
+		},
+		{
+			"id": 5,
+			"prompt": "I'm a maintainer of cyberuni/marketplace and I already have it checked out here. I want to add a plugin called 'db-migrate' that lives at github.com/someuser/db-migrate. Add it.",
+			"expected_output": "Detects the cwd is the marketplace repo itself, not the plugin, so it reads the plugin's metadata from the given URL (cloning it to a scratch location) instead of the cwd, then works directly in the existing checkout (fetch/merge, branch, edit, commit, push, PR) rather than cloning or forking cyberuni/marketplace again. The prepared entry's source/repository URL points at db-migrate's repo, not at cyberuni/marketplace.",
+			"files": []
 		}
 	]
 }

package/skills/remove-plugin/README.md

@@ -22,7 +22,7 @@ Root `plugin.json` is never deleted as cleanup. It is the canonical source of tr
 manifest GitHub Copilot CLI reads, so removing it takes out the source and a live target at once.
 
 Dropping a vendor is a manifest edit first: deleting only the file leaves the vendor declared, and
-the next build writes it straight back. That edit routes to `init`.
+the next build writes it straight back. That edit routes to `init-universal-plugin`.
 
 Deleting a published plugin's source does not unpublish it. The skill says so rather than implying
 the removal reached consumers.

package/skills/remove-plugin/SKILL.md

@@ -49,7 +49,7 @@ Copilot CLI's search order is `.plugin/plugin.json` → `plugin.json` → `.gith
 
 Removing a vendor is a manifest edit first and a deletion second — deleting only the file leaves the
 vendor declared, and the next build writes it straight back. That edit belongs to
-`/universal-plugin:init`'s update route; come back here for the file.
+`/universal-plugin:init-universal-plugin`'s update route; come back here for the file.
 
 ## Remove the whole plugin
 
@@ -82,6 +82,6 @@ this skill does.
 
 | Task | Skill |
 |------|-------|
-| Remove a vendor from what the plugin declares | `init`, update route |
+| Remove a vendor from what the plugin declares | `init-universal-plugin`, update route |
 | Confirm what is stale, shadowing, or unbuilt before deleting | `doctor` |
 | Take a published plugin out of a marketplace listing | `publish-plugin` |

package/skills/version/SKILL.md

@@ -90,7 +90,7 @@ Every guard resolves before the first write, so a failed run leaves the tree unt
 
 | Message names | What it means | Do this |
 |---|---|---|
-| a missing `plugin.json` | not at a plugin root, or the plugin was never scaffolded | `cd` to the plugin root, or run `/universal-plugin:init` |
+| a missing `plugin.json` | not at a plugin root, or the plugin was never scaffolded | `cd` to the plugin root, or run `/universal-plugin:init-universal-plugin` |
 | no version to bump from | the manifest has never carried a `version` | pass an explicit version (`plugin version 0.1.0`) to set the first one |
 | an unknown version or release type | the argument is neither a release type nor valid semver | use one of the values in the table above |
 | a target that does not advance | the requested version is not greater than the current one | pick a higher version, or pass `--force` if the user genuinely wants to move backward |
@@ -108,7 +108,7 @@ Every guard resolves before the first write, so a failed run leaves the tree unt
 
 | Task | Skill |
 |------|-------|
-| Create, adopt, or change what the plugin declares | `init` |
+| Create, adopt, or change what the plugin declares | `init-universal-plugin` |
 | Check whether the two authored versions agree | `doctor` |
 | Add a changeset for the change being released | `add-changeset` |
 | Refresh the repository's own marketplace catalogs after a bump | `marketplace` |