Concepts

Prompts and packages

A prompt lives at /{owner}/{slug}. Its content is a package: one or more files plus frontmatter.

• Kinds: text, chat, image, video, skill, rules, agent. The kind decides how the package renders and where it installs.
• Files: relative /-separated paths, at most 512 KB per file, 200 files and 5 MB per package. Skills can carry scripts and references next to SKILL.md.
• Entry file: the file that holds the prompt itself. It is detected by name (prompt.md, SKILL.md, agent.md, *.prompt.md, *.instructions.md, *.mdc, .cursorrules, AGENTS.md, CLAUDE.md, GEMINI.md, …). For a skill the shallowest SKILL.md wins.
• Frontmatter: YAML at the top of the entry file. Known keys are title, summary (alias description), kind, license, tags, targetModels (alias models), variables and contentRating; any other keys (name, allowed-tools, globs, applyTo, …) pass through untouched.

Variables

Templates use {{name}} and {{name|default}}; \{{ writes a literal {{. Anything that is not a valid variable name, such as {{#if}} or {{ user.name }}, is left as is, so Handlebars and Jinja content survives.

Variables can be typed in frontmatter:

variables:
  - name: language
    type: enum
    options: [Go, Python, TypeScript]
  - name: code
    type: string
    multiline: true
  - name: strict
    type: bool
    default: false

Types are string, enum, number, bool and file. A variable is required when the body uses it and it has no default. Rendering is pure templating: nothing is sent to a model. The website, API, SDKs, CLI and MCP server all use the same engine, so a prompt renders identically everywhere.

Chat prompts

A chat prompt splits its entry body into messages on level-2 headings:

## system
You review {{language}} code.

## user
{{code}}

The split happens before variables are substituted, so a value can never add or reorder messages.

Versions

Every commit creates a new version: v1, v2, … numbered densely per prompt.

• Versions are immutable. Each has a contentHash (algorithm incantory-tree-v1) over its files and frontmatter; the SDKs recompute it on download and refuse a mismatch.
• A commit identical to the latest version is refused (409 no_changes). A commit made against an older base is refused with 409 stale_base so concurrent edits are never silently overwritten.
• A version cannot be deleted, only yanked. A yanked version is hidden from lists and cannot be the target of a label, but still resolves when pinned, with a Deprecation header.
• Restoring an old version commits its content as a new version.

Labels

A label is a named, movable pointer to a version, like production or staging. Consumers ask for the label; you release by moving it.

• Every move is recorded in the label history (who, when, from which version, why).
• A protected label can only be moved by the owner or an admin, and changes to it are audited.
• A label with requirePassingEval can only move to a version that has a passing eval run (403 eval_required); see Evals and the CI gate.
• A label cannot point at a yanked version (403 version_yanked).

Refs

Every client accepts the same reference syntax:

Pin @vN (or use an incantory.lock file) when you need reproducibility, and a label when you want releases to reach you.

Drafts and publishing

A prompt can start as a draft: a working copy only its owner sees. Publishing commits the draft as v1. After that, the editor keeps a working draft for the next version, and the CLI or API can commit complete packages directly. Visibility is public or unlisted (readable by link, never listed).

Forks

A fork copies a version into your namespace as a new prompt. The fork remembers its parent version, so its page shows where it came from, and the parent's license rules follow it (see below).

Change requests

A change request proposes a version from a fork back to the original prompt. The target's owner reviews the diff, discusses it in comments and merges it, which commits a new version with the fork author credited as co-author.

Attribution and licenses

Every prompt carries an SPDX license. Prompts people publish here use CC0-1.0, CC-BY-4.0 (the default), CC-BY-SA-4.0, MIT or Apache-2.0. Imported collections keep their upstream license and a pinned link to the source commit.

Every prompt has an attribution chain: the original source, then each fork parent, then the current author. The same chain appears on the page, in the API and in exports. A fork of a share-alike prompt must stay share-alike. See Content licenses.