integrate-agentgearlisted

# integrate-agentgear One `#[derive(PluginHost)]` struct gives a host the full install / uninstall / update / self-heal / doctor lifecycle. agentgear drives the `claude plugin` CLI for those ops and bakes the plugin tree into the binary. It writes that one Claude-Code plugin into 23 other harnesses' native config files, detect-gated, never clobbering user config (`copilot-cli` is a 25th target, orchestrated through its own plugin CLI rather than a per-surface config translate). The host declares intent once; agentgear delivers it per harness. This skill is the process. The exhaustive API lives in the repo's `wiki/` and `docs/` (mapped at the end); cite those rather than restating them. ## fit check (do this first) Answer these before writing any code. A "no" changes the plan. 1. **Does one binary both ship and install the plugin?** agentgear's embed model assumes the `PluginHost` binary IS the artifact that carries and installs the plugin tree. A plugin whose binary is a separate, independently-versioned artifact the plugin locates at runtime (the way slopcat's plugin finds a `slopcat` on PATH) has no clean agentgear story yet. Track it against the companion-binary item in `docs/todo.md` before committing to a migration. 2. **The plugin's own binary distribution stays the host's job.** `Source` models where the plugin *tree* comes from, never where the host's compiled binary comes from. Keep any curl+checksum / PATH-resolution / version-GC installer the