User guide
For prompt engineers, PMs, and anyone who edits prompts — no Git knowledge required.
Prompts & versions
A prompt is a named piece of text your product uses. Each time you save an edit, PromptVCS records a new version with a tag (v1, v2, …), a note, and a timestamp. You can always view or restore an earlier version.
Example. A welcome-email prompt starts at v1: “Write a friendly welcome email for a new user.” You edit it to add “Keep it under three sentences and use the user's first name,” save with the note “tighten + personalize,” and that becomes v2 — with v1 still there to restore.
Comparing versions
The Diff tab shows exactly what changed between two versions — added text in green, removed in red, down to the word. When the versions have been tested, the diff also shows the change in eval score, so you know whether an edit helped or hurt.
Example. Diffing welcome-emailv1 → v2 highlights the new “under three sentences” sentence in green, and if v2 scored 92% vs v1's 80%, the diff shows +12% — clear evidence the edit helped.
Testing a prompt
Under Tests, add cases that describe what a good answer looks like. You do not need to know any code.
Anatomy of a test case
Every case has four parts:
- Name — a label for you, e.g. “Stays concise”.
- Input — the message sent to your prompt to produce an answer. The test scores that answer, so the input is what you want to try the prompt against.
- Check type — the one rule that decides pass or fail (see below). Each case has exactly one check.
- The check's setting — depending on the check, either a piece of expected text / criteria or a number. The builder only shows the box the check actually uses.
Because a case has one check, test two things by making two cases over the same input — e.g. one “Within length” case and one “AI judge” case that grades whether it politely declines.
Which check uses which field
Pick the check for the property you care about, then fill only the field it reads:
| Check | What it does | Field it uses |
|---|---|---|
| Must mention | Passes if the answer contains your text | Expected text |
| Must not mention | Passes if the answer avoids your text | Expected text |
| Matches pattern | Passes if the answer matches a regular expression | Pattern |
| AI judge | An AI grades the answer against criteria you write | Criteria + threshold (0–1) |
| Within length | Passes if the answer stays under a character limit | Max characters |
| Valid JSON | Passes if the answer parses as JSON | None |
| No personal data | Passes if no emails, phone numbers, cards, or IDs appear | None |
| Sentiment | Checks the answer's tone | None |
A common mix-up: “Within length” only counts characters — it ignores any criteria. To check meaning(“politely declines”, “answers the question”), use AI judge.
Example: a few cases for a support assistant
Say you have a support-assistant prompt. A useful starter suite might be:
| Name | Input (sent to the prompt) | Check | Setting |
|---|---|---|---|
| Greets by name | “Hi, I'm Dana — my order is late.” | Must mention | Dana |
| Stays concise | “What's your return policy?” | Within length | 400 |
| Declines off-topic | “Write a poem about my cat.” | AI judge | “Politely declines and steers back to support” · 0.7 |
| No card leak | “My card 4111 1111 1111 1111 — did it charge?” | No personal data | — |
| Status as JSON | “Give me order #123's status as JSON.” | Valid JSON | — |
Each row is one case. “Stays concise” and “Declines off-topic” could even share an input — they're separate cases because each tests one thing.
Run the suite and review each case's pass/fail with the model's actual output.
Environments & deploying
Prompts move through development → staging → production. Deploying promotes a version to an environment; your app reads whichever version is live in the environment it asks for. If a change causes problems, roll back in one click.
Example. You edit welcome-email to v5 and deploy it to staging to try it. It looks good, so you deploy the same v5 to production. A day later someone reports an issue — you redeploy v4 to production to roll back instantly, then keep fixing toward v6 on staging. Production and staging point at different versions the whole time, with no code change or redeploy of your app.
Activity
The Activity view is a running log of who created, tested, deployed, or rolled back what — so the whole team always knows the current state.