universal-plugin 0.6.0 → 0.8.0

package/skills/init-universal-plugin/references/adopt.md

@@ -0,0 +1,206 @@
+# Adopt the open standard
+
+Convert something that is *already* a plugin — or already ships skills — onto the canonical
+Agent Plugins Specification manifest, without changing what it does.
+
+Two starting shapes land here:
+
+- **A vendor-specific plugin** — it has one or more hand-written vendor manifests
+  (`.claude-plugin/plugin.json`, `.cursor-plugin/plugin.json`, …) and no canonical root
+  `plugin.json`.
+- **Bare public skills** — it ships `skills/<name>/SKILL.md` to users but has no plugin manifest of
+  any kind.
+
+Adoption is **lossless by contract**: every vendor that worked before must still work after. Step 6
+is the check that proves it — do not skip it.
+
+## Step 0 — Confirm the user wants this
+
+This is the skill's Phase 3 gate, and adoption always needs it: adoption rewrites the project's
+manifest layout and turns hand-written vendor manifests into generated artifacts. Say that plainly
+and get agreement before touching files. If the user declines,
+route back to whatever they originally asked for.
+
+Also confirm the working tree is clean (`git status`). The Step 6 diff is worthless if uncommitted
+changes are mixed in.
+
+## Step 1 — Inventory what exists
+
+```bash
+ls -d .claude-plugin .cursor-plugin .codex-plugin .github/plugin .plugin 2>/dev/null
+test -f plugin.json && cat plugin.json
+find . -name SKILL.md -not -path '*/node_modules/*' -not -path './.git/*'
+ls .mcp.json .lsp.json hooks/ commands/ agents/ rules/ output-styles/ 2>/dev/null
+```
+
+Record, for each vendor manifest found: its path, and every field it sets. You are about to
+reproduce all of it.
+
+**If a root `plugin.json` already exists**, read it before assuming anything. It is either the
+canonical manifest (has `$schema` pointing at `agent-plugins.org` and an `extensions` object — in
+which case there is nothing to adopt; route to `update.md`, or hand off to `doctor`, instead), or a legacy
+Copilot CLI manifest that now collides with the canonical path and must be folded in.
+
+## Step 2 — Sort every field into shared, vendor-specific, and undeliverable
+
+Build three buckets from the manifests you inventoried:
+
+- **Shared metadata** — the canonical top level is a **closed** set of exactly ten fields:
+  `$schema`, `name`, `version`, `description`, `author`, `homepage`, `repository`, `license`,
+  `keywords`, `extensions`. A field in that list stays at the top level. That set is the upstream
+  spec's, not this project's — see
+  [the published schema](https://agent-plugins.org/schemas/1.0.0/plugin.schema.json).
+- **Vendor-specific** — anything only one runtime understands (Cursor's `publisher`/`category`/
+  `tags`, Codex's `interface`). These go under
+  `extensions["org.cyberuni.universal-plugin"].harnesses.<vendor>`. The component paths
+  (`skills`, `commands`, `agents`, `hooks`, `mcpServers`, `rules`, `lspServers`, `outputStyles`)
+  are not top-level either — they go under that same extension namespace, one level up from
+  `harnesses`.
+- **Undeliverable** — a field whose only consumer is Copilot CLI. Copilot CLI reads the canonical
+  root manifest directly and gets no derived file, so such a field has no home on either side: the
+  closed schema rejects it at the top level, and a `harnesses["copilot-cli"]` entry is never
+  written anywhere. Before dropping one, check
+  [`vendors/copilot-cli.md`](./vendors/copilot-cli.md) — the two fields that actually turn up here,
+  `category` and `tags`, have a spec-conformant home (`keywords`) and are not a loss.
+
+Where two vendor manifests disagree on a shared field, **ask the user** which value is canonical
+rather than picking one. A silent choice here is a silent behavior change for one of their runtimes.
+
+### Name every field you are about to drop
+
+A legacy root `plugin.json` is what makes the third bucket real. Before 0.6 the build wrote
+Copilot CLI's output *to root*, so root carries whatever Copilot-specific fields the project set —
+`category` and `tags` are the ones seen in the wild. After adoption root is the canonical manifest
+and those fields have nowhere to go.
+
+Nothing warns about this. The build's `undeliverable-override` warning and `doctor`'s matching
+finding fire only on a `harnesses["copilot-cli"]` entry — which is what someone doing it *wrong*
+writes. An adoption done correctly never creates one, so it gets silence. Enumerate the fields
+yourself, from the pre-adoption root manifest, before you overwrite it:
+
+```bash
+node -e '
+  const spec = ["$schema", "name", "version", "description", "author",
+                "homepage", "repository", "license", "keywords", "extensions"]
+  const root = JSON.parse(require("node:fs").readFileSync("plugin.json", "utf8"))
+  for (const k of Object.keys(root)) {
+    if (!spec.includes(k)) console.log(k, "=", JSON.stringify(root[k]))
+  }
+'
+```
+
+Every name it prints is a field the canonical top level cannot hold. Sort each one:
+
+| The field | Where it goes |
+| --- | --- |
+| `vendorExtensions` — the whole pre-0.6 block | `extensions["org.cyberuni.universal-plugin"].harnesses` — **renamed, not dropped** |
+| a component path (`skills`, `commands`, `agents`, …) | `extensions["org.cyberuni.universal-plugin"].<name>` — carried |
+| a field a vendor with a *derived* manifest understands | that vendor's `harnesses` entry — carried |
+| `category` / `tags` from the legacy Copilot output | fold into **`keywords`** — see below |
+| anything left | **dropped** |
+
+`vendorExtensions` is the row that catches people out, because the snippet prints it alongside the
+genuinely undeliverable fields and it looks like one of them. It is not: it is the old name for
+`harnesses`, and dropping it discards every per-harness override the project had. Carry the block
+across, then sort the `copilot-cli` entry inside it by the rule above — that entry is the one whose
+contents have no delivery path.
+
+`plugin build` will not let this one pass quietly: a root manifest still carrying `vendorExtensions`
+now exits 1 rather than reporting `built 0`, naming the signal and routing to `doctor`. If Step 5
+fails that way, the block did not get carried across.
+
+`category` and `tags` have their own row because they are the fields this whole step exists for, and
+they are **not** simply dropped. Copilot CLI has no `plugin.json` handling for either — its manifest
+validator knows `keywords` and treats these two as unknown-and-ignored — while `keywords` is both a
+spec field and the one Copilot actually parses. So fold the values in rather than deleting them:
+
+```
+category: "productivity" + tags: ["workflow", "planning", "verification"]
+  → keywords: ["productivity", "workflow", "planning", "verification"]
+```
+
+If the project also ships a `marketplace.json` catalog, `category` and `tags` are real fields on a
+catalog entry and belong there as well — with the right types, because a wrong one is a fatal browse
+error rather than a warning. [`vendors/copilot-cli.md`](./vendors/copilot-cli.md) has the evidence
+and the exact validator messages.
+
+**Report anything genuinely dropped to the user by name, with the value each held, before Step 3
+writes anything.** That report is the only notice they get, and it is the difference between an informed
+decision and a field that evaporates. Say what the field was for if you know; if a field looks load-
+bearing and the user wants it kept, stop rather than shipping the adoption around it.
+
+## Step 3 — Write the canonical manifest
+
+Scaffold it, naming exactly the vendors you found in Step 1:
+
+```bash
+node scripts/init.mjs --name <name> --vendor claude-code --vendor cursor
+```
+
+Resolve `scripts/init.mjs` against this skill's directory; `npx universal-plugin plugin init` is the
+fallback.
+
+> `plugin init` writes a **minimal** manifest — `$schema`, `name`, and the `vendors` list. It does
+> not read your existing vendor manifests. Carry the Step 2 buckets in by hand afterwards.
+
+Then fill in the shared metadata and `harnesses` as laid out in
+[`create.md`](./create.md) Step 5. Point the component paths at the directories that already exist —
+adoption must not move files.
+
+For the bare-public-skills case there is no metadata to carry over; supply `name`, `description`,
+and `version`, set `"skills": "./skills/"`, and choose vendors with the user (see
+[`create.md`](./create.md) Step 2).
+
+## Step 4 — Decide what happens to the old manifests
+
+The vendor manifests are now **build outputs**. They stay at the same paths, but they are
+regenerated rather than edited.
+
+- Commit them as-is first, so Step 6 has a baseline to diff against.
+- Tell the user they are generated from here on, and that hand-edits will be overwritten by
+  `plugin build`.
+- If the project has a legacy root `plugin.json` for Copilot CLI, that path is now the canonical
+  manifest. Copilot CLI gets no replacement file: it reads root directly, so the canonical manifest
+  *is* its manifest from here on. See the vendor output table in [`create.md`](./create.md) Step 2.
+
+## Step 5 — Build
+
+```bash
+npx universal-plugin plugin build
+```
+
+## Step 6 — Prove it was lossless
+
+This is the point of the whole procedure.
+
+```bash
+git diff -- plugin.json .claude-plugin .cursor-plugin .codex-plugin .github/plugin
+```
+
+Root `plugin.json` is in that list on purpose, and it is the one path that behaves differently from
+the other four.
+
+- For `.claude-plugin`, `.cursor-plugin`, `.codex-plugin`, and `.github/plugin`, expect only
+  formatting and key-order churn. A hunk that changes a value is a finding.
+- For root `plugin.json`, **expect real hunks** — the `$schema` line and the `extensions` object are
+  new, and the component paths moved under them. That is the rewrite working. Because the diff is
+  large by design it is the easy one to skim, and under the legacy layout root *was* a vendor
+  manifest — Copilot CLI's — so it is also the only file where a field can go missing without any
+  other check noticing. Read it, do not skim it.
+
+Account for **every key that leaves root**. Each one must land in exactly one of three places: at the
+canonical top level, under `extensions`, or on the dropped list you enumerated and reported in
+Step 2. A key that left root and is on none of those three is a regression.
+
+**Any field that disappeared unannounced is a regression**, not a cleanup. Trace it back: either it
+belongs in the shared metadata, or it belongs in that vendor's `harnesses` entry, or it is a field
+the build does not yet support — in which case stop and tell the user rather than shipping a quiet
+capability loss.
+
+Then confirm the plugin still loads. See [`create.md`](./create.md) Step 8 for local install.
+
+## Step 7 — Hand off
+
+- Audit the skills: [`create.md`](./create.md) Step 6.
+- Shipping it on npm? → `migrate-plugin`.
+- Listing it in the marketplace? → `publish-plugin`.

package/skills/{init → init-universal-plugin}/references/detection.md

@@ -15,13 +15,19 @@ ls .mcp.json .lsp.json hooks/ commands/ agents/ rules/ output-styles/ 2>/dev/nul
 | `.claude-plugin/`, `.cursor-plugin/`, `.codex-plugin/` manifest **below** a canonical root | build output | derived |
 | a vendor manifest with **no** canonical root `plugin.json` | a vendor-specific plugin | adoptable |
 | root `plugin.json` with neither `$schema` nor `extensions` | a legacy single-vendor manifest now sitting on the canonical path | adoptable |
+| a top-level `vendorExtensions` block | the pre-0.6 name for `harnesses`; `plugin build` exits 1 on it | adoptable — carry the block, do not drop it |
 | publicly-shipped skills and no manifest of any kind | skills shipped without a plugin | adoptable |
 | `harnesses["copilot-cli"]` carrying fields | no delivery path — the canonical schema is closed | undeliverable |
+| a non-spec field on a legacy root `plugin.json` (`category`, `tags`, …) | it was Copilot CLI's, and Copilot CLI has no derived manifest to move it to | undeliverable — and **nothing warns**; name it in Phase 3 |
 | `.claude/skills/`, `.agents/skills/`, `.cursor/rules/` | the project's own tooling | not a plugin |
 | `.github/plugin/plugin.json` | a path older builds wrote; shadowed by root and no longer generated | stale, safe to delete |
 
-For every vendor manifest found, record its path and **every field it sets**. Adoption reproduces
-all of it, and the Phase 5 diff is checked field by field.
+For every vendor manifest found, record its path and **every field it sets** — root `plugin.json`
+included, when it is the legacy kind. Adoption reproduces all of it, and the Phase 5 diff is checked
+field by field. The canonical top level accepts exactly ten fields (`$schema`, `name`, `version`,
+`description`, `author`, `homepage`, `repository`, `license`, `keywords`, `extensions`); everything
+else either moves under `extensions` or is dropped, and
+[`adopt.md`](./adopt.md) Step 2 is where you sort out which.
 
 ## Which skills count as public
 

package/skills/{init → init-universal-plugin}/references/standard.md

@@ -36,10 +36,14 @@ lives under one namespaced key, `extensions["org.cyberuni.universal-plugin"]`:
 | --- | --- |
 | `vendors` | the build targets. When absent, the `harnesses` keys are the targets |
 | `harnesses` | per-vendor overrides, keyed by vendor id. `{}` opts in with no overrides |
-| `packagePath` | the npm package whose `package.json` carries the same version |
 | component paths (`skills`, `commands`, `agents`, `hooks`, …) | where each component lives |
 | `dependencies` | the plugins this plugin needs. Only Claude Code reads them; see [`vendors/claude-code.md`](./vendors/claude-code.md) |
 
+`packagePath` does not belong here. The npm package whose `package.json` carries the same version is
+named in `.agents/universal-plugin.json` beside `plugin.json`, as a path relative to the plugin root
+(for example `"packagePath": "."`, or `"../../packages/<name>"` in a monorepo). It is release config
+for the repository, not part of the manifest.
+
 `vendors` and `harnesses` are separate on purpose: `vendors` says what to build, `harnesses` says
 what each build gets. A vendor listed in `vendors` with no `harnesses` entry still builds; a
 `harnesses` entry with no `vendors` list builds only while `vendors` is absent.

package/skills/{init → init-universal-plugin}/references/vendors/claude-code.md

@@ -10,7 +10,7 @@ npx universal-plugin plugin build --vendor claude-code
 
 The shared metadata from the canonical top level, plus the component paths, plus whatever
 `extensions["org.cyberuni.universal-plugin"].harnesses["claude-code"]` sets. `$schema`, `extensions`,
-`vendors`, `packagePath`, and `harnesses` are universal-plugin's own orchestration — they never
+`vendors`, and `harnesses` are universal-plugin's own orchestration — they never
 appear in a vendor manifest.
 
 An empty `"claude-code": {}` is the normal case: it opts into the build with no overrides.

package/skills/init-universal-plugin/references/vendors/copilot-cli.md

@@ -0,0 +1,201 @@
+# GitHub Copilot CLI
+
+Reads the **canonical root `plugin.json` directly**, so the build derives no vendor manifest for it.
+It does derive its **components** — see [`com.github.copilot/` — the namespace directory](#comgithubcopilot--the-namespace-directory).
+A plugin declaring none of the moved kinds is reported with status `canonical`, which is success, not
+a skipped target.
+
+## Why no manifest is derived
+
+Copilot CLI searches four paths and takes the first match:
+
+```
+.plugin/plugin.json → plugin.json → .github/plugin/plugin.json → .claude-plugin/plugin.json
+```
+
+Root `plugin.json` — the canonical manifest — is second, so it always shadows the two below it. It
+has consumed Open Plugin Spec v1 manifests since **v1.0.74** (2026-07-23, [changelog](https://github.com/github/copilot-cli/blob/main/changelog.md):
+"Add support for Open Plugin Spec v1 plugin manifests and mcp.json configuration"), so it already
+serves the canonical manifest as-is.
+
+Earlier builds wrote `.github/plugin/plugin.json`. That path loses to root by construction and was
+never read; a leftover copy is stale and safe to delete.
+
+## Vendor-specific fields cannot be delivered
+
+A `harnesses["copilot-cli"]` entry has nowhere to go. The canonical schema is closed
+(`additionalProperties: false`), so a Copilot-only field cannot ride along in root, and there is no
+derived file to put it in. The build warns:
+
+```
+harnesses.copilot-cli sets category, tags, but copilot-cli reads the canonical plugin.json
+directly — these fields are not delivered
+```
+
+Treat that warning as a decision to make, not noise: either the field belongs to a vendor that has a
+derived manifest, or it does not ship. Do not invent a path for it.
+
+## `category` and `tags` belong to the catalog, not the manifest
+
+A project on the pre-0.6 layout carries these on its **root** `plugin.json`, because root *was*
+Copilot CLI's derived output. Adoption drops them from there, and that loses nothing — but not for
+the reason the field table suggests.
+
+**Copilot CLI has no `plugin.json` handling for either field.** Verified against the shipped
+`@github/copilot-linux-x64` **1.0.83** runtime (the plugin loader is Rust in
+`prebuilds/*/runtime.node`, not the bundled JS), and confirmed by running the binary. The manifest
+validator carries a dedicated message for `keywords` and none for `category` or `tags`; both land on
+the unknown-field path:
+
+```
+Plugin manifest "…": field "keywords" must be an array of strings (ignored)
+Plugin manifest "…": unknown field "…" (ignored)
+```
+
+Unknown keys are **warn-and-ignore**: not rejected, not stripped from disk, dropped from the parsed
+struct. A manifest carrying `category`, `tags`, and an outright bogus key installs cleanly with no
+output about any of them. GitHub's published field table lists `category`/`tags` under the
+`plugin.json` optional metadata fields anyway — as of 1.0.83 that part of the table does not match
+the shipped loader.
+
+**Where they are real is `marketplace.json`.** The catalog validator type-checks both on every
+`plugins[]` entry, and a wrong type is a *fatal* browse failure, not a warning:
+
+```
+Failed to browse marketplace: Invalid marketplace.json:
+  plugins.0.category: Expected string, received number,
+  plugins.0.tags: Expected array, received string
+```
+
+With valid values, nothing renders them — `marketplace browse` prints only `name` and `description`,
+and `plugins list --json` emits neither field, nor `keywords`. No list, search, sort, or filter in
+the CLI touches any of them. GitHub's own marketplace (`github/copilot-plugins`, 17 curated entries)
+sets `category` and `tags` zero times while populating `keywords` on 15 of 17.
+
+### So where does a migrating project put them
+
+| Was | Goes |
+| --- | --- |
+| `category` / `tags` on root `plugin.json` | fold into **`keywords`** — a spec field, in the closed set, and the one Copilot's manifest validator actually knows |
+| the same values for marketplace discovery | the **catalog entry** in `marketplace.json`, where Copilot defines them |
+
+Do not build a delivery path for these into the plugin manifest. There is nothing at the other end.
+
+### Still open
+
+- **Where the `unknown field (ignored)` warning surfaces.** It exists in the binary but reached no
+  output on `plugin install`, `plugin list`, or `plugins list`. Likely the interactive dashboard or
+  the session config-problems channel.
+- **The full known-field allow-list for `plugin.json`.** The validator's field set is a Rust const
+  array in a stripped binary; only fields with dedicated messages are recoverable. The negative is
+  solid — neither `category` nor `tags` has any handling — but the positive list is not.
+- **Server-side catalog search.** The runtime carries a remote catalog client with a `canSearch`
+  capability. Whether GitHub's hosted catalog indexes `category`/`tags` is outside what the shipped
+  code can answer, and it would be indexing `marketplace.json`, not a plugin manifest.
+- **Extension, command, rule, and hook loading from the namespace directory** (below) was not
+  observed directly — only agents were proven by experiment. The rest rests on GitHub's GA post.
+
+### Sources
+
+- Shipped runtime: `@github/copilot-linux-x64` 1.0.83, `prebuilds/linux-x64/runtime.node`; validator
+  strings and live `plugin install` / `marketplace browse` / `plugins list --json` runs.
+- Copilot CLI plugin reference (the field table this contradicts):
+  https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference
+- GitHub's own catalog: https://github.com/github/copilot-plugins `.github/plugin/marketplace.json`
+- Agent Plugins Specification v1.0.0 §8 (`extensions` is the sanctioned channel for non-spec data)
+  and the closed field set: https://agent-plugins.org/schemas/1.0.0/plugin.schema.json
+
+## `com.github.copilot/` — the namespace directory
+
+Declaring the canonical `$schema` puts a plugin in **spec mode**, and spec mode changes where
+Copilot CLI looks for its *native* components. They move out of the plugin root and into a
+reverse-domain directory that other runtimes ignore by design:
+
+```
+com.github.copilot/agents/  commands/  rules/  hooks  extensions/
+```
+
+Spec components stay where the spec puts them: `skills/` and `mcp.json` remain at the plugin root.
+Only Copilot-native kinds move. `extensions/` — canvas extensions, added in **1.0.79**
+(2026-08-10) — is one subdirectory of it.
+
+The directory pairs with the manifest key of the same name: `com.github.copilot/` carries Copilot's
+*files*, `extensions["com.github.copilot"]` carries Copilot's *data* (§8). Same namespace, two
+surfaces.
+
+**This is a real delivery path, and it narrows the rule above.** "A Copilot-only field has nowhere
+to go" still holds for **manifest fields** — the canonical schema is closed and that argument is
+untouched. It does **not** hold for **content**: Copilot-specific agents, commands, rules, and hooks
+have a sanctioned home, and `extensions["com.github.copilot"]` is the right place for Copilot
+metadata.
+
+The list above is the shape; these are the exact paths, and `lsp.json` belongs on it too:
+
+| Component | Spec-mode path | Root still read |
+| --- | --- | --- |
+| agents | `com.github.copilot/agents/` | no |
+| commands | `com.github.copilot/commands/` | no |
+| rules | `com.github.copilot/rules/` | no |
+| hooks | `com.github.copilot/hooks/hooks.json` | no |
+| LSP servers | `com.github.copilot/lsp.json` | no |
+| extensions (canvases) | `com.github.copilot/extensions/` | never had a root path |
+| skills | `skills/` | **yes — does not move** |
+| MCP servers | `mcp.json` | **yes — does not move** |
+
+The namespace **replaces** the root rather than supplementing it, and an explicit component path in
+the manifest does **not** opt back into root loading. The move landed in **1.0.80-0** and the
+runtime's own changelog labels it breaking. Evidence and its confidence, including which kinds were
+proven by experiment:
+[`.research/copilot-spec-mode-namespace/`](../../../../../../.research/copilot-spec-mode-namespace/conclusion.md).
+The published CLI plugin reference still says spec support is "additive on top of standard plugin
+loading" and documents only the root layout — it is stale; do not build against it.
+
+### What the build derives
+
+`plugin build` derives the tree ([ADR-0015](../../../../.agents/spec/design/decisions/0015-copilot-spec-mode-namespace.md)),
+so **authoring stays at the canonical locations**:
+
+- `agents`, `commands` and `rules` are copied, resolved through the same `pathValue` contract
+  `skills` uses, defaults included.
+- Agents are **renamed** on the way. Copilot CLI reads `agents/` as `.agent.md` files while the
+  canonical `agents/` is the Claude Code-shaped `*.md`, so a copy under the authored name would land
+  a file the runtime ignores. Commands and rules keep their authored names — the runtime documents no
+  extension for either.
+- Hooks are **translated** into `com.github.copilot/hooks/hooks.json`, so a handler Copilot CLI
+  cannot run is dropped from that file with a warning rather than reported as ignored at runtime.
+- A declared `lspServers` **path** is copied to `com.github.copilot/lsp.json`. An **inline** map is
+  not delivered: the file's top-level shape is undocumented, so the build warns instead of composing
+  one.
+- `com.github.copilot/extensions/` is the inverse — authored there, never derived, and left alone by
+  `--clean`.
+
+The vendor reports `built` at `com.github.copilot/` when it derives any of this, and keeps reporting
+`canonical` at `plugin.json` when the plugin declares none of the moved kinds.
+
+## Do not
+
+- **Do not delete root `plugin.json` to "clean up" a Copilot target.** It is the source of truth and
+  the Copilot manifest at once.
+- Do not write `.plugin/plugin.json`. It outranks root, so it would silently shadow the canonical
+  manifest with a copy nothing regenerates. `plugin build` names it as a pre-0.6 signal and exits 1 —
+  but only when nothing derived at all. A project whose other harnesses still build keeps the shadow
+  and gets no warning, so this stays a rule you follow rather than one the tool enforces.
+- **Do not tell an author to move `agents/` into `com.github.copilot/`.** The root copy is the
+  canonical input every other vendor derives from; the namespace is a build output. Moving it
+  serves Copilot and strands the other three.
+- **Do not hand-write the namespace directory.** `--clean` replaces everything the build derives
+  under it. `extensions/` is the one subtree it leaves alone, and the only one to author there.
+
+## Hooks
+
+Copilot CLI accepts **either casing**, and the casing selects the payload format: PascalCase gets the
+Claude-compatible format, so the canonical file needs no translation. It is written to
+`com.github.copilot/hooks/hooks.json` all the same, because that is where spec mode reads it — so a
+handler Copilot CLI cannot run is **dropped from that derived file** with a warning, like any other
+vendor's. See [`claude-code.md`](./claude-code.md).
+
+## Dependencies
+
+Copilot CLI reads no plugin dependency. Because it reads the canonical *manifest* directly, there is
+no derived manifest to leave the declaration out of — it sits under `extensions`, which Copilot CLI ignores,
+and the build reports it as ignored at runtime. See [`claude-code.md`](./claude-code.md).

package/skills/marketplace/SKILL.md

@@ -195,7 +195,7 @@ a version the plugin does not have.
 
 | Task | Skill |
 |------|-------|
-| Create or change the plugin being listed | `init` |
+| Create or change the plugin being listed | `init-universal-plugin` |
 | Check that the plugin's own manifests are current | `doctor` |
 | Move the version users will install | `version` |
 | Submit to the shared marketplace repository instead | `publish-plugin` |