The Kortix marketplace is the Kortix-native catalog. Every item is an open
git repo made of plain files — a whole clonable project (its kortix.yaml,
agents, skills, tools) or an individual skill / agent / tool. There is no
deterministic installer, no version lock, and no update system: you add an item
by importing it — reading its source and merging what fits into this
project's own files, then opening a change request. Everything you import becomes
100% user-owned files in this repo, exactly like any other code you write.
Why it works this way: the Kortix system layer (this kortix-* family, the
kortix CLI) is served live and always-latest, so it never goes stale. Marketplace
items are the opposite — they're yours to own and edit, so they're imported as
files, not pinned to an upstream that could clobber your changes.
kortix marketplace search "<query>" --json # find items (parse the JSON)
kortix marketplace show <id> --json # inspect one item: type, files, source repo
Read-only. There is no install / update / remove subcommand anymore —
adding an item is the import flow below.
- Get the source. From
kortix marketplace show <id> --json, take the item's
source git repo/ref (or its inline files). Clone/read it in the sandbox.
- Detect what it is from its file structure:
- a
kortix.yaml at the repo root → a project (agents + skills + tools +
config),
- a
SKILL.md → a skill,
- an agent definition (an
agents/*.md) → an agent,
- a tool file (a
tools/*.ts) → a tool.
- Merge what fits into this project, in the right place:
- skills →
.kortix/opencode/skills/<name>/,
- agents →
.kortix/opencode/agents/, tools → .kortix/opencode/tools/,
- for a whole project: pull in its skills/agents/tools and reconcile its
kortix.yaml into this project's (merge connectors/triggers/agents — never
blindly overwrite the user's manifest). Use judgment; keep what's relevant.
- Adapt it to this project. If a skill carries a "TODO: make this yours"
placeholder or generic copy, tailor it to what this project actually does.
- Wire up its needs. If the item requires a connector/secret, don't hardcode
anything — mint a setup link (
kortix secrets request … /
kortix connectors connect …) and surface it to the user.
- Commit + open a CR.
git add/commit, git push origin HEAD, then
kortix cr open --title "Import <item>". The user reviews the diff and merges
— that's how it becomes permanent (see kortix-system for the CR mandate).
Importing is just you reading files and writing files, landed through a change
request. No lock file, no tracked "installed" state — git is the source of
truth for what's in this project.
When the catalog has nothing that fits, the wider open ecosystem is still fair
game — npx skills find "<query>" searches skills.sh, and a skill from there is
just a SKILL.md plus references, so it merges in through the exact same import
recipe above. Either way you end up importing plain files you own.
1---2name: kortix-marketplace3description: The Kortix marketplace — how to discover capabilities and IMPORT them into this project. The marketplace is a catalog of open git repos: whole ready-made PROJECTS (registry:project) and individual skills/agents/tools. There is no deterministic 'installer' — you (the agent) import an item by reading its source and merging the files that fit into this project, then opening a change request. Use when the user wants to browse/search the Kortix catalog, 'add/clone the <X> project', 'import that skill/agent', pull in a marketplace capability, or add a new source.4---56<skill name="kortix-marketplace">78The **Kortix marketplace** is the Kortix-native catalog. Every item is an **open9git repo** made of plain files — a whole clonable **project** (its `kortix.yaml`,10agents, skills, tools) or an individual **skill / agent / tool**. There is **no11deterministic installer, no version lock, and no update system**: you add an item12by **importing** it — reading its source and merging what fits into this13project's own files, then opening a change request. Everything you import becomes14**100% user-owned files** in this repo, exactly like any other code you write.1516Why it works this way: the Kortix *system* layer (this `kortix-*` family, the17`kortix` CLI) is served live and always-latest, so it never goes stale. Marketplace18items are the opposite — they're *yours* to own and edit, so they're imported as19files, not pinned to an upstream that could clobber your changes.2021<discovery>22Browse/search the catalog from the `kortix` CLI (already authenticated here):2324```bash25kortix marketplace search "<query>" --json # find items (parse the JSON)26kortix marketplace show <id> --json # inspect one item: type, files, source repo27```2829Read-only. There is no `install` / `update` / `remove` subcommand anymore —30adding an item is the import flow below.31</discovery>3233<importing>34**The standard import recipe.** To add a marketplace item to this project:35361. **Get the source.** From `kortix marketplace show <id> --json`, take the item's37 source git repo/ref (or its inline files). Clone/read it in the sandbox.382. **Detect what it is** from its file structure:39 - a `kortix.yaml` at the repo root → a **project** (agents + skills + tools +40 config),41 - a `SKILL.md` → a **skill**,42 - an agent definition (an `agents/*.md`) → an **agent**,43 - a tool file (a `tools/*.ts`) → a **tool**.443. **Merge what fits into this project**, in the right place:45 - skills → `.kortix/opencode/skills/<name>/`,46 - agents → `.kortix/opencode/agents/`, tools → `.kortix/opencode/tools/`,47 - for a **whole project**: pull in its skills/agents/tools and reconcile its48 `kortix.yaml` into this project's (merge connectors/triggers/agents — never49 blindly overwrite the user's manifest). Use judgment; keep what's relevant.504. **Adapt it to this project.** If a skill carries a "TODO: make this yours"51 placeholder or generic copy, tailor it to what this project actually does.525. **Wire up its needs.** If the item requires a connector/secret, don't hardcode53 anything — mint a setup link (`kortix secrets request …` /54 `kortix connectors connect …`) and surface it to the user.556. **Commit + open a CR.** `git add`/`commit`, `git push origin HEAD`, then56 `kortix cr open --title "Import <item>"`. The user reviews the diff and merges57 — that's how it becomes permanent (see `kortix-system` for the CR mandate).5859Importing is just you reading files and writing files, landed through a change60request. No lock file, no tracked "installed" state — **git is the source of61truth** for what's in this project.62</importing>6364<projects>65A whole **project** item is the richest thing in the marketplace — a working,66end-to-end Kortix project focused on a function. You can spin it up as its **own67new project** (from the web UI's "Add to a project" → new project, which seeds68the files deterministically), or **import/merge it into this existing project**69via the recipe above to make this project bigger. It's all just files.70</projects>7172<adding-a-source>73To make another registry's items discoverable here, add it as a **source** — any74public git repo that ships `SKILL.md` files or a `marketplace.json` (e.g.75`anthropics/skills`, community repos from skills.sh). Curated sources enable in76one click; an arbitrary git URL is admin-gated. Once added, its items show up in77`kortix marketplace search`, and you import them the same way.78</adding-a-source>7980<outside-the-catalog>81This skill covers the Kortix catalog: whole projects + skills/agents/tools,82imported into this repo as owned files via a CR.8384When the catalog has nothing that fits, the wider open ecosystem is still fair85game — `npx skills find "<query>"` searches skills.sh, and a skill from there is86just a `SKILL.md` plus references, so it merges in through the exact same import87recipe above. Either way you end up importing plain files you own.88</outside-the-catalog>8990</skill>