For developers · Lumi Cloud

How it works

You keep your pack in a public Git repository and submit one commit of it at a time. Luminary staff review that version; once it's approved, it appears in the catalog and in the signed index Lumi reads.
People install a listed version exactly at its commit, from Lumi's Settings > Capability packs > Install from Git, or an organization adds it to its own registry. Either way each person still reviews and approves what the pack runs.
A listed version never changes. To publish a change, submit the new commit as a new version.
There are no publisher terms yet.

Make a pack

A folder with a lumi-pack.json manifest. It names the pack (id, name, version, description) and lists what it brings: agents and skills (Markdown files in the pack), hooks (commands run at lifecycle events), mcp_servers, providers (model providers) and ui_panels. Every path stays inside the pack's folder, without symbolic links.
Declare the SDK version. Set "manifest_version": 1 for the Lumi Extension SDK, and optionally the Lumi versions it works with, such as "lumi": ">=0.19.2".
Model providers and panels follow the Extension SDK's protocol: Lumi starts the provider's command for each request, writes one JSON line to it and reads JSON lines back (text, tool calls, then done or error). Panels are pages Lumi shows in a sandboxed frame. The SDK's Python package, lumi_extension, does the protocol for you, and its template starts a working provider.
Check it as Lumi will:
```
lumi extension check path/to/your-pack
```
It loads the manifest with Lumi's rules, tries a provider's first model, and prints the pack's content digest: the 64 hex digits you can give when you submit, so computers check the files themselves and not just the commit.
Sign it (optional, recommended). Make a key once and keep its private file secret; publish the public key and key id where people can check them, such as your README:
```
lumi extension keygen ~/keys/my-packs.key
lumi extension sign path/to/your-pack --key ~/keys/my-packs.key --publisher "Your name"
```
Signing writes lumi-pack.sig, which covers every file in the pack, so sign again after every change and commit the signature with it. A signature says who made the pack; it never approves it.
Try it yourself with Install from Git, then push the commit you'll submit to a public repository.

What a submission needs

Field	Rule
Pack id	The `id` in `lumi-pack.json`: 1 to 80 lower-case letters, digits, `.` `_` and `-`, starting and ending with a letter or digit. Ids like Lumi's or Luminary's are for Luminary. The first approved version makes the id its publisher's for good.
Version	The `version` in `lumi-pack.json` at that commit, such as `1.2.0`.
Name, description	One line each, up to 120 and 500 characters, without invisible or direction-changing characters.
Repository	A public `https` address on a public host name: no IP address, credentials, access token, port, query or fragment.
Commit	The full 40-character commit.
Folder	Optional: where the pack is in the repository, without `.` or `..` parts.
Content digest	Optional: what `lumi extension check` printed for the pack at that commit.
License	An SPDX identifier or expression, such as `MIT` or `MIT OR Apache-2.0`, matching the repository's license file. Not `LicenseRef-…` or free text.
Publisher	Who publishes it, up to 80 characters: a name that's yours to use.
Signing key	Optional: the base64 public key `lumi extension keygen` printed. Its key id is shown beside the version.
Permissions	Every permission the manifest declares, the pack's own and its tools' together: `read_project`, `write_project`, `network`, `shell`. People see them in the Extensions store before they install.

Nothing may pass for something listed: an id, name or publisher that looks like a listed pack's (review-too1s for review-tools) is refused, and so is mixing alphabets within a word.
A commit already waiting or listed can't be submitted again, and files Luminary delisted never come back, under any id or repository.
Up to 10 of your versions can wait for review at once, and five submissions in ten minutes.
Your account's email is how reviewers reach you. Only you and Luminary's staff see who submitted a version and the review note.

How Luminary reviews it

Staff, who sign in with two-step verification, review each version by hand, in a sandbox. Nobody reviews their own submission. They check that:

the repository is public and has the commit, and the folder's lumi-pack.json has the pack id;
lumi extension check prints the content digest you gave;
with a signing key, lumi-pack.sig verifies with it;
the license file matches the license you gave;
the manifest declares the version and permissions you gave, and what the pack runs fits them;
what the pack runs (hooks, MCP servers, model providers, scripts) does what it says: no hidden network calls, reading credentials, obfuscated code or downloads at run time;
the publisher's name is yours to use, and a changed repository or key is explained.

Approval lists the version at once. A rejection comes with a note saying why, on Your submissions; fix it and submit again. A listed version found harmful or wrong can be delisted: it leaves the catalog, the index lists it as delisted, and organizations that use it are warned. Luminary's review isn't a security audit, and people still approve each pack themselves.

The signed index

Lumi reads the catalog from /marketplace/v1/index.json, signed with Luminary's marketplace key. Each copy expires 24 hours after it's made. Lumi trusts the key it was built with, never one fetched beside the index; this is the key, as /marketplace/v1/keys.json publishes it:

Key id: 3848bb3a702bc1b0
Public key (Ed25519): Vl4AXVMSV0YmYogZCN1gxHGmAJRR5qrC7SEDk0/RgHw=

Submit a pack