Lobe Chat Plugins Index is a JSON file with a review process around it

The deliverable is one file on npm

The manifest is short and tells you the entire architecture.

  "name": "@lobehub/plugins-index",
  "version": "1.9.0",
  "main": "public/index.json",

The package entry point is a JSON file. LobeChat fetches that file, reads it as a plugin list, and shows the entries to the user, which is what the repository description says in as many words: it accesses index.json from this repository to display a list of available plugins for LobeChat to the user.

So this is a registry, not a runtime. Nothing here executes plugin code. A plugin lives in its own repository, published as its own npm package, and what arrives here is metadata that says the name, the author, the description, the tags and the URL. That separation is the design decision worth copying. The index can be regenerated, replaced or mirrored without any code executing, and the blast radius of a bad index entry is a bad row in a list rather than a compromised client.

The package publishes the public directory and nothing else, which is the same idea expressed in the file list. Only the artifact ships.

The generated README is the visible face of the same data, and every entry there carries a fixed shape.

### [SEO Assistant](https://lobechat.com/discover/plugin/seo_assistant)

followed by an author and date line, a one sentence description, and a row of tags in backticks such as seo and keyword.

Submission is a pull request against a template

The contribution path is five steps, and it is a human review queue rather than an automated registration.

Fork the repository, make a copy of plugin-template.json, fill in the copy and rename it appropriately, move it into the src directory, then submit a pull request and wait for review. The prose before the list says to make an entry in the plugins directory using plugin-template.json, write a short description, tag it appropriately and open a pull request.

Those two descriptions do not agree on the directory. The prose says plugins, the numbered steps say src, and the repository tree contains src and no plugins directory. Given that the build script reads from src, the numbered steps are the ones that describe the working layout, and the earlier sentence is stale wording.

The editorial notes around the steps are the part that makes this a registry rather than a dump, and they are unusually blunt.

> An plugin will need to be functioning for it to be included.

The full set of rules: a plugin must be functioning to be included; if a plugin is no longer functional or unmaintained the maintainers might redirect the entry to a fork or remove it; not all plugins will be accepted, because they review each one and make an assessment; you can submit a plugin you did not author, though the author doing it themselves is preferred; and if you want an entry removed, or you think the description does not describe the plugin properly, you open an issue or a pull request.

One mechanical detail is documented as an automation: the createAt date will be populated automatically after merge. So submission dates are not self-declared, which means the date column in the generated list is a reliable sort key.

Nine bun scripts and what each one is for

The tooling is Bun based, and the scripts map one to one onto the stages of building a registry.

    "build": "bun scripts/build.ts",
    "sync": "bun scripts/sync.ts",
    "awesome": "bun scripts/build.ts && bun scripts/updateAwesome.ts",

build assembles the index. sync appears to reconcile entries against upstream state, which given the removal and fork redirect rules is where that logic would live. awesome runs build and then updateAwesome, which regenerates the Awesome Plugins section of the README from the index data. That last one explains the marker comment in the README.

<!-- AWESOME PLUGINS -->

A marker comment like that exists so a script can find the region it owns and rewrite it without touching the hand written parts of the document. It is a small pattern with real value: the README stays readable and correct for humans without anyone maintaining the list by hand.

The rest of the scripts cover the surrounding work: format runs scripts/format.ts, lint runs eslint over the scripts directory with fix enabled, lint:md runs remark with the quiet flag and writes output back, prettier covers json, ts and md files, test runs scripts/test.ts, and release runs semantic-release.

Running Bun rather than Node is a deliberate choice for a build pipeline like this. The scripts are TypeScript, they start without a compile step, and there is no tsconfig build chain to babysit. The cost is that contributors need Bun installed, which is one more prerequisite than a plain Node project would ask for.

Schema first, with zod and zod-to-json-schema

The two schema libraries in the dependency list tell you how manifests are validated. zod at ^3.24.1 does runtime validation, and zod-to-json-schema at the same version generates a JSON Schema from the zod definition, which is what lets an external plugin author write a manifest against the published schema and get editor completion.

    "zod": "^3.24.1",
    "zod-to-json-schema": "^3.24.1"

That pairing is the single most reusable idea in this repository. A registry that validates with zod at build time and publishes the derived JSON Schema gets two things from one definition: broken entries fail the pipeline instead of reaching clients, and the contribution guide can be a link to a machine readable schema rather than prose that drifts.

The official SDK is a dev dependency at ^1.32.4, which means entry authors are expected to build against @lobehub/chat-plugin-sdk rather than hand writing the function schema. The pinned langchain at 0.1.37 is the one dependency that looks left behind, since it is a much older line than everything else in the list and is likely used for one specific transformation during the build rather than as a general framework choice.

The rest of the dev dependency list is ordinary registry tooling: @octokit/rest for the GitHub API, fs-extra and lodash-es and p-map for file and collection work, consola for logging, dayjs for dates, dotenv, dirty-json for tolerating malformed JSON in third party metadata, typescript at ^5.7.3, eslint at ^8.57.1 with @lobehub/lint on top, and remark with remark-pangu for Markdown formatting. That last one is a detail worth pausing on, because remark-pangu inserts spacing between Chinese and Latin text, which tells you the documentation is maintained bilingually.

Bilingual docs, a template file, and an MIT licence nobody can see

The repository root tells you how the documentation is maintained.

.i18nrc.js
README.zh-CN.md
locales/
meta.json
plugin-template.json

A Simplified Chinese README, an i18n config, a locales directory, a meta.json and the plugin template. The presence of a Chinese README alongside the English one is not a courtesy, it is a sign that the contribution flow is used from a Chinese speaking community, which the plugin list itself corroborates: entries include a Google CSE plugin, an Alibaba Tongyi Wanxiang image generator, and a set of search plugins that are mostly wrappers around search APIs that are harder to reach from that region.

The dates in the list also tell you how active the index is. The newest entries visible in the README carry dates of 2026-01-12, 2025-12-13, 2025-12-08, 2025-11-28 and 2025-11-14, and further down there are entries from 2024-08-09, 2024-06-27 and 2024-05-06. A registry accumulates, so a long tail of 2024 entries is expected; the useful signal is whether the top of the list is still receiving new submissions.

Then there is the licensing inconsistency. The repository metadata reports no licence, and the tree does contain a LICENSE file, but the published manifest declares MIT and names LobeHub as the author with an email contact. If you want to fork the registry or reuse the tooling, the package manifest is the clearest statement available and it says MIT, while the absence of a machine detected licence at the repository level is the sort of gap that automated compliance tools flag. Worth asking about rather than assuming.

The last commit to the repository is dated 2026-04-30, and the repository shows 301 stars, 171 forks and 57 open issues. A fork count that high relative to stars is exactly what you would expect from a registry where contributing is a pull request rather than a clone.

What the README promises and does not document

The table of contents lists four sections beyond submission and the plugin list: Self Hosting, Deploy to Vercel, Local Development, and Contributing, plus a Links section.

Only Contributing is written in the README body. Self Hosting, Deploy to Vercel and Local Development appear in the contents but the text is not present in the file, which means the section bodies live somewhere else, most likely in the wiki or in a version of the document that is generated differently, or they were removed and the contents were not updated.

That matters for a specific reason. Self hosting the index is the thing an organization would want: the ability to point LobeChat at your own copy of the registry rather than the public one. Since the package publishes a single JSON file and the client fetches it, self hosting should be a matter of serving one document, and the README's table of contents says that capability is documented somewhere. If you need it, that is the section to go looking for rather than assuming the feature is missing.

There is also no documentation of the entry schema in prose. The shape has to be inferred from plugin-template.json and from the rendered README, which is the argument for the zod-to-json-schema setup being the real documentation surface. A schema published to a schema store would close the gap that the missing sections leave.

The topics are worth a final note, since they are narrow for a repository with 301 stars: ai, awesome, chatgpt, function-calling, lobe-chat, lobe-chat-plugin, lobehub and openai. The function-calling tag is the accurate one. Everything in this index exists so that a chat client can call a function.

Editorial conclusion

This repository is worth reading if you are building any kind of extension registry, because the hard parts are all visible and none of them are the index itself. The index is one JSON file, and the work is in keeping it honest: a zod schema and zod-to-json-schema so a malformed manifest fails the build, a build script that assembles src into public/index.json, an update script that rewrites the Awesome Plugins section of the README from that data, a test script, and semantic-release for versioning. Two contradictions are worth keeping in mind as you read the docs. The submission instructions say to make an entry in a plugins directory and then say to move it into src, and only src exists in the repository. And the repository reports no licence while the published package declares MIT, which matters if you plan to fork the registry. The last commit is dated 2026-04-30 and the newest entries in the generated list are from early January 2026.

Frequently asked questions

Official sources

1. Issues
2. lobehub/lobe-chat-plugins on GitHub
3. Project website
4. README
5. Releases