Skip to content

poc: unify skills, MCP and integrations into one Marketplace tab - #76

Draft
JairEsk wants to merge 1 commit into
mainfrom
jair/marketplaceDemo
Draft

poc: unify skills, MCP and integrations into one Marketplace tab#76
JairEsk wants to merge 1 commit into
mainfrom
jair/marketplaceDemo

Conversation

@JairEsk

@JairEsk JairEsk commented Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Extending Roxy meant knowing which mechanism your wish was implemented by: a Skill (/skills), an MCP server (/mcp), an Integration (/integrations), or the Remote Workspace dialog. Four pages, four vocabularies, every one named after the plumbing rather than the outcome. To connect a database you had to already know the words "MCP server".

Collapse all four into one noun -- an Add-on -- with a kind badge that explains the mechanism without being how the list is organized.

The UX decisions, in order of how much they matter:

  1. One noun. You search for "postgres", not for "an MCP server".
  2. Two tabs (Installed / Discover), not seven. Labs is third only because it answers a different question: where is this going?
  3. Search is the primary control, and it indexes the jargon we removed from the surface -- typing "mcp" or "SKILL.md" still finds the right cards.
  4. Permissions on the card, before install. An add-on's risk is DERIVED from its capabilities (addonRisk) rather than self-reported, so nothing can advertise itself as harmless while asking to drive your keyboard.
  5. One switch means one thing. Live toggle for anything real, an explicit "Preview" for shells, an interest signal for ideas. A control that looks live but is inert would poison every other control on the page.

Also lands SuperUser: the first critical add-on, shipped deliberately as a shell. It is listed, describable and consent-gated, and it does nothing. It exists in this state so the permission model is designed against a real critical entry rather than a hypothetical one, and so the conversation about whether Roxy should operate the whole machine happens over a manifest, now, instead of over an implementation, later.

And Labs: 12 candidate implementations published before they are built, each with its capabilities, what it builds on, and the honest objection to it. An idea with a manifest can be argued with; the same idea in a backlog can only be seen by its author.

No new IPC and no migration -- installed rows are merged from the existing skills.list/mcp.list/integrations.list, and preview/lab flags persist through the integrations table under namespaced ids (addon: / lab:).

Removes routes/Integrations.tsx: fully covered by the Marketplace and unreachable from the UI. /skills and /mcp are kept as the deep-dive editors the Marketplace links into.

Adds ~45 checks to smoke:shared (935 passing).

Extending Roxy meant knowing which mechanism your wish was implemented by:
a Skill (/skills), an MCP server (/mcp), an Integration (/integrations), or
the Remote Workspace dialog. Four pages, four vocabularies, every one named
after the plumbing rather than the outcome. To connect a database you had to
already know the words "MCP server".

Collapse all four into one noun -- an Add-on -- with a `kind` badge that
explains the mechanism without being how the list is organized.

The UX decisions, in order of how much they matter:

  1. One noun. You search for "postgres", not for "an MCP server".
  2. Two tabs (Installed / Discover), not seven. Labs is third only because
     it answers a different question: where is this going?
  3. Search is the primary control, and it indexes the jargon we removed from
     the surface -- typing "mcp" or "SKILL.md" still finds the right cards.
  4. Permissions on the card, before install. An add-on's risk is DERIVED
     from its capabilities (addonRisk) rather than self-reported, so nothing
     can advertise itself as harmless while asking to drive your keyboard.
  5. One switch means one thing. Live toggle for anything real, an explicit
     "Preview" for shells, an interest signal for ideas. A control that looks
     live but is inert would poison every other control on the page.

Also lands SuperUser: the first `critical` add-on, shipped deliberately as a
shell. It is listed, describable and consent-gated, and it does nothing. It
exists in this state so the permission model is designed against a real
critical entry rather than a hypothetical one, and so the conversation about
whether Roxy should operate the whole machine happens over a manifest, now,
instead of over an implementation, later.

And Labs: 12 candidate implementations published before they are built, each
with its capabilities, what it builds on, and the honest objection to it.
An idea with a manifest can be argued with; the same idea in a backlog can
only be seen by its author.

No new IPC and no migration -- installed rows are merged from the existing
skills.list/mcp.list/integrations.list, and preview/lab flags persist through
the integrations table under namespaced ids (`addon:` / `lab:`).

Removes routes/Integrations.tsx: fully covered by the Marketplace and
unreachable from the UI. /skills and /mcp are kept as the deep-dive editors
the Marketplace links into.

Adds ~45 checks to smoke:shared (935 passing).
@JairEsk JairEsk changed the title feat: unify skills, MCP and integrations into one Marketplace tab DEMO NO MERGE: unify skills, MCP and integrations into one Marketplace tab Aug 25, 2026
@FreddyJD FreddyJD changed the title DEMO NO MERGE: unify skills, MCP and integrations into one Marketplace tab poc: unify skills, MCP and integrations into one Marketplace tab Aug 25, 2026
@FreddyJD
FreddyJD marked this pull request as draft August 25, 2026 15:12
@FreddyJD
FreddyJD marked this pull request as ready for review August 27, 2026 00:53
@FreddyJD
FreddyJD marked this pull request as draft August 27, 2026 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant