[GH-ISSUE #5062] [Feature] Ship REA as a Claude Code plugin (one-step MCP + skill install) #3104

Open
opened 2026-10-31 00:36:41 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @cainiao1992 on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5062

Area

Setup, packaging, or upgrade

Current limitation

Claude Code users register REA with rea mcp doctor --client claude_code and install the skill separately (npx skills add morluto/rea --skill reverse-engineer-anything). That is two manual steps, and the registered server version and the installed skill instructions can drift apart.

Use cases

  • An agent user wants REA tools plus the usage skill available from one install action instead of separate registration and skill steps.
  • A development checkout wants to load the local build directly with claude --plugin-dir, without touching published versions.

Desired outcome and success criteria

/plugin install rea --marketplace morluto/rea (after a one-time marketplace add) registers the local MCP server and installs the reverse-engineer-anything skill together, with both on one released version.

Expected interaction with targets

No target interaction (documentation or usability only) — this packages the existing MCP server and skill behind Claude Code's plugin installation; no new provider or execution authority.

Verification available so far

I have a prototype or observed results

Verification details

Prototype implemented: a marketplace manifest sourcing the plugin from the published rea-agents npm package (source: npm), a plugin manifest with an inline mcpServers entry, and a launcher that prefers a local build (scripts/rea.mjs + dist/ + node_modules/ present) and otherwise runs npx -y rea-agents@<package version> mcp. Observed:

  • claude plugin validate . passes (one intentional warning: the manifest omits version so package.json stays the single version source).
  • npm pack --dry-run carries the manifest, launcher, and generated skill; marketplace.json stays out of the tarball.
  • Both launcher branches answered an MCP initialize with serverInfo {"name":"rea","version":"6.7.0"}.
  • The author installed the plugin from the branch and used it successfully.

A PR with the implementation follows.

Alternatives considered

  • Committing generated skills/ to this repository so a git-sourced plugin carries them — rejected: the repo keeps generated skill bundles uncommitted, and a git-sourced plugin would leave the skill floating on main while the server stays pinned to a released version.
  • A separate plugin repository synced from npm on release — viable, but adds a repository and a sync CI step; the npm plugin source achieves the same versioning guarantee with none of that.
  • Status quo (doctor + skills add) — works, but multi-step and drift-prone.

Possible direction

As in the verification details. Because the plugin content comes from the published tarball, npm publish effectively ships the plugin — no sync CI and no second version source. The launcher reads the version from the same package.json that ships inside the tarball, so the npx fallback is pinned to the version the plugin itself shipped with.

References

  • Claude Code plugin marketplaces documentation (npm plugin source type).
  • Current registration guidance in docs/installation.md.
Originally created by @cainiao1992 on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5062 ### Area Setup, packaging, or upgrade ### Current limitation Claude Code users register REA with `rea mcp doctor --client claude_code` and install the skill separately (`npx skills add morluto/rea --skill reverse-engineer-anything`). That is two manual steps, and the registered server version and the installed skill instructions can drift apart. ### Use cases - An agent user wants REA tools plus the usage skill available from one install action instead of separate registration and skill steps. - A development checkout wants to load the local build directly with `claude --plugin-dir`, without touching published versions. ### Desired outcome and success criteria `/plugin install rea --marketplace morluto/rea` (after a one-time marketplace add) registers the local MCP server and installs the `reverse-engineer-anything` skill together, with both on one released version. ### Expected interaction with targets No target interaction (documentation or usability only) — this packages the existing MCP server and skill behind Claude Code's plugin installation; no new provider or execution authority. ### Verification available so far I have a prototype or observed results ### Verification details Prototype implemented: a marketplace manifest sourcing the plugin from the published `rea-agents` npm package (`source: npm`), a plugin manifest with an inline `mcpServers` entry, and a launcher that prefers a local build (`scripts/rea.mjs` + `dist/` + `node_modules/` present) and otherwise runs `npx -y rea-agents@<package version> mcp`. Observed: - `claude plugin validate .` passes (one intentional warning: the manifest omits `version` so `package.json` stays the single version source). - `npm pack --dry-run` carries the manifest, launcher, and generated skill; `marketplace.json` stays out of the tarball. - Both launcher branches answered an MCP `initialize` with `serverInfo {"name":"rea","version":"6.7.0"}`. - The author installed the plugin from the branch and used it successfully. A PR with the implementation follows. ### Alternatives considered - Committing generated `skills/` to this repository so a git-sourced plugin carries them — rejected: the repo keeps generated skill bundles uncommitted, and a git-sourced plugin would leave the skill floating on main while the server stays pinned to a released version. - A separate plugin repository synced from npm on release — viable, but adds a repository and a sync CI step; the npm plugin source achieves the same versioning guarantee with none of that. - Status quo (doctor + skills add) — works, but multi-step and drift-prone. ### Possible direction As in the verification details. Because the plugin content comes from the published tarball, `npm publish` effectively ships the plugin — no sync CI and no second version source. The launcher reads the version from the same `package.json` that ships inside the tarball, so the npx fallback is pinned to the version the plugin itself shipped with. ### References - Claude Code plugin marketplaces documentation (npm plugin source type). - Current registration guidance in `docs/installation.md`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#3104
No description provided.