## Problem Today, Agents and Flows live as separate pages, and filters mix ownership, enablement, and visibility into overlapping terms, so it's hard to tell "what can I turn on" from "what do I already have." Detail pages lead with the enable action before showing the trust and provenance signals people need to decide whether to use something. Object type terminology (Agent, Flow, MCP Server) isn't explained in context, so users bring inconsistent mental models to the same labels. ## Goal Combine Agents, Flows, Skills, and MCP Servers into a single catalog, separate managing what a project or group uses from discovering what it could use, and establish a consistent, collision-free filter and terminology model across Explore, Group, and Project scope. Restructure the detail page so evaluation signals lead the enable action. ## Designs ### How it fits together The catalog has two levels of navigation: 1. **Tabs: "In this project" | "Discover".** These switch between the two lists (`GlTabs`, mode kept in the URL). Only "In this project" shows a count. 2. **Type control, inside each tab: All | Agents | Flows | Skills | MCP servers.** A `GlSegmentedControl` with live counts that filters whichever list you're in. The type selection carries over when you switch tabs. The Agents and Flows tabs from gitlab-org/gitlab#627839 become the type control: they move from page tabs to a filter inside each list. #627839 can land as is, with the switch to the segmented control as a follow-up. Search, the filter button, and the sort button sit in the same row as the type control in both tabs. ### In this project A list with one status badge per row (Enabled, Disabled with an inline Enable button, or Enabled by {group name}) and a row menu.  ### Discover A card grid with an Enable button or Enabled badge on each card, and star counts. The New and Trending sections are shown for direction only and aren't in this iteration.  ### Detail page The item type and its icon sit under the name. The enable action, star count, and menu sit in the top corner. Trust and provenance (Source, visibility, categories, authorship) sit in the sidebar alongside enablement status.  ### All screens Full screens, including menus and states, are in the Designs tab of each design issue: - gitlab-org/gitlab#612996 Unified catalog view: In this project, Discover, Developer view, empty state - gitlab-org/gitlab#627187 Filters: toolbar, filter menu (Category, Source, State), sort menu, empty state - gitlab-org/gitlab#612998 Card items: Discover cards - gitlab-org/gitlab#612999 Detail pages: agent, flow, and MCP server, plus the Developer view ## Proposal ### Structure - Two tabs at Group and Project scope: **In this [scope]** (everything the scope manages or uses, with a count) and **Discover** (everything the user can see that could be enabled here, no count). - Explore shows Discover only. - A type control with live counts: All, Agents, Flows, Skills, MCP servers. ### In this [scope] - A list, one row per item: name, type badge, description, category, and a GitLab icon for foundational items. - One status badge per row: **Enabled**, **Disabled**, or **Enabled by {group name}**. - Disabled rows show an inline **Enable** button (**Connect** for MCP servers). Disable, Remove from this [scope], and Delete live in the row menu. Enable is never in the menu. - Developers see **Request enablement** (**Request connection** for MCP servers) instead of Enable. - Requested items show an **Enablement requested** badge. Developers see only the badge. Maintainers see the badge and an Enable button. - When anything is requested, Maintainers see a notice above the list: "N items requested for enablement · Review". Review filters the list to requested items. - Foundational items are turned on or off in GitLab Duo settings, not in the catalog. When on, they show as Enabled with no Disable or Remove. When off, they aren't listed here. ### Discover - A card grid. Each card has an **Enable** button (**Connect** for MCP servers), or an **Enabled** badge when already enabled here. - Foundational items turned off in Settings stay in Discover, marked "Turned off in Settings" with no Enable action. - Star count on cards, as a trust signal. ### Search, filters, and sort - Search matches name and description. - Filters: **Category** (curated list), **Source** (GitLab, then groups by top-level group name), and **State** (Enabled, Disabled, Requested; In this [scope] only). - Sort: In this [scope] by Name, Recently added, Recently updated. Discover by Popular, Most starred, Recently added, Name. - Filter and sort state is kept in the URL. ### Detail page - Trust and provenance signals (Source, visibility, authorship) appear before the enable action. - Categories appear in the sidebar's About section as one line: a single category icon followed by the item's categories, comma-separated, as plain text (for example "CI/CD, Testing"). - Triggers and enablement status have their own sections. - A star button with count in the header. ### Terminology - **Managed:** created in this scope. - **Enabled by {group name}:** enabled at the group level, read-only at Project scope. - **Enable / Disable:** for agents, flows, and skills. - **Connect / Disconnect:** for MCP servers. - **Disable (or Disconnect):** stops the item and keeps its settings. It stays in the list. Takes effect immediately with no confirmation, and the toast offers Undo. - **Remove from this [scope]:** for items added from elsewhere. Stops the item, clears its settings, and takes it off the list. It's still in Discover. Asks for confirmation. - **Delete:** for managed items. Permanent, and affects every scope using the item. Asks for confirmation. - **Request enablement / Request connection:** a Developer asking a Maintainer to turn an item on. ### What Explore is Explore is the cross-GitLab catalog view, a browsable place to discover agents, flows, skills, and MCP servers independent of any group or project you belong to. It answers "what exists that I could use," not "what do I already have." Explore follows the auth-based visibility model: it shows everything the user is authorized to see. Enabling from Explore asks which projects to enable the item in. **What Explore is not** * **Not a workspace.** There's no creation entry point here. Creation happens at Group or Project scope, where an item has an owning namespace with real permissions and service account context. * **Not a management view.** There's no In this [scope] tab and no State filter, since nothing at Explore is scoped to what the viewer manages or has enabled. ### List membership Which items each list returns is defined per scope: - Project scope: gitlab-org/gitlab#631304 - Explore scope: gitlab-org/gitlab#631305 - Group scope: gitlab-org/gitlab#631306 (not ready, see open questions) ## Open questions 1. **Source feasibility.** Can each item's publishing top-level group (name and avatar) be resolved in the list query, and can the filter's option list come from one aggregate query? What should Source show when the user can see an item but not its publishing group? If this is expensive, a fallback is "GitLab" vs "Your organization." Tracked in gitlab-org/gitlab#631304. 2. **Filter component.** `GlFilteredSearch` was chosen earlier for forward-compatibility. The current design uses an icon filter button with Category, Source, and State. Does engineering agree to move away from `GlFilteredSearch`? 3. **Nested filter menu.** The prototype explores a filter menu with submenus, which isn't in Pajamas yet (gitlab-org/gitlab-services/design.gitlab.com#3274). Until it is, should we build with the documented Pajamas Filtering pattern? 4. **Group scope.** The prototype builds group enablement as its own action: it applies to all current and future projects in the group and replaces project-level configuration. An earlier direction described the group view as a read-only rollup of project-level enablement instead. Which model do we build? Tracked in gitlab-org/gitlab#631306. 5. **Popular sort.** Does real usage data exist yet, or should "Most starred" be the Discover default until it does? 6. **Requests.** The design shows requests in In this [scope]: an Enablement requested badge, a notice with a count and a Review link for Maintainers, and a Requested state filter. Still open: what does a request create on the backend, does it persist, and are Maintainers notified anywhere outside the catalog (for example a to-do or email)? ## Out of scope for this pass - Discover sections (New, Trending) - Run status and last run - "Update pending" on skills, which comes from repo-backed authoring (gitlab-org&23370) ## Success criteria - Agents, Flows, Skills, and MCP Servers are reachable from a single catalog - Users can tell what a scope already uses (In this [scope]) from what it could use (Discover) - Every filter and terminology term used in the catalog means the same thing everywhere it appears - Detail pages present trust and provenance information before the enable action, across all object types - Explore shows everything the user is authorized to see, following the auth-based visibility model - No loss of existing filtering or discovery functionality during the reorganization