Contributing to Undra Community

Thanks for thinking about adding something. This catalog is curated — we keep the bar high so anyone browsing trusts that resources work, are properly licensed, and aren't malicious. Here's the path to a merge.

What you can submit

The first four (template, skill, prompt, font) are tool-agnostic by design. Don't reach for extension just because Undra is in the URL — most submissions are not extensions.

Submission flow

1. Pick an id — kebab-case, globally unique across the catalog. Check index.json first.
2. Pick a starting version — 0.1.0 is conventional. Subsequent releases bump semver.
3. Create the folder at resources/<id>/<version>/.
4. Write manifest.toml following the SCHEMA. Required fields: id, type, version, name, author, description (≤ 200 chars), license. Plus a single [payload.<type>] table with the type-specific block.
5. Add the payload files alongside the manifest. The exact filenames must match what manifest.toml references.
6. Run validation locally: npm run validate. It checks the manifest shape, verifies referenced files exist, and surfaces warnings for missing binaries.
7. Build the index locally: npm run build:index regenerates index.json from your new manifest (and every other one).
8. Email us the change as a patch / zip / link to a fork at [email protected]. (A GitHub-based submission flow is on the roadmap — for now the catalog repo is private.)

We'll review for the criteria below and either merge with a redeploy or come back with specific changes.

Curation criteria

These aren't bureaucratic — they're the things that make the catalog feel trustworthy versus feeling like a dumping ground.

License must be clear and compatible

• Required: a valid SPDX identifier in manifest.toml (MIT, CC0-1.0, Apache-2.0, OFL-1.1, ISC, etc.).
• No "all rights reserved" content. The catalog is curated for free use.
• For fonts, OFL-1.1 / Apache-2.0 / proprietary-with-explicit-permission only.
• For everything else, anything OSI-approved or CC0 works.
• If you didn't write it, you must have permission to redistribute it under the declared license.

Resources must actually work

• Templates open cleanly in their declared itemType (note/plan/canvas/dashboard).
• Skills have the required Anthropic-style frontmatter (name, description) and produce useful output in at least one tool (Claude / Codex / Cursor / Undra).
• Prompts are tool-agnostic — they don't depend on a tool-specific feature unless that's the whole point.
• Fonts ship every face declared in [[payload.font.faces]]. No missing weights.
• Extensions activate without throwing (note: runtime activation is a roadmap item — extensions are accepted but currently install-only).

Descriptions must be honest

• The description is what shows on every card. ≤ 200 chars, plain prose, no marketing fluff.
• longDescription (optional) can expand into multiple paragraphs of markdown if there's more to say.
• Tag accurately. tags is used for search and routing — don't add irrelevant tags to game discovery.

Quality bar for AI resources (skills + prompts)

These resources affect AI behavior, which means a bad one is more than just unhelpful — it can produce misleading output. We ask that AI submissions:

• Solve a specific, narrow problem. "Help me write" is too broad; "Write a thorough code review for a diff" is concrete.
• Be tested in at least one model. Note in the description if results vary across models.
• Cite sources if instructions claim factual things ("X best practice" → link to where that comes from).
• Don't hardcode tool-specific magic unless it's explicit (e.g. a Cursor rule that only makes sense in Cursor should be tagged cursor).

Code resources (extensions, skills with tools)

If a resource declares capabilities or invokes tools:

• List every required capability in requiredCapabilities. Don't request what you don't use.
• The capability vocabulary is in SCHEMA.md. Stick to it; new capabilities need a coordinated change to the schema and the Undra extension host.
• Extension code must be readable. Obfuscated or minified bundles get rejected.

What we won't merge

• Anything that's behind a paywall, even partially.
• Marketing content disguised as a resource. ("Try our SaaS!" prompts are out.)
• Personal opinions / political content / NSFW.
• Resources that depend on services we can't verify (closed-source APIs you control, paid-only backends).
• Forks of existing catalog entries that don't add meaningful value.
• Anything that requires user data to leave their device by default.

Updating an existing resource

• Patch bumps (0.1.0 → 0.1.1) — fix a typo or shipping bug. Use the same folder with the new version number. Don't overwrite the old version; old installs reference it.
• Minor bumps (0.1.0 → 0.2.0) — backward-compatible changes (added an icon, expanded prompt).
• Major bumps (0.1.0 → 1.0.0) — breaking changes. Rename the resource id if the semantics changed dramatically.

Old versions stay in the catalog so users on the old install path don't break. Eventually we'll prune versions older than N — for now they accumulate.

Local development setup

git clone <undra-site-community repo>
cd undra-site-community
npm install
npm run validate
npm run build

npm run build produces dist/ — the exact files that get uploaded. Nothing outside dist/ ships to the live site.

Versioning the schema itself

If you propose a change to manifest.toml shape or index.json shape:

1. Update SCHEMA.md with the new field.
2. Update scripts/validate-manifests.js to accept (and ideally enforce) it.
3. Bump index.json's schemaVersion if it's a breaking change to consumers.
4. Update the in-app catalog reader types in undra-app/apps/desktop/src/extensions/firstParty/community/internal/community/types.ts.

A breaking schemaVersion bump requires coordinating an undra-app release that understands both old and new shapes.

Questions

[email protected]. We respond.