Marketplace Submissions

How to publish a template or plugin to the in-app marketplace.

The Projelli marketplace is two public GitHub repos. Templates live at projelli/community-templates, plugins at projelli/community-plugins. Each entry is one folder under entries/ with a manifest, the entry's files, and screenshots. To publish, you fork the relevant repo, add your folder, and open a pull request.

Prerequisites

• A working template or plugin tested locally inside Projelli.
• A unique id in your manifest that doesn't collide with any existing entry.
• An open-source license (MIT, Apache-2.0, BSD-3-Clause, or similar). Closed-source entries aren't accepted.
• At least one screenshot.
• A GitHub account.

Step 1: Pick the right repo

Templates and plugins live in different repos because they have different schemas and different review criteria.

• Template: a workflow definition plus a markdown body that produces one or more files when run. No code. Use community-templates.
• Plugin: a JavaScript bundle that runs inside Projelli's sandboxed worker and contributes commands, toolbar buttons, sidebar panels, or settings. Use community-plugins.

Step 2: Fork the repo and add your entry

gh repo fork projelli/community-templates  # or community-plugins
cd community-templates
git checkout -b add-my-entry

Create a folder under entries/ matching your manifest's id:

entries/my-template/
  manifest.json
  template.md
  workflow.json
  questions.json
  screenshots/
    main.png

entries/my-plugin/
  manifest.json
  index.js          (your built bundle)
  screenshots/
    main.png

The folder name must exactly match manifest.id. The build script enforces this.

Step 3: Author the manifest

Templates use the TemplateManifest schema; plugins use the PluginManifest schema. Both repos' READMEs show a complete example.

Fields you'll always need: id, name, version (semver), apiVersion, author, description, category, tags, and minProjelliVersion.

Plugins additionally declare main (the JS entry path) and permissions (what host capabilities the plugin needs). See the permissions reference for details on which permissions are surfaced to the user at install time and how to keep that list short.

Step 4: Validate locally

Both repos ship the same scripts/build-catalog.mjs. Run it from the repo root:

npm install --no-save zod@^4.3.6

# templates repo
PROJELLI_CATALOG_KIND=templates node scripts/build-catalog.mjs

# plugins repo
PROJELLI_CATALOG_KIND=plugins node scripts/build-catalog.mjs

If your manifest validates, the script writes catalog.json plus a tarball and checksum inside your entry folder. If it fails, you'll see a list of validation errors with the field path and reason. Fix and re-run.

You can leave the generated tarball and checksum out of your PR; the GitHub Action regenerates them after merge so the catalog stays consistent.

Step 5: Open a pull request

git add entries/my-entry/
git commit -m "Add my-entry v1.0.0"
git push origin add-my-entry
gh pr create --base main

Use this title format: Add <name> v<version>.

In the PR description, include:

• One paragraph on what the entry does and who it's for.
• For plugins: the list of permissions you declared, with one sentence per permission explaining why you need it.
• For plugins that declare network: which hosts the plugin contacts and what data is sent.
• A link to your source repo if it's public.

Step 6: Review

A maintainer reviews every submission. Reviews focus on:

• Schema valid. The Action runs build-catalog.mjs on every PR. If it fails, the PR can't merge.
• Honest description. The pitch matches what the entry actually does.
• Reasonable scope. Entries that do one focused thing land faster than ones that try to do everything.
• Plugin code is readable. The bundle isn't obfuscated to hide behavior. Source maps or a linked source repo help.
• No secrets. No hardcoded API keys, tokens, or credentials in the bundle.
• Permissions match behavior. What a plugin declares matches what its bundle actually does.
• Original. We don't accept near-duplicates of existing entries unless the differentiator is obvious.

Most reviews finish within a few days. If we ask for changes, push another commit to the same branch and the PR updates automatically. Once merged, the Action regenerates catalog.json and your entry appears in the in-app marketplace on the next refresh.

Updating an existing entry

Bump version in your manifest, update the files, and open a PR. Don't change the entry's id or rename the folder; that breaks installs for users on the old version.

Removing an entry

Open a PR that deletes the entry folder. Existing installs in user copies of Projelli keep working; the entry just disappears from the marketplace.

Reporting a problem

If you find an entry that's broken, misleading, or doing something it shouldn't be doing, open an issue on the relevant repo with the entry id and details. We take takedowns seriously when a plugin violates the trust model.