Use case · Developers

Prompts in review, like the rest of your code.

If a prompt decides what your product says, it needs a history, a test and an owner.

support-reply.promptv2 → v3
committed to main as v3

A workflow that feels familiar.

  1. Keep the prompt out of the code

    Store it in Prompt Verse with {{variables}}. Your code asks for the rendered messages, not a string it pasted in.

  2. Branch for an experiment

    Try a new wording on a branch. Main keeps serving the version in use.

  3. Prove it with an eval

    A few dozen cases, a scoring method and a threshold. A change that drops the score does not get merged.

  4. Tag what ships

    Tag the version that passed. Your service fetches that tag.

What you get, concretely.

  • Commits with messages

    A reviewable history instead of “prompt_final_v7”.

  • Messages and JSON out

    Render as chat messages, JSON, YAML, XML or Prompty.

  • A door for your agents

    Your coding assistant can read and improve prompts over MCP.

Be clear about the edges.

  • Pre-beta
    Fetching at run time

    An HTTP API and an MCP server exist in the pre-beta. Check the reference for the routes before you depend on them.

  • Not offered
    No SDK yet

    There are no client libraries. You call the HTTP API or MCP directly.

Put your prompts under version control.