agent sidequestsYour copy-and-paste prompt
Replace the [brackets] with your details, then paste this into your assistant.
Give me a hands-on tour of my latest app build at [authorized staging URL or test app]. Use only [test account and workspace]. The build is [version or deployment identifier], the time budget is [25 minutes], and the core journeys are [up to three journeys, each with its expected result]. Use [desktop and/or mobile viewport sizes]. Save the result in [private run folder or this chat]. Before interacting, confirm the environment and workspace match the supplied nonproduction details. Use only synthetic test data. The permitted actions are [specific test-record creation, editing and other bounded interactions]; everything else is out of scope. External email, messages, purchases and other real-world effects must be disabled or stubbed. Do not touch production, private customer records, billing, provider settings or real recipients. If the app redirects to production or the test boundary is unclear, stop that journey and explain the blocker. Use existing test access; do not create accounts or change permissions to get around a block. On the first run, create a baseline. Record the build identifier, time, role, viewport, relevant visible configuration and fixture names, then exercise the agreed journeys. Start from a known test state. For each journey, record the exact steps, expected outcome, observed outcome and a current screenshot at the meaningful moment. Judge completion by the resulting app state, not just a successful click. Mark each check passed, failed, blocked or not tested. If you cannot operate the app, produce an explicitly unrun checklist rather than a claimed tour. For a failure, capture a concise issue: user impact, route or screen, build, starting state, reproducible steps, expected versus actual behavior and screenshot references. Try the same bounded check once more from the documented starting state if safe; record both attempts and label inconsistent behavior. Do not modify product code, configuration or fixtures to make a failure disappear. Keep proposed fixes separate from observed findings. Do not file tickets or message the team. On later builds, repeat the same checks under comparable conditions and compare against the saved baseline. Call something a regression only if the earlier run passed the same check and the current run fails it; otherwise call it a newly observed issue or an uncertain comparison. Separate visible UI changes, observed behavior changes and changes mentioned only in supplied release notes. A screen you did not previously visit is newly inspected, not proof of a new feature. Keep the previous evidence and explain differences in role, fixtures, viewport or configuration that weaken a comparison. A staging result does not prove a feature is live in production. Return a short visual walkthrough, the build-to-build change list, a prioritized issue list and the coverage checklist, including blocked and untouched areas. Link every finding to this run's evidence. Redact secrets and any accidentally encountered personal data from screenshots and notes. State the limits of this small sample; passing these journeys does not establish that the whole app is bug-free. After the baseline is saved, recurring runs may use [requested schedule and timezone, or supported build trigger]. Configure only the trigger I specify through a supported mechanism and verify its saved status before calling it active. Keep a run ledger keyed by build identifier and test-plan version; do not duplicate a completed run for the same build unless I request a retest. If no background runner is available, return the tour now with a reusable checklist and say that nothing is scheduled. Keep all reports in the agreed private destination; no automatic external sends.
Automatic copying is unavailable. Select the prompt text above and copy it.