# 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 | Type | What it is | Useful in | |---|---|---| | **Template** | A starter file — a note, plan, canvas, or dashboard | Undra; any markdown editor | | **Skill** | An AI capability bundle (Anthropic-style `SKILL.md`) | Undra, Claude, Codex, Cursor — drop in or paste | | **Prompt** | A markdown prompt body | Any AI chat (Claude / ChatGPT / Codex / Cursor) | | **Font** | A `.woff2` typeface family | Undra UI/editor; any web project | | **Extension** | Undra-specific sandboxed script | Undra only | 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///`. 4. **Write `manifest.toml`** following the [SCHEMA](SCHEMA.md). Required fields: `id`, `type`, `version`, `name`, `author`, `description` (≤ 200 chars), `license`. Plus a single `[payload.]` 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 . (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](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 ```bash git clone 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](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 . We respond.