arize-prompts

Arize Prompts Skill

SPACE — --space flags accept a space name (e.g., my-workspace) or a base64 space ID (e.g., U3BhY2U6...). Resolve a known name with ax spaces get NAME; ax spaces list is for human browsing.

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

For flags, run ax prompts <sub> --help. Gotchas and the messages shape: references/cli-prompts.md.

How this skill fits into the prompt workflow

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 {{...}} (use 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 (Params in the UI). On create / create-version, pass --invocation-params (JSON file or inline JSON); see ax prompts create --help.
• 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.