Marketplace

Documentation Index

Fetch the complete documentation index at: https://docs.slideless.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

What it is

The Slideless Marketplace is a public, npm-style catalog of presentations that anyone can browse and remix. Any account can slideless publish a deck as a listing; anyone — account or not — can slideless remix <slug> it to start a new project from those exact files. It lives at slideless.ai/marketplace and is backed by a small set of public Cloud Function endpoints. A listing wraps:

• A slug — the stable, human-readable id (acme/q4-template, pricing-calculator). Used in URLs and every CLI command.
• An immutable version pin — a listing always points at one frozen version of the source presentation. Publishing never silently changes what people download.
• Metadata: title, description, README, kind, interactive, category, tags, tech stack, status, owner.
• Three public counters: stars, remix count, and view count.
• Optional remix lineage — if the source deck was itself remixed from another listing, the listing records where it came from.

​

The three kinds

Every listing has a kind, set at publish time, that categorizes it by purpose. The boundary test is message / machine / blueprint: The boundary is about purpose, not mechanics: all kinds are HTML decks, all can be remixed. Ask yourself what is this for — to convey a message, to operate a machine, or to drive a build.

​

Interactivity is a badge, not a category

Every listing also carries a boolean interactive flag. Interactivity is orthogonal to kind — it is a badge, not a category:

• A presentation can be static or interactive. Both are still presentations.
• An app is always interactive (the backend forces interactive: true for app).
• For a presentation, interactive defaults to false.

The classic edge case: an interactive parametric cost-quote — a deck where the reader drags sliders to see prices update — is a presentation (with interactive: true), not an app. Its value is the author’s content and framing; the interactivity just makes the message land harder. It only becomes an app if the value is the machine itself, usable for any input regardless of the author’s content. slideless search --kind filters on kind; --interactive filters on the badge.

​

Tech stack

A listing can also declare a techStack: the technologies it is built with, or built for. It is a free-form list of lowercase technology slugs such as nextjs, firebase, tailwindcss, or n8n. Pass one canonical short slug per technology, with no display names and no version numbers. The backend only lowercases and hyphenates what you send; it never substitutes one value for another. Set it at publish with slideless publish --stack, and change it later with slideless listing update --stack. Slideless keeps a curated catalog of common technologies — the recommended vocabulary, and what the website renders a logo for — but techStack is not restricted to it: any lowercase slug is accepted, so niche technologies are fine. The tech stack is most useful for plan listings: a build plan is only worth remixing if it targets a stack you actually want to build on, so a remixer can run slideless search --kind plan --stack nextjs to find a plan for their stack. It works for any kind, though — an app can declare what it’s built with too.

​

Browsing — no account needed

Browsing is fully public. Listing the catalog, reading a single listing, and recording a remix require no API key:

• The website at slideless.ai/marketplace.
• slideless search and slideless listing get from the terminal.
• GET /listMarketplaceListings and GET /getMarketplaceListing over HTTP.

Only publishing, managing your own listings, and starring need an authenticated key.

​

Public vs unlisted

A listing’s status controls discoverability: unlisted is the way to share a remixable deck with a specific audience without putting it in the public index — a client template, a work-in-progress, an internal tool. There is no access check on an unlisted listing: the slug is the secret. Switch between the two at any time with slideless listing update <slug> --status.

​

Stars, remixes, and views

Each listing carries three public, GitHub-style signals:

• Stars (starCount) — an explicit bookmark/upvote. Star a listing with slideless star <slug> (needs a key), remove it with slideless unstar, and list your own stars with slideless stars. Star count feeds --sort stars.
• Remix count (remixCount) — incremented every time someone runs slideless remix <slug>. A usage signal, not a vote. Feeds --sort popular.
• View count (viewCount) — incremented every time the listing’s page opens on the marketplace website. The site fires POST /recordMarketplaceView once per session per listing, so a refresh in the same session does not double-count.

None of the three exposes who starred, remixed, or viewed — only the totals are public. slideless listing get shows all three.

​

Remix lineage

When a deck is created by remixing a listing, Slideless records that origin. slideless remix <slug> writes a small marker file — .slideless-remix.json — into the fresh folder, capturing the source slug, version, and title at the moment of the remix. The marker is not a slideless.json: the folder stays unlinked. On the first slideless push from that folder, push reads the marker and sends the lineage to the backend. The lineage is then stored on the new presentation once, at creation, and is immutable — later pushes never change it. When you slideless publish a listing from that presentation, the lineage is copied onto the listing too. A listing published from a remix exposes remixedFromSlug / remixedFromTitle, and its marketplace page shows a “Remixed from <original>” link back to the source listing. See Remixing templates for how the marker behaves if you move or delete it.

​

Remixes of this — descendants

The lineage is navigable in both directions. From any listing you can ask for the listings that were remixed from it: GET /listMarketplaceRemixes?slug=<slug> returns every public descendant listing. When descendants exist, the marketplace website shows a “Remixes of this” section on the listing page, and slideless listing get <slug> lists them too. Only descendants that have themselves been published appear here — remixing alone does not create a listing.

​

How it relates to the presentation lifecycle

Publishing is a layer on top of a normal presentation. The lifecycle is unchanged:

1. slideless push a deck — you now have a presentation with a version history.
2. slideless publish --kind … from inside that linked folder — Slideless creates a listing pinned to the current version.
3. Keep pushing new versions as usual. The listing does not move on its own — it stays pinned to the version you published.
4. To point the listing at a newer version, run slideless listing update <slug> --republish-version. To take it down, slideless unpublish <slug>.

​

Remix is not collaboration

Remixing and collaboration both move a deck between people, but they are fundamentally different: slideless remix <slug> writes the listing’s files into a fresh local folder with no slideless.json — so the folder is not linked to any presentation, including the original. It is a clean starting point. When you slideless push from it, you create your own new presentation, in your own organization, with its own version history. The original listing’s owner never sees your remix and is not affected by it (other than its remix count ticking up). The one thing carried across is lineage — a .slideless-remix.json marker the remix writes so that, if you later publish, your listing can credit the original (see Remix lineage). Lineage is attribution metadata; it grants no access and creates no live link in either direction.

​

Next

• Publishing to the marketplace — turn a deck into a listing, end to end.
• Remixing templates — search and remix a listing into a new project.
• Command reference — every publish / remix / search / listing / star flag.
• API keys — the marketplace:publish scope.