# The MiniMax plugin, and how to submit it

treg's fifth shop window: the **MiniMax Plugin Marketplace**, which serves both **MiniMax Code**
(desktop) and **MiniMax Agent** (cloud). Like the Claude Code and Cursor plugins it is
**skills-only**, and for a harder reason than convenience: MiniMax rejects any package holding a
credential, and treg's MCP is bearer-authed per user. An authenticated MCP would have to go through
their **App/Connector** program (OAuth MCP server, PKCE, MiniMax-registered client) — see
"Later: an App" below.

Source of the rules: MiniMax's *Plugin Development and Submission Guide* (Feishu wiki
`QlTLwbAGNiACwLkWI85cFxHzn4L`, last updated 2026-08-17). It is a JS-rendered page behind a Feishu
login; the rules that matter are encoded in `scripts/minimax_plugin.py`.

## What is where

```
plugins/minimax/
├── .minimax-plugin/plugin.json   the manifest (schemaVersion 1)
├── icon.png                      512×512, the ▚ mark — same file as plugin/assets/icon.png
└── skills/treg/SKILL.md          GENERATED — never edit by hand
scripts/minimax_plugin.py         validator (--check) and ZIP builder (--zip OUT)
```

`plugins/minimax/` is the **plugin root** (a sibling of the Cursor root `plugins/treg/`; each store needs its own root because the manifests and generated bootstraps differ): `.minimax-plugin/plugin.json` sits directly inside it, which is
what MiniMax requires of a ZIP root or a GitHub subdirectory. Manifest `name` is `treg`; the skill is
exposed at runtime as `treg:treg`.

**Never edit `plugins/minimax/skills/treg/SKILL.md`.** Change `src/treg/web/skill.md` and regenerate:

```bash
uv run python scripts/build_plugin.py            # regenerate ALL plugins
uv run python scripts/build_plugin.py --check    # fail if any is stale (also a test)
python3 scripts/minimax_plugin.py --check  # MiniMax package rules (also a test)
```

### No bootstrap

The skill is the served page unchanged. Its first section already covers an agent with neither
treg's MCP tools nor the CLI, and nothing in it sends the agent to `treg mcp install`, which has no
MiniMax target.

### What their validator enforces (and ours pre-checks)

- `.minimax-plugin/plugin.json` at the root, **no wrapper directory** in the ZIP.
- `name`: lowercase, starts with a letter, ≤80 chars of `[a-z0-9._-]`. `version`: SemVer, **must
  bump whenever package content changes** (region/target-only changes may keep it). Ours tracks
  `pyproject.toml` — `test_plugin_version_tracks_the_package` pins it.
- `category` from a fixed list (Office, Studio, Design & Sites, Code, Business, Sales,
  Productivity, Science & Healthcare, Education, Other). We use **Productivity**.
- `exampleQueries`: 0–3, non-empty, ≤4,096 chars, *production* content.
- `apps` / `mcpServers` / `skills`: relative paths; **unused ones stay as empty arrays**.
- `icon`: relative path, lowercase `.png/.jpg/.jpeg/.webp`, square.
- Skill: `skills/<name>/SKILL.md`, YAML frontmatter with `name` == directory and non-empty
  `description`; body must be executable instructions, not marketing.
- Paths ASCII-only, `/` separators. No symlinks, hardlinks, LFS pointers, submodules, install
  scripts, native binaries, executable bits. UTF-8 without BOM. JSON = object, no duplicate keys.
- Limits: ZIP ≤64 MiB, ≤2,048 entries, ≤1,024 files, ≤16 MiB per file, path ≤512 B / segment
  ≤128 B / depth ≤16.
- **No token, key, secret or personal data anywhere.**

The manifest carries no `license` key — their schema does not define one and unknown keys are a
validator risk. The licence is stated here instead: `SKILL.md` is prose about a hosted service and
ships under the repo's Apache-2.0 (see `LICENSE`).

## Submission runbook

Two sources are accepted and go through the same pipeline. **Prefer GitHub** — no artefact to
manage, and updates are a new `Ref`.

**Submit** (form linked from the guide: "Open the Plugin submission form"; needs a Feishu account —
use one the team keeps, the *same* account must query status later):

| field | value |
|---|---|
| Action | Submit a new Plugin |
| Region | **US** (and CN if wanted — separate dimension; treg.to is reachable from CN but billing is Stripe) |
| Delivery target | **Desktop (MiniMax Code) + Cloud (MiniMax Agent)** — the skill is CLI-driven, so cloud only helps if the Agent sandbox can run `install.sh`; pick both, they can disable one |
| Source | GitHub |
| Repo | `https://github.com/superdesigndev/treg` |
| Ref | `main` (or the release tag, e.g. `v0.12.1`) |
| Plugin subdirectory | `plugins/minimax` |
| Email | jason@superdesign.dev |

ZIP alternative — built deterministically, no wrapper directory:

```bash
python3 scripts/minimax_plugin.py --zip treg-minimax-$(python3 -c 'import tomllib;print(tomllib.load(open("pyproject.toml","rb"))["project"]["version"])').zip
```

**After submitting:** save the `submission_id`. Pipeline: source freeze → script validation
(failures come back as a Feishu message) → Release MR to the CN/US marketplace `main` → human
review of the MR diff, Markdown report, icon, CI → owner merges → pipeline packages → status
"Publishing" / "Published" / "Publishing failed" by Feishu message. Status query needs the
submitting Feishu account + `submission_id` + email.

**Updating:** `name` stays `treg`, bump `version` (the release bump does this), provide proof of
maintenance (the GitHub repo is the proof), resubmit with the new Ref. No change summary — they
diff the MR.

## Known review risks

1. **`curl … | sh` in the skill.** The package contains no install script, but the skill *tells the
   agent to run one*. ClawHub's LLM review flagged the same line (`SQP-2`, see
   `docs/CLAUDE-PLUGIN.md`). If a reviewer objects, the fallback is `pip install treg` /
   `uv tool install treg` — the CLI is on PyPI — and a one-line swap in `MINIMAX_BOOTSTRAP`.
2. **Cloud target.** On MiniMax Agent the skill only works if the sandbox has a shell with network
   egress and can open a browser for `treg login` (device-code login is what to point them at if
   not). If cloud fails their verification, resubmit desktop-only — that is a catalog-metadata change,
   no version bump.
3. **Description vs implementation.** Their rule: say what problem it solves, not how. The manifest
   description is capability-only; keep it that way.

## Later: an App

To get the five MCP tools into MiniMax natively, treg would enter their **App/Connector** track:
contact MiniMax *before* building, provide test + prod Streamable-HTTP MCP endpoints, an OAuth
issuer with discovery metadata, authorization/token/registration/revocation endpoints, scopes,
DCR/PKCE (S256) support, refresh tokens, callback allowlist needs, a test account, rate limits and
error codes. MiniMax then assigns a `provider` and the plugin gains `treg.app.json`
(`{"schemaVersion":1,"provider":"treg"}`). treg's MCP currently authenticates with a static bearer
token, which their guide says to raise with them *before* development — so this is a product
decision (an OAuth AS in front of `/mcp/`), not a packaging one.