These Vitest prompts help turn a reported bug or a small module into tests with a clear purpose. The most important input is the behavior the module promises, including what happens when a dependency fails. A file full of assertions can still miss that contract if every collaborating function is replaced with a convenient fake. Start with one failing example and expand only where another case proves a different rule.
Supply the runtime and a real example
Give the agent your package manifest, Vitest configuration and a nearby test. Specify whether the code runs in Node, a simulated DOM or a real browser. Avoid asking it to upgrade the runner as part of writing a regression unless that upgrade is the task. Vitest's getting-started guide describes installation and configuration; check the requirements for the version actually installed in your project.
Include realistic inputs with identifying information removed. An empty object rarely reveals whether a parser handles a partially valid response. Two examples that differ at one important boundary give the agent a much stronger starting point.
Turn a bug report into a focused regression
Use this when you can describe a result that should change. Ask the agent to explain why the existing implementation produces the wrong answer before editing it. The explanation should reference a path through the code. This makes it easier to reject a test that merely restates the proposed implementation.
Write a Vitest regression for {{bug_report}} in {{module_path}}.
Read {{existing_test}} and the installed runner configuration.
Use the public behavior as the assertion boundary. Show a minimal input
that fails before the fix, then propose the smallest repair.
Run the targeted test. Report the failing and passing evidence separately.
Do not add unrelated coverage or change the runner version.
Make asynchronous failures observable
A promise resolving successfully and a background operation finishing successfully are different events. For a retrying operation, ask what happens after the last failure and whether the caller receives it. For cancellation, specify which resource should stop and which state must remain available. The prompt should require the agent to await the result under test.
Test the async behavior of {{operation_path}} using Vitest.
Cover success, rejection, cancellation and {{timeout_boundary}} where
those behaviors exist in the contract. Identify every promise and timer
the test must settle. Use controllable dependencies instead of wall-clock
sleeps. Explain how each test would detect an unhandled rejection or a
result that arrives after cancellation.
Review mocks for leaked state and false confidence
A mock review is especially helpful after a suite passes alone but fails with other files. Collect the failing invocation and the order of tests. Ask which state survives between cases before changing global cleanup settings. A reset that erases the behavior being tested can hide the original problem.
Audit mocks in {{test_file}} after this suite failure: {{output}}.
List module mocks, spies, timers and stateful fixtures. Trace which state
can survive between tests. Suggest scoped cleanup and a regression that
fails when {{leaked_state}} is left behind. Keep real parsing and business
rules intact unless isolation requires otherwise.
Keep the successful testing recipe
Review the final diff for assertions that would still pass if the important branch were removed. Also look for oversized snapshots that bury the changed field. A concise result should state the contract checked, the command run and any environment dependency that prevented execution.
Store the approved prompt in Kipt with variables for module, report and example test. Keep project conventions in the saved instructions, and provide fresh failure output each time. If the task concerns rendered form behavior, pair this collection with the Testing Library prompts.