poc: unify skills, MCP and integrations into one Marketplace tab - #76
Draft
JairEsk wants to merge 1 commit into
Draft
poc: unify skills, MCP and integrations into one Marketplace tab#76JairEsk wants to merge 1 commit into
JairEsk wants to merge 1 commit into
Conversation
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).
FreddyJD
marked this pull request as draft
August 25, 2026 15:12
FreddyJD
marked this pull request as ready for review
August 27, 2026 00:53
FreddyJD
marked this pull request as draft
August 27, 2026 00:53
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
kindbadge that explains the mechanism without being how the list is organized.The UX decisions, in order of how much they matter:
Also lands SuperUser: the first
criticaladd-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).