Community tools

Tools that people outside the core team build for NextOS - apps, 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.

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.