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

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:

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:

/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:

/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:

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

Shell equivalents:

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:

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:

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:

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:

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