Distribution: Gemini CLI Extensions blocked (no monorepo/subdir install + format mismatch) #182

Summary

Investigated Gemini CLI Extensions as a fifth distribution channel. Confirmed it is not currently viable for the canonical plugins/winui package as-is — two separate blockers, not one.

Blocker 1: no monorepo/subdirectory install support

gemini extensions install <repo-url> requires gemini-extension.json to live at the root of the git repository. There is no manifest field or CLI flag to point at a subdirectory, so a monorepo like win-dev-skills (multiple plugins under plugins/<name>/...) cannot be installed directly.

• Tracked upstream: Support installing extensions from a Git repository subdirectory google-gemini/gemini-cli#25676 ("Support installing extensions from a Git repository subdirectory") — filed with exactly our use case, auto-closed as COMPLETED on 2026-05-10 with a maintainer reply stating engineering is focused elsewhere and there are no immediate plans to address it. Not actually resolved.
• Broader ask still open: Support installing extensions from monorepo / marketplace google-gemini/gemini-cli#28428 ("Support installing extensions from monorepo / marketplace") — no committed timeline.

Blocker 2: format mismatch, not just packaging

Even if the subdirectory problem were solved, a Gemini CLI extension's gemini-extension.json is built around:

• mcpServers — extensions primarily add tools via an MCP server process, not markdown skill files
• commands/**/*.toml — custom slash-commands (TOML prompt templates)
• GEMINI.md — a single persistent context file

There is no first-class "bundle of SKILL.md-style skills" concept the way Claude Code / our agent-plugin format has. Porting plugins/winui here isn't a manifest-and-PR job like Copilot/Claude — it requires either standing up an MCP server that surfaces the workflow as tools, or rewriting the skills as TOML slash-commands + a single GEMINI.md context file. That's a real re-authoring effort, not a repackaging of the canonical adapters.

Options

1. Wait — subscribe to gemini-cli#28428, revisit once monorepo/marketplace install lands upstream, then add a thin manifest pointing at the existing package (cheapest, but no ETA).
2. Shim repo — publish a small standalone repo (root-level gemini-extension.json) just for Gemini, likely wrapping the same skill content via a lightweight MCP server. Extra repo/maintenance surface, and drifts from the "one canonical package, thin adapters" principle in MARKETPLACE-DISTRIBUTION.md.
3. Do nothing for now — treat as not-yet-viable and park it; revisit when option 1 resolves.

Recommendation

Default to option 1 (wait + track). Re-evaluate if Gemini CLI extensions gain real traction and the upstream ask remains stalled, at which point option 2 becomes worth the maintenance cost.

Relates to

• Track Agent Plugins 1.0 packaging and marketplace distribution #158 (master distribution tracking issue)
• Cursor: resolve binary-policy blocker and submit WinUI plugin #181 (Cursor — the other channel-specific blocker, same pattern)