Platform scope: should this repo extend beyond Claude Code?

[mhenke]

This repo is currently documented as a Claude Code plugin marketplace. A natural question as the project grows: should it stay scoped to Claude Code, or expand to support other IDEs and AI CLIs (e.g. Gemini CLI)?

Expanding platform support would be a meaningful directional shift — not just a technical one, but a product and governance one. It would affect naming, documentation, contribution expectations, and what counts as in-scope for new plugins and agents.

Some things worth thinking through:

• Scope clarity: A tighter scope makes it easier to maintain quality and coherence. A broader scope could attract more contributors but also more divergence.
• Abstraction cost: Supporting multiple runtimes usually requires abstraction layers that add complexity and maintenance burden.
• Naming and framing: The current README and CLAUDE.md present this as a Claude Code-specific marketplace. Multi-platform support would require revisiting that framing.
• Contribution bar: What does a cross-platform plugin look like? Does every plugin need to work everywhere, or can platform-specific plugins coexist?

No position taken here — this is an open question for the community and ultimately a call for the maintainer to make. Sharing this to surface the decision explicitly before implementation work gets ahead of it.

What are your thoughts on where the platform boundary should sit?

cc #511

[mhenke]

One data point worth considering: everything-claude-code has already tackled multi-harness support at some scale. Their tagline: "Works across Claude Code, Codex, Cursor, OpenCode, Gemini, and other AI agent harnesses."

Their FAQ entry on cross-platform compatibility gives a sense of what that support looks like in practice:

Does this work with Cursor / OpenCode / Codex / Antigravity?

Yes. ECC is cross-platform:

• Cursor: Pre-translated configs in .cursor/. See Cursor IDE Support.
• Gemini CLI: Experimental project-local support via .gemini/GEMINI.md and shared installer plumbing.
• OpenCode: Full plugin support in .opencode/. See OpenCode Support.
• Codex: First-class support for both macOS app and CLI, with adapter drift guards and SessionStart fallback. See PR #257.
• Antigravity: Tightly integrated setup for workflows, skills, and flattened rules in .agent/. See Antigravity Guide.
• Non-native harnesses: Manual fallback path for Grok and similar interfaces. See Manual Adaptation Guide.
• Claude Code: Native — this is the primary target.

Pointing this out not as an argument for or against expanding scope here, but as evidence that the abstraction cost is real and solvable — and that the design decisions involved (per-harness config dirs, drift guards, fallback paths) are non-trivial. Worth knowing what approaches exist before deciding whether to take them on.

[Keesan12]

One pattern that has felt workable for us is separating the runtime-specific surface from the governance contract.

The runtime-specific part answers things like:

• which CLI or IDE harness is being driven
• what install/auth path it needs
• what adapter glue exists today versus later

The governance contract stays much more stable:

• budget envelope
• verifier plan
• stop reason
• persisted run record / audit trail

That is why I’m sympathetic to broader platform support, but only if the repo keeps the adapter boundary explicit. Otherwise the abstraction cost leaks everywhere.

A practical middle ground might be:

• keep the primary framing honest about the current native target
• allow platform-specific contributions to coexist
• standardize the contract around what every runtime has to honor once it is inside the system

That keeps scope creep lower than "everything must work everywhere," but it still leaves room for the ecosystem to grow beyond a single harness.

[wshobson]

Hey @mhenke, thanks for surfacing this explicitly — and apologies for the late reply. The directional call has actually been made and is now shipped, so I'll catch this thread up to where the code is.

Position: yes, multi-harness, but with an explicit adapter boundary. The May refactor (PRs #541 and #542) shipped:

• Single source of truth under plugins/<name>/ — agents, skills, and commands authored once
• Per-harness adapters in tools/adapters/ that emit Codex, Cursor, OpenCode, and Gemini artifacts from that single source (see docs/harnesses.md for the capability matrix and ARCHITECTURE.md for the design)
• AGENTS.md is now the canonical context file — Claude Code reads it via @AGENTS.md import, Codex/Cursor/OpenCode read it directly, Gemini reads it via .gemini/settings.json

On @Keesan12's framing — splitting "runtime-specific surface" from "governance contract" is essentially what the adapter framework does. The adapter boundary is mechanical (frontmatter shape, tool name remapping, output path), and the contract — what every plugin must honor — is enforced by plugin-eval plus make validate STRICT=1. That keeps the abstraction cost localized to ~5 files under tools/adapters/ rather than leaking into every plugin.

On your specific questions:

• Scope clarity — Claude Code is still the native source of truth; other harnesses are downstream consumers of generated artifacts. That keeps the contribution model simple.
• Abstraction cost — bounded to the adapter layer. Plugin authors write Claude Code conventions; the adapters translate.
• Naming/framing — README and AGENTS.md were updated as part of the refactor.
• Contribution bar — every plugin works on every harness via the adapters; plugins don't need to be multi-harness-aware. If a plugin uses a feature without an equivalent (e.g. hooks on a harness that doesn't support them), the harness_portability lint surfaces it.

Happy to discuss further if there are gaps in how this is documented.