Grok Skills and Plugin Marketplace

Executive Summary

Grok Skills and Plugin Marketplace covers three related extension systems: reusable expertise in the Grok app, installable packages for Grok Build, and procedures used by Grok Bot. The app Skills launch was May 18, 2026; the terminal marketplace followed on June 11. These are distinct delivery and execution surfaces, not a single synchronized library.^[1][2][3]

The most inspectable part is the official xai-org/plugin-marketplace GitHub repository. It supplies a catalog, source revisions, component metadata, and an update process for Grok Build. That makes it a distribution entry in agentic skills frameworks, rather than a development methodology comparable to the workflows it distributes. Its strengths are reviewable packaging and pinned provenance; permission semantics, external dependencies, and individual licenses still need separate evaluation.^[4][5]

---

Three Surfaces, Three Workflows

The app launch includes document, presentation, spreadsheet, PDF, and skill-creation capabilities. It describes built-in skills on every account and custom versions taking precedence. That announcement establishes the app workflow; it does not establish that installing a CLI package also installs it into a Grok chat or a Bot.^[1]

For Bots, a skill describes how to work, while a routine determines when one Bot does it. The guide distinguishes reusable skills from the connectors and logins needed to execute them. It also distinguishes event integrations on the Cursor account from similarly named Slack or GitHub plugins.^[3]

Teach-by-demonstration, where enabled, records visible computer interaction for up to ten minutes and produces a draft skill to review. Availability can roll out gradually. A Bot's Test run performs real work: it is not a dry-run guarantee. Saved instructions and learned procedures therefore need validation before recurring execution.^[3]

---

How the CLI Marketplace Works

Catalog, source, and component index

The source of truth is .grok-plugin/marketplace.json. Each entry names a plugin and either points to files in the catalog repository or identifies a remote repository, full commit SHA, and optional subdirectory. At the inspected commit, the local copies are Neon and Omneky. The layout supports a first-party plugins/ directory, but this snapshot should not be described as containing a first-party plugin collection merely because that directory is documented.^[6][4]

A separate generated plugin-index.json describes components before installation. Examples illustrate why “plugin” does not mean “one skill”:

These rows describe the checked index, not an independent functionality test of each package.^[9]

Remote catalog sources must contain a full 40-character lowercase SHA. The validator checks that field and rejects unsafe source-subdirectory shapes. The README also documents installer verification of the cloned commit. A pin fixes the selected repository revision; it is not a signature proving the author trustworthy or a review of every operation the plugin may perform.^[10][4]

Index generation fetches pinned sources and extracts their components. CI compares regenerated output with the committed index, so missing upstream commits and stale metadata can fail validation. The index records its remote SHA; the documented client behavior ignores index data that no longer matches the catalog pin.^[11][4]

Publishing and updating

A contributor adds or changes the catalog entry, pins the remote source, regenerates the index, and submits a PR for CI and code-owner review. The contribution guide calls for stated licenses, legitimate source ownership, and disclosed endpoints and credentials. Its published review criteria cover scripts, hooks, MCP scope, and injection attempts; this is a description of the submission process, not proof that every installed package has passed an independent security audit.^[5]

The repository also contains a daily update workflow: it looks for upstream HEAD changes accompanied by a plugin manifest version change, then opens proposed pin-update PRs. It explicitly requires manual review rather than auto-merging them. This publishes catalog revisions; it does not establish that every user's installed plugin is automatically updated.^[12]

---

Discovery and Portability in Grok Build

Grok discovers skills from project .grok/skills/ directories, user ~/.grok/skills/, enabled plugins, and configured extra paths. The docs also describe automatic discovery of Claude Code extension files and user-level .agents skills and commands. Use grok inspect to see what the current directory actually loads, including instructions, plugins, hooks, and MCP servers.^[8][13]

The metadata semantics need inspection, even when the file parses:

These are host-specific semantics, not a portable permission contract. In particular, accepting a license field without applying it is not permission to disregard the package's actual license.^[8]

Hooks are another compatibility boundary. Grok maps supported Claude and Cursor event conventions, and project hooks require trust. Only PreToolUse is a blocking event. A crash, timeout, or malformed result is documented as fail-open: the failure is recorded and the tool call proceeds. An explicit denial is therefore materially different from a hook that simply fails.^[14]

The Grok–Claude Bridge Is an Adapter

The separate official grok-build-plugin-cc repository installs a Claude Code plugin that launches the real grok executable. It requires Node, an installed CLI, and Grok authentication; the plugin owns run state and process tracking. It offers review, critique, delegation, and session-import commands. This is an execution adapter with its own dependencies, not proof that a shared SKILL.md makes all hosts interchangeable.^[15]

The inspected code differs from the README's permission examples. At commit 92b76a6, review and critique request the read-only sandbox but set automatic approval. The generic run path does the same until --write removes that sandbox request; the documented delegate policy uses write-capable runs unless asked for read-only work. The installed CLI and any managed policy determine final enforcement; read that configuration before treating a bridge action as approval-gated.^[16][15]

The underlying sandbox also has limits. Grok documents it as off by default; its built-in read-only profile still permits reads broadly and writes to runtime/temp directories. Child-network restrictions differ between Linux and macOS, and do not block the model API or in-process web tools. A “read-only” label should not be interpreted as preventing all data exposure.^[17]

---

A Concrete Evaluation Workflow

Consider a developer adding browser diagnostics to an existing application. The following is an evaluation design, not a test performed for this report:

1. Choose the execution surface. Open the Grok Build extensions interface and its Marketplace tab. Select a package for the actual task rather than assume an app skill or Bot template is the same installation.^[8][2]
2. Inspect the package. Review its source SHA, component index, license, and MCP configuration. For the pinned Chrome DevTools package, the configuration invokes a separately distributed chrome-devtools-mcp@1.9.0 package through npx; that runtime dependency is part of the operational setup.^[6][18]
3. Verify discovery and authority. After installation, inspect the loaded configuration with grok inspect. Check available tools, credentials, hook behavior, and sandbox settings; a skill's allowed-tools field is not the control to rely on.^[13][8][14]
4. Run a bounded trial. Ask for evidence about a known test-page problem, specify permitted actions and a stopping condition, and compare findings against the known defect. Record the package and host versions along with the result.
5. Retest after changes. A catalog update, new host binary, or changed connected service can alter behavior. A repository pin does not freeze a hosted MCP service or all downstream software.^[12][18][7]

The acceptance criteria in this workflow are editorial recommendations. No claim of improved completion rate or reduced cost follows merely from installing the plugin.

---

Pricing and Licensing

There is no single Grok Skills price or license. Packages, the host agent, and connected services are separate parts of the bill and permission model.

The Build overview separately documents API-key authentication and configurable model endpoints. A local skill file does not include the cost or service entitlement of whatever model configuration runs it.^[13] The reviewed sources do not establish a separate universal marketplace installation charge.

Licensing must be checked at the selected package revision:

This sample demonstrates variation; it is not a license audit of all 27 entries. The marketplace warns that third-party packages can execute code and access data, and expressly declines guarantees about their security and behavior. Public distribution, review guidelines, and SHA pinning answer different questions.^[4]

---

What Developers Say

Two specific bridge reports show why host/version testing matters. On August 7, 2026, GitHub user kai-wedekind, who also maintains a downstream bridge fork, reported outside-workspace reads and writes on Windows using the bridge-style automatic-approval/read-only invocation. The report identifies CLI versions 1.0.0 and 0.2.118 and remained open when checked September 16. This review verified the current bridge's argument construction but did not reproduce the reported Windows behavior.^[24][16]

On August 29, pmallett-ao reported critique-command failure with bridge 0.2.1 and Grok CLI 0.2.11 on macOS, where an argument was rejected before the model ran. That issue also remained open. It supports testing a particular version combination, not a claim that every current Grok skill or bridge invocation fails.^[25]

These are first-hand reports about an adapter, not representative satisfaction data for the entire marketplace. The sources reviewed did not establish a controlled evaluation of current catalog-wide quality or a reliable adoption total.

---

Competitive and Complementary Context

The useful choice is the operating model. A plain project skill is enough when one repository needs a reusable procedure. A plugin is useful when the procedure requires bundled tools, hooks, or agents. Bot routines serve recurring work in the Bot service. A complete methodology such as Superpowers can itself be distributed inside the Grok catalog, so the catalog and the methodology are not substitutes.^[8][3][9] See Anthropic Skills for another catalog and Claude Plugin Marketplace for the related distribution ecosystem.

Tembo operates at the execution-platform layer. Its current site lists Grok Build among supported agents and describes preserving agent configurations while running foreground or background work with team visibility and review. That is relevant when a team wants to operate coding-agent workflows beyond one terminal. It is not evidence that every Grok marketplace package is preinstalled, compatible, or equivalently permissioned inside Tembo.^[26]

Tembo Agent Studio is a different comparison for reusable team procedures: skills are committed into the connected repository, installed by a workspace administrator, and selected per agent. Its documented Pydantic path loads skill resources and executes scripts locally; binary resources are skipped on import. Draft/stable promotion governs agent definitions separately. No reviewed source establishes a direct Grok-marketplace import or Grok Bot routine integration.^[27][28]

Disclosure: Ry Walker is Tembo's co-founder and CEO.

Assessment

Best fit: Developers already using Grok Build who want inspectable packages and explicit source revisions, or Grok users turning a recurring task into reusable instructions on the appropriate app/Bot surface.

Poor fit: Teams expecting one catalog to standardize permission behavior across clients, guarantee every package's security, or make model and connected-service usage free.

The catalog's manifest, component index, and reviewable updates are concrete infrastructure. The decision still belongs at the package-and-runtime level: identify what loads, what runs, which credentials it receives, and how the result will be checked. That is more informative than a blanket compatibility label or marketplace size.

---

Research by Ry Walker Research • methodology