Community tools

Tools that people outside the core team build for NextOS - apps, scripts, extensions, agents, skills, MCP servers, command-line tools, templates and skins - live in one public repository and each gets a page of its own at /community/<name>. The listing at /community is generated from that repository, so publishing a tool is a pull request, not a form.

Find one

Browse /community. Every page says what the tool does, how to install it in one step, which platforms it runs on, what it asks for, and where the source is. Screenshots and the questions people ask are on the page too. Community apps also show up at the bottom of the app library, under "From the community", and inside the App Store in the OS, alongside the built-in apps.

Publish one

1. Fork the community tools repository.
2. Copy the template folder to tools/<name> and fill in tool.json: what the tool is, one-sentence summary, version, author, repository, licence, categories, how to install it, and the dates it was published and last updated.
3. Write README.md next to it - the long description on your page, in plain Markdown.
4. Run the checks, rebuild the manifest, and open a pull request.

Once merged, the page appears within the hour and stays in step with the repository from then on.

Sharing a skin

A skin is the one kind you never have to package by hand. Make one in the Skins app, press Share, and NextOS opens the pull request for you.

What happens when you press it:

1. The skin is checked again on the server - the format, every colour, the size caps, and the readability thresholds. A skin that would be hard to read comes back with the numbers and what to change, and nothing is opened.
2. Its own CSS is put through the sanitiser, and what survives is what gets published. Nothing that was dropped travels.
3. A folder is written on a new branch of the community tools repository: the listing, a README, the skin itself, and two pictures rendered from the skin rather than screenshotted.
4. A pull request opens, crediting you, and you get the link back straight away.

If a skin with your name is already there, the folder gets a number on the end and the response tells you which one it used. The listing appears at /community/<name> once a maintainer merges it, and anyone can then put it on from that page or from the Skins app's Community tab.

On jonkum.in you can open five a day. That is not about cost - it is about how many a person can reasonably ask someone else to read. (The counter lives in the deployment's key-value store; a self-hosted copy without one has no daily cap of its own, and leans on the GitHub token's rate limit instead.)

The maintainer sees a small, plain diff: five files under tools/<name>/, no generated manifest, and a description saying what the skin does. Rebuilding the manifest is their step on merge, so two people sharing on the same day never conflict with each other.

Doing it by hand, or self-hosting

The folder is five files and nothing is generated at install time, so you can just write one: tool.json with kind and install.kind both set to skin, README.md, skin/skin.json, and images/preview.svg and images/swatch.svg. The repository's own checks validate the skin against a JSON schema that is generated from the same rules NextOS enforces, so what passes there is what the OS will accept.

If you run your own copy of NextOS, the Share button needs two settings before it does anything - without them it answers "sharing unavailable" and the app offers you the file to download instead:

• COMMUNITY_GITHUB_TOKEN - a fine-grained token for the repository the pull requests should land in, with contents read and write and pull requests read and write, and nothing else. It is never written to a log and never comes back in a response.
• COMMUNITY_GITHUB_REPO - owner/name of that repository. Leave it out and pull requests go to the public one.

Skins that run code

A skin can also carry a small program with full, unsandboxed access to the running OS - the DOM, every store, the shell's own registries - for a look tokens and CSS cannot express on their own (see Skins). Sharing one from the Skins app is no different: press Share, and the pull request carries the program too, hash-verified the same way a Script's is. The listing gets a "Runs code" badge and shows what the program claims to do, straight from the same description NextOS shows before it ever runs. Installing one from /community/<name> still asks for a one-time approval the first time the code runs - a scripted skin is never trusted silently just because it came from the community index.

Sharing a script

A Script runs in NextOS's own sandboxed worker - code, bound to a command, an OS event, or a schedule. Its share flow is the code sibling of a skin's: the Scripts app sends its manifest, its compiled build and its source, and NextOS opens the pull request the same way, with two differences a skin never needs.

1. The server rebuilds the download zip itself, from the same files the request carries, and refuses if its hash disagrees with what the app claims it should be - the same hash pin NextOS checks again the moment someone installs it.
2. Only three kinds of file are ever accepted: the script's own src/** (kept for review, never shipped), its compiled build/** (what installs), and a README.md. Anything else in the request is refused outright.

The pull request lands as tools/<name>/script/: files/script.json (the manifest), files/build/*.js (compiled), script.zip and script.lock.json (both generated, hash-verified), plus src/** and the listing's own tool.json/README.md alongside it. Once merged, /community/<name> shows its permissions, the tools it calls and its triggers in plain words, and an Install in NextOS link installs it straight from the manifest's own download.

Sharing an extension

An Extension contributes commands, panels, context actions and hooks into NextOS's built-in apps, activated the first time one of those is used. Sharing one from the Extensions app follows the exact same rule as a script - the same file allowlist, the same server-side rebuild-and-hash-check - with one more thing to say: what it contributes. /community/<name> lists every slot in plain words - a context action here, a panel there, a before-hook on a note save - next to its permissions, so installing one is never a surprise.

The pull request lands as tools/<name>/extension/: files/extension.json, files/build/*.js (only when the extension has worker code at all), files/panels/*.html (the sandboxed webviews its panels/settingsSections/railCards point at), extension.zip and extension.lock.json, plus src/** alongside it.

What a listing carries beyond an app manifest

A native app manifest tells NextOS how to run an app. A community listing also has to be found and read on the open web, so it carries a plain one-sentence summary, an optional search title and share image, keywords, screenshots with descriptions, the questions people ask, categories, and the dates it was published and last changed. Those dates drive the sitemap, so a bumped updatedAt is how search engines learn a page moved on.

Rules

Only tools that exist and work today; plain descriptions, no keyword stuffing; images you have the right to publish; no secrets or personal data anywhere in a tool folder. Listings that break these are removed.