Prompt Management

Prompts are versioned templates a project owns, alongside its providers, routing, and traces. You author and maintain them in the dashboard; your application fetches the published version at runtime through an SDK — see the TypeScript and Python references for the runtime side. Open a project and select Prompts to reach the prompt directory at …/prj/<project>/prompts. The directory lists every prompt in the project with its status, a band of summary cards (prompt count, active releases, prompt fetches over the last 24 hours, rollbacks over the last 30 days), and tools to search, filter by status or environment, and sort. A prompt’s status is one of:

​

Creating a prompt

From the directory, choose New prompt. The first step asks for two things:

• Display name — the human-readable name (at least 2 characters), for example Customer support router.
• Slug — the lowercase, hyphenated identifier, prefixed by the project (<project>/<slug>). Letters, numbers, and hyphens only, at least 2 characters; it’s derived from the name until you edit it.

The slug and name must be unique within the project. Creating a prompt requires the prompt:create permission. Choosing Continue creates the prompt and drops you into the editor to build its first version.

​

Authoring a prompt

The editor opens on the Editor tab. A prompt version is an ordered list of blocks — the messages and instructions sent to the model.

​

Blocks

Each block has:

• A role — system, developer, user, assistant, or tool.
• Content — the text of the block, which may contain template variables.
• An optional condition — when set, the block renders only if the condition holds; otherwise it always renders.
• A required flag — required blocks can’t be deleted, so the structural shape of the prompt is preserved.

Add a block, edit it, duplicate it, move it up or down, toggle whether it’s required, or delete it. Deleting removes the block from the current draft; you can undo by re-adding it before you publish. A block condition is built from comparison rows (variable operator value, using operators such as ==, !=, in, contains, is_true) combined with and / or groups — so you can include a block only for, say, user_type == "admin".

​

Template variables

Reference a variable inside any block with {{ variable }}. Variables you reference are tracked in the editor, where you set each one’s type — string, text, number, boolean, enum, json, array, date, datetime, or message_list — whether it’s required, and an optional default. Your application supplies the values when it fetches the prompt. Editing a prompt’s blocks and variables, and publishing new versions, requires the prompt:create permission. With only prompt:read, the editor opens read-only.

​

Versioning and publishing

Editing always happens on a draft. Publishing freezes that draft:

1. Choose Publish in the editor.
2. The confirmation explains the effect: the current version vN becomes an immutable, read-only version, and a fresh vN+1 draft is started from the same blocks so you can keep editing without changing what’s published.
3. Confirm to publish.

A published version can never be edited — that’s what makes a release reproducible. To change a published prompt, edit the new draft and publish again. The other editor tabs work with this version history:

• Versions — the catalog of every version with its status, and the review panel (below).
• Diff — a block-by-block comparison between two versions, including the working draft against what’s published.
• History — the version lineage over time, showing who changed what.

​

Reviewing a version

A version can be reviewed before it’s released. On the Versions tab, a reviewer can record a decision — Approve, Reject, or Request changes — with an optional note, and later withdraw a rejection. Recording or withdrawing a review decision requires the prompt:review permission.

​

Releasing to environments

Publishing makes a version available; it doesn’t deploy it. To serve a version, promote it to an environment on the Releases tab, which shows one release per environment.

• Promote points an environment at a specific version.
• Roll back returns an environment to an earlier version.
• A release is either single — one version serves all traffic — or weighted, splitting traffic across versions for an A/B test or canary (for example, a 60/40 split across two variants).

Promoting, rolling back, and concluding an experiment require the prompt:publish permission.

​

Promotion policies

An environment can carry a prompt promotion policy that governs how versions move into it. A policy can require that a version was first promoted to a specific upstream environment, set a minimum dwell time before a rollback is allowed, restrict rollbacks within a lookback window, and require approval (optionally with separation of duties, so the promoter can’t be the approver). Managing these policies requires the env:policies:manage permission.

​

Maintaining prompts

From each row’s actions menu in the directory:

• Edit opens the prompt in the editor.
• Duplicate copies the prompt and its latest version into a new draft, named <name> (copy) with a -copy slug.
• Archive hides the prompt from the default view without destroying it.
• Restore brings an archived prompt back to active.

You can also change a prompt’s status and tags at any time, and select multiple prompts to act on them together from the bulk bar — set status, archive, restore, or duplicate the selection in one action. Each action is governed by the permissions below.

​

Permissions

Each prompt action is gated by its own permission, enforced server-side: A member with only prompt:read sees the directory and releases in read-only mode; creating, editing, and archiving are disabled. See Roles & permissions.

​

Next steps