arize-prompts

Arize Prompts Skill

SPACE — All --space flags and the ARIZE_SPACE env var accept a space name (e.g., my-workspace) or a base64 space ID (e.g., U3BhY2U6...). Find yours with ax spaces list.

Official references (read the skill body first; open docs only if the user needs UI walkthroughs):

• CLI: https://arize.com/docs/api-clients/cli/prompts
• Creating prompts in the product (Prompt Playground, variables, params): https://arize.com/docs/ax/prompts/tutorial/create-a-prompt

See references/cli-prompts.md for full flag tables.

---

How this skill fits into the prompt workflow

Skill	Use it for
This skill (arize-prompts)	Workflows A–B: build or import templates and save · C: labels / promote · D: list, get, edit description, new version for message changes, delete, duplicate
arize-prompt-optimization	Improving prompt text using traces, datasets, experiments, and the optimization meta-prompt — often after you know what to change
arize-experiment	Running dataset experiments that consume Hub prompts or column-mapped inputs
arize-evaluator	Scoring prompt outputs with LLM-as-judge

Typical loop: Author or elicit the prompt (Playground or chat) → save to Hub → run experiments (arize-experiment) → evaluate outputs (arize-evaluator) → optimize (arize-prompt-optimization) → save new version → promote with labels.

---

Concepts: what is a prompt in Arize?

A prompt in Prompt Hub is a named, versioned template stored in a space — not a one-off string in code. It is an artifact you can open in the Playground, diff across versions, and wire to experiments or production workflows.

Each prompt includes:

• Messages — an ordered chat transcript (system, user, assistant, tool roles) as stored JSON. Typically a system message for behavior and a user message as the template that receives dataset or runtime variables.
• Template variables — must be written with single curly braces around each name: { + identifier + } (same shape as {} with the variable name inside), e.g. {question}, {context}. Filled at runtime by experiments or your app. Always use --input-variable-format f_string for this style. Do not ask the user which variable format to use — default to f_string unless the template clearly uses Mustache {{...}} or you need none for literal braces with no substitution.
• Provider and model — the vendor and model this version targets. --provider is required by the CLI on every create and create-version. --model must always appear in commands this skill proposes — pick an explicit model string, propose a sensible default if unknown, and confirm before running.
• Invocation parameters — optional model settings like temperature and max tokens, configured under Params in the UI. CLI flows still require provider and explicit model alongside messages and format.
• Version history — every material change creates a new immutable version. Labels like production and staging are mutable pointers to specific versions so your app code never needs to change when you promote a new version.
• Version description — the optional text on Save New Version in the Hub UI is the same concept as --commit-message in the CLI.