---
title: "Native Plugin Install Strategy"
description: "Last verified: 2026-04-19"
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/native-plugin-install-strategy-2026-04-19
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:31:17.872Z
license: CC-BY-4.0
attribution: "Native Plugin Install Strategy — Claudary (https://claudary.paisolsolutions.com/skills/native-plugin-install-strategy-2026-04-19)"
---

# Native Plugin Install Strategy
Last verified: 2026-04-19

## Overview

---
title: "Native plugin install strategy for supported harnesses"
date: 2026-04-19
category: integrations
module: installer
problem_type: integration_decision
component: installer
symptoms:
  - "Multiple harnesses can discover the same CE skills from shared roots and create duplicates or shadowing"
  - "Some harnesses now support native Claude-compatible plugin installs, making custom Bun installs redundant"
  - "Old manual installs can leave stale skills and agents after CE renames or deprecations"
root_cause: evolving_platform_install_surfaces
resolution_type: install_strategy
severity: medium
tags:
  - install-strategy
  - native-plugins
  - legacy-cleanup
  - cursor
  - codex
  - copilot
  - droid
  - qwen
  - gemini
  - opencode
  - kiro
---

# Native Plugin Install Strategy

Last verified: 2026-04-19

This document records the intended install model by harness. The current priority is separating native marketplace installs from custom Bun installs so CE does not create duplicate or shadowing skills across tools.

## Summary

| Harness | Intended install path | Custom Bun install? | Legacy cleanup needed? | Notes |
| --- | --- | --- | --- | --- |
| Claude Code | Native plugin marketplace using existing `.claude-plugin/marketplace.json` and `plugins/compound-engineering/.claude-plugin/plugin.json` | No | Only for old/manual non-native installs, if any | Current repo shape already satisfies Claude Code. |
| Cursor | Native Cursor Plugin Marketplace using existing `.cursor-plugin/marketplace.json` and `plugins/compound-engineering/.cursor-plugin/plugin.json` | No, CE plugin install/convert target removed | No for marketplace installs; add targeted cleanup only if historical custom Cursor artifacts are confirmed | Users install from Cursor Agent chat with `/add-plugin compound-engineering` or by searching the plugin marketplace. |
| GitHub Copilot CLI | Native plugin marketplace using the same existing `.claude-plugin` metadata | No, CE plugin install/convert target removed | Yes, before or during migration from previous `.github/` custom installs | Tested manually: Copilot can install from the existing CE marketplace and load agents. |
| Factory Droid | Native plugin marketplace pointed at the CE GitHub repository | No, CE plugin install/convert target removed | Yes, before or during migration from previous `~/.factory` custom installs | Droid docs say Claude Code plugins install directly and are translated automatically; `ce-doc-review` was manually tested in Droid. |
| Qwen Code | Native extension install from the CE GitHub repository and existing Claude plugin metadata | No, CE plugin install/convert target removed | Yes, before or during migration from previous `~/.qwen` custom installs | Qwen docs say Claude Code extensions install directly from GitHub and are converted automatically; native install was manually tested on 2026-04-19. |
| OpenCode | Custom CE install to `~/.config/opencode/{skills,agents,plugins}` plus merged `opencode.json`; source commands are written only if present | Yes | Yes, every install | OpenCode plugins are JS/TS or npm hooks/tools, not a Claude-compatible marketplace install path for CE's full plugin payload. |
| Pi | Custom CE install to `~/.pi/agent/{skills,prompts,extensions}` plus MCPorter config; source commands are written only if present | Yes, until CE ships and tests a Pi package | Yes, every install | Pi has package install support, but CE has not yet packaged the compat extension, generated skills, prompts, and MCPorter config into a tested Pi package. |
| Codex | Custom CE install to `~/.codex/skills/compound-engineering/<skill>` and `~/.codex/agents/compound-engineering/<agent>.toml` | Yes, because native Codex plugins do not currently register bundled custom agents | Yes, every install | Avoid `~/.agents/skills` so Codex installs do not shadow Copilot's native plugin skills. Claude agents are converted to Codex TOML custom agents. |
| Gemini CLI | Custom CE install to `~/.gemini/{skills,agents}` for now; source commands are written only if present; native extension packaging exists but does not fit CE's current repo/package layout | Yes, until CE ships a Gemini extension root, release artifact, or dedicated distribution branch/repo | Yes, every install | Avoid `~/.agents/skills`; write normalized Gemini agents to `~/.gemini/agents`. |
| Kiro CLI | Custom CE install to project `.kiro/{skills,agents,steering,settings}` | Yes | Yes, every install; manual `cleanup --target kiro` also exists | Kiro has its own JSON agent format and project-local install root. |

Deprecated targets:

- Windsurf is no longer an active CE install, convert, or sync target. `cleanup --target windsurf` remains available only to back up old CE-owned files from previous Bun installs under `~/.codeium/windsurf/` or workspace `.windsurf/`.

Removed capabilities:

- Personal Claude Code home sync (`bunx @every-env/compound-plugin sync`) has been removed. Syncing arbitrary `~/.claude` skills, commands, agents, and MCP config across unrelated harnesses is not a bounded compatibility surface; CE only supports installing the CE plugin and cleaning up old CE-owned artifacts.

Current CE command posture:

- The `compound-engineering` plugin currently ships no Claude `commands/` files. Its workflow entry points are skills invoked with slash syntax, such as `/ce-plan`, `/ce-work`, and `/ce-doc-review`.
- The CLI still understands source plugin commands for legacy cleanup and for converting non-CE Claude plugins that still ship commands. CE install docs should not describe commands as part of the current CE payload except as legacy/source-plugin compatibility.

## Global Decision: Avoid `~/.agents` For CE-Owned Installs

Do not install CE-owned skills or agents into `~/.agents` for normal target installs.

Several harnesses read `~/.agents/skills`, but Copilot CLI gives personal/project skill roots precedence over plugin skills. A CE skill written for Codex, Gemini, Pi, or another target into `~/.agents/skills` can silently shadow the same skill from Copilot's native plugin install. That makes `~/.agents` unsafe as a shared CE-managed install root.

Use target-owned roots instead:

```text
OpenCode: ~/.config/opencode/skills/<skill>/SKILL.md
          ~/.config/opencode/agents/<agent>.md
          ~/.config/opencode/commands/*.md  # source commands only, if present
          ~/.config/opencode/opencode.json

Pi:       ~/.pi/agent/skills/<skill>/SKILL.md
          ~/.pi/agent/prompts/*.md  # source commands only, if present
          ~/.pi/agent/extensions/*.ts
          ~/.pi/agent/compound-engineering/mcporter.json

Codex:  ~/.codex/skills/compound-engineering/<skill>/SKILL.md
        ~/.codex/agents/compound-engineering/<agent>.toml

Gemini: ~/.gemini/skills/<skill>/SKILL.md
        ~/.gemini/agents/<agent>.md
        ~/.gemini/commands/*.toml  # source commands only, if present

Copilot: managed by native plugin install under ~/.copilot
Cursor:  managed by native Cursor Plugin Marketplace install
Droid:   managed by native plugin install under ~/.factory for user scope
Qwen:    managed by native extension install under ~/.qwen
```

`~/.agents/skills` remains a cleanup target only, because prior CE installs or experiments may have left shadowing skills there.

## Claude Code

### Decision

Claude Code is already satisfied by the current repo layout:

- Root marketplace: `.claude-plugin/marketplace.json`
- Plugin root: `plugins/compound-engineering/`
- Plugin manifest: `plugins/compound-engineering/.claude-plugin/plugin.json`
- Plugin components: `agents/`, `skills/`, and related files under the plugin root. Claude `commands/` would be supported if reintroduced, but CE does not currently ship them.

Users install with:

```text
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering
```

No custom Bun install or conversion should be used for Claude Code.

### Cleanup

Native Claude plugin installs are owned by Claude Code. The CE cleanup command should not delete Claude Code's plugin cache. It should only handle explicitly known old/manual CE artifacts if we discover any historical non-native Claude install path.

## Cursor

### Decision

Cursor should use the native Cursor Plugin Marketplace, not `bunx @every-env/compound-plugin install compound-engineering --to cursor`.
The custom Cursor plugin install/convert target has been removed from the CLI target registry.

The repo publishes Cursor marketplace metadata separately from the Claude marketplace:

- Root marketplace: `.cursor-plugin/marketplace.json`
- Plugin manifest: `plugins/compound-engineering/.cursor-plugin/plugin.json`

Users install from Cursor Agent chat with:

```text
/add-plugin compound-engineering
```

They can also search for "compound engineering" in the plugin marketplace.

No custom Bun install or conversion should be used for Cursor.

### Cleanup

Cursor marketplace installs are owned by Cursor. CE should not delete Cursor's plugin marketplace cache.

If we discover historical CE-owned Cursor artifacts from the old custom writer that can shadow marketplace installs, add a targeted cleanup path for those known artifacts. Do not reintroduce Cursor as an active `convert` or `install` target.

## GitHub Copilot CLI

### Decision

Copilot should use native plugin install, not `bunx @every-env/compound-plugin install compound-engineering --to copilot`.
The custom Copilot plugin install/convert target has been removed from the CLI target registry.

Copilot CLI can read:

- Marketplace manifests from `.claude-plugin/marketplace.json`
- Plugin manifests from `.claude-plugin/plugin.json`
- Plugin agents from the plugin `agents/` directory
- Plugin skills from the plugin `skills/` directory

Users install inside Copilot CLI with:

```text
/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering@compound-engineering-plugin
```

Shell equivalents:

```bash
copilot plugin marketplace add EveryInc/compound-engineering-plugin
copilot plugin install compound-engineering@compound-engineering-plugin
```

Do not add a parallel `.github/plugin/marketplace.json`, `.github/plugin/plugin.json`, or generated `agents-copilot/` directory unless a real compatibility failure appears. Manual testing showed Copilot can install from the existing CE marketplace and load CE agents.

Copilot skill conflicts are not displayed like Codex duplicate skills. Copilot deduplicates skills by the `name` field in `SKILL.md` using first-found-wins precedence. Project and personal skill locations, including `~/.agents/skills`, load before plugin skills. Therefore a stale `~/.agents/skills/ce-plan/SKILL.md` with `name: ce-plan` would shadow the plugin's `ce-plan` and the plugin skill would be silently ignored.

### Cleanup

The old custom Copilot target wrote generated files under `.github/`-style output. Users who installed that way should run CE legacy cleanup before or during migration so they do not have duplicate agents or skills from both the old Bun output and the native plugin.

For Copilot, "duplicate" often means silent shadowing rather than two visible entries. Cleanup must remove CE-owned stale skills from project and personal skill roots before switching to native plugin install, otherwise users can appear to have the native plugin installed while actually running an old flat skill.

Run:

```bash
bunx @every-env/compound-plugin cleanup --target copilot
```

The cleanup command backs up known CE-owned Copilot artifacts such as:

- Generated `.github/agents/*.agent.md` files from old installs
- Generated `.github/skills/*/SKILL.md` directories from old installs
- Generated `~/.copilot/{agents,skills}` files from personal old installs
- Shared `~/.agents/skills/*` CE skills that would shadow native Copilot plugin skills
- Any tracked install-manifest entries from the old writer

It must not delete user-authored `.github/agents` or `.github/skills` content unless manifest/history proves CE ownership.

## Factory Droid

### Decision

Droid should use native plugin marketplace install, not `bunx @every-env/compound-plugin install compound-engineering --to droid`.
The custom Droid plugin install/convert target has been removed from the CLI target registry.

Users install with:

```bash
droid plugin marketplace add https://github.com/EveryInc/compound-engineering-plugin
droid plugin install compound-engineering@compound-engineering-plugin
```

Factory's docs describe GitHub marketplace installation, user/project/org plugin scopes, and direct Claude Code plugin compatibility. They explicitly say Droid can install a Claude Code plugin directly and automatically translate the format. Manual testing on 2026-04-19 confirmed Droid could run `ce-doc-review` from the CE plugin and load both the skill and agents.

This means Droid is now in the same category as Claude Code and Copilot for CE distribution: use the native marketplace/plugin install path, not a generated custom Bun install.

### Cleanup

The old custom Droid target wrote CE-owned artifacts under `~/.factory`, especially:

- `~/.factory/skills/*`
- `~/.factory/droids/*.md`
- `~/.factory/commands/*.md`
- any CE install manifest or managed backup directory created by the old writer

Before users migrate from the old Bun install to the native Droid plugin, legacy cleanup should remove or back up CE-owned generated files so the native plugin is not shadowed by stale local artifacts.

Run:

```bash
bunx @every-env/compound-plugin cleanup --target droid
```

The cleanup command must not delete Droid's native plugin cache or user-authored Droid files. It should only remove artifacts proven to be CE-owned by an install manifest, known historical CE names, or generated CE metadata.

## Qwen Code

### Decision

Qwen should use native extension install, not `bunx @every-env/compound-plugin install compound-engineering --to qwen`.
The custom Qwen plugin install/convert target has been removed from the CLI target registry.

Users install with:

```bash
qwen extensions install EveryInc/compound-engineering-plugin:compound-engineering
```

Qwen Code's extension docs say it can install Claude Code extensions directly from GitHub and convert Claude plugin metadata to Qwen extension metadata automatically. Manual testing on 2026-04-19 confirmed the CE plugin installed successfully through Qwen's native path.

This is a better fit than the old custom writer because Qwen now owns the Claude-plugin compatibility layer. The old writer duplicated that logic and did not fully rewrite CE's agent-heavy skill content into Qwen subagent invocation syntax.

### Cleanup

The old custom Qwen target wrote CE-owned artifacts under `~/.qwen`, especially:

- `~/.qwen/extensions/compound-engineering/` with CE-managed tracking keys in `qwen-extension.json`
- `~/.qwen/skills/*`
- `~/.qwen/agents/*.yaml`
- `~/.qwen/agents/*.md`
- `~/.qwen/commands/*.md`

Before users migra

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/native-plugin-install-strategy-2026-04-19) · https://claudary.paisolsolutions.com