Nexus · UnderstudyWrite prompts that
get results.
Understudy does what you ask in plain English — so the clearer the ask, the better the run. Here's the anatomy of a good instruction, worked examples that show which settings each one leans on, and how to build a prompt with assertions that produces a real pass/fail verdict.
Anatomy of a good prompt
Most reliable runs name these six things. You rarely need all six — include the ones that matter for your check.
https://www.sccu.com/es, not just "the site."demo-login."Not sure where to start? Type a rough draft in the composer and press Improve prompt. The built-in coach rates it, suggests fixes, and offers a ready-to-use rewrite — it won't invent a URL or an expected value you didn't give, it tells you to add them.
Examples by goal
Each example lists the settings it uses. The prompt is the plain-English part; the settings live in ⚙ Settings or on the saved test.
1 · Localization QA of a translated page
Open https://www.sccu.com/es and review it as a Spanish-speaking member. Check every visible heading, button, link, and menu for: - English text left untranslated - inconsistent formality (tú vs usted) - Title Case in headings (Spanish uses sentence case) - clipped or overflowing text Report each issue you find. Review the homepage and the main navigation only — don't sign in.
Why it works: concrete URL + persona + an explicit checklist of what "wrong" means + a tight scope. Understudy files each problem as a categorized finding.
2 · A sign-in flow with assertions
Go to https://app.example.com/login and start the sign-in flow with the email test@example.com. 1. Enter the email and continue. Expected result: a password field and a "Forgot password?" link appear. 2. Submit an empty password. Expected result: an inline error "Password is required" shows below the field. Stop before actually signing in.
Why it works: numbered steps, each with an inline Expected result: line. Understudy checks each one where it applies and combines them into a pass/fail verdict.
3 · An authenticated flow with a saved login
Go to https://app.example.com and sign in with the secret 'demo-login'. Once on the dashboard, open Account → Orders. Expected outcomes: - The most recent order shows status "Delivered". - The order total is formatted as USD, e.g. $42.00. - No error banner appears anywhere on the page.
Why it works: the password never appears in the prompt — only the secret's name travels. The three outcomes are each a single, checkable fact.
4 · A health sweep (console, network & accessibility)
Walk through the top three pages of https://www.example.com — home, pricing, and contact. On each page, note anything visibly broken, and let the automatic checks capture JavaScript errors, failed network requests, and accessibility violations.
Why it works: it leans on the passive capture toggles — you don't have to describe those checks, just turn them on. Scoped to three pages so it stays fast. Sonnet is plenty for a broad sweep.
5 · Video & media checks
Understudy tests video through the media element's state, not the pixels. Turn on Check video & audio and it flags failed sources, autoplay-with-sound, and missing or wrong-language captions automatically. To confirm a video actually plays, ask for it and add an expected outcome:
Open https://www.example.com and play the hero video. Expected result: the video plays — the timer advances past 0:00 and it is not paused. Expected result: closed captions are available in Spanish.
Why it works: "the timer advances and it is not paused" is a fact read from the media element — far more reliable than a screenshot, which can't tell a playing video from a frozen poster. The captions check doubles as a localization test.
Building a prompt for assertions
Assertions — "expected outcomes" — are what turn a run into a test. Understudy checks each one against the page and produces a pass/fail verdict, instead of just describing what it saw.
Two ways to write them
Inline — put an Expected result: line right after the step it applies to. Best when the check depends on getting to a certain point.
3. Add the item to the cart and open the cart.
Expected result: the cart shows 1 item and a subtotal of $25.00.
Listed — end the prompt with an Expected outcomes: block. Best for a handful of facts that should all hold at the end. (On a saved test, these go in the Expected outcomes field instead of the prompt.)
Complete the checkout with the test card, then verify: Expected outcomes: - The confirmation page reads "Payment received". - An order number in the format ORD-###### is shown. - A confirmation email row appears in the activity log.
Make each outcome checkable
Every outcome should be a single fact Understudy can see on the page. Quote the exact on-screen text where you can.
"Make sure the checkout works and everything looks right."
"A green 'Order placed' banner appears and the order shows today's date."
"The form validates and submits correctly."
"An empty email shows 'Email is required'."
"A valid email clears the error and enables Submit."
A template to start from
# optional setup Go to <URL> (and: sign in with the secret '<name>') # the steps, each with its own check where it matters 1. <do something> Expected result: <what should be true right here> 2. <do the next thing> Expected result: <what should be true right here> # or a final block of facts that should all hold Expected outcomes: - <single checkable fact, quoting on-screen text> - <single checkable fact>
The verdict: every outcome must pass for the test to pass. A missed check reads as fail, not a silent skip — so list only what you actually want enforced, and keep each one to a single, observable fact.
Settings cheat-sheet
Most settings need nothing in the prompt — you just turn them on. Here's when a setting also wants a word in the instruction.
| Setting | Say this in the prompt… |
|---|---|
| Model | Nothing — Opus by default. Drop to Sonnet or Haiku for broad, simpler sweeps to save cost. |
| Autonomy | Bound a guarded run: "stop before submitting," "don't sign in," "read-only — don't change anything." |
| Secrets | "Sign in with the secret name." The value never enters the prompt or the report. |
| Expected outcomes | Add Expected result: lines per step, or an Expected outcomes: list — that's what makes the verdict. |
| Console & network capture | Nothing extra — toggle it on. Add "note anything broken" and it'll surface JS errors and failed requests as findings. |
| Accessibility (axe-core) | Nothing extra — toggle it on; each page visited is scanned automatically. |
| Check video & audio | Toggle it on for automatic media findings. To verify playback, add "play the video" + an Expected result: that the timer advances. |