Prompts

Versioned prompt templates stored in your workspace. Edit in the dashboard, load by name from code, pin per experiment.

The Prompt service stores prompt templates as workspace-versioned resources. Edit a template in the dashboard, render it at runtime with variables, and pin a specific version to an experiment so old runs stay comparable after edits.

Anatomy

{
  name: "faq-system",
  template: "You answer FAQs about {{ product }}.\n\nQuestion: {{ question }}",
  variables: ["product", "question"],
  version: 7,
}

Create or update

import { Polarity } from "@polarityinc/polarity";
 
const plr = new Polarity();
 
await plr.prompts.create({
  name: "faq-system",
  template: `You answer customer FAQs about {{ product }}.
 
Rules:
- Cite the doc when possible.
- If you don't know, say so.
 
Question: {{ question }}`,
  variables: ["product", "question"],
});

Re-calling create() with an existing name bumps the version. Use update() if you want to fail when the name doesn't exist.

Load and render

import { loadPrompt, renderTemplate } from "@polarityinc/polarity";
 
const prompt = await loadPrompt("faq-system");                    // latest version
const pinned = await loadPrompt("faq-system@v7");                 // specific version
 
const rendered = renderTemplate(prompt, {
  product: "Polarity",
  question: "How do I cancel?",
});
 
await anthropic.messages.create({
  model: "claude-sonnet-4-5",
  system: rendered,
  messages: [{ role: "user", content: userInput }],
});

Pin per experiment

In a spec:

prompts:
  faq-system: v7        # pin
  greeting: latest      # explicit latest (default)

Pinning makes old experiments reproducible — even after you edit the prompt, the pinned version is what loadPrompt("faq-system") returns inside that experiment's sandbox.

Live A/B

Weight multiple versions to split traffic per sandbox:

prompts:
  faq-system:
    type: weighted
    versions:
      v7: 0.5
      v8: 0.5

Each run picks a version by weight; scoring slices results per version so you can compare on the same metrics. Useful before promoting a new prompt to production.

Where prompts appear

Dashboard → Polarity → Prompts. Each prompt shows version history with diff, which experiments use which version, and per-version scoring distribution.

Why a managed Prompt service

If your prompts live in code, every prompt change requires a deploy, and there's no versioned history. The Prompt service inverts that: non-engineer teammates can edit and ship prompts from the dashboard, and you keep determinism by pinning versions in specs that matter.

If you only have one prompt that never changes, just put it in a string literal — the Prompt service is for the ones that do change.