Jest prompts are most useful when they make a test's reason visible. A good regression says which input used to fail and what a caller should receive. A mock should isolate an external boundary without deciding the answer in advance. This collection focuses on those decisions: reproducing a defect, making asynchronous errors fail the test, and improving assertions that have become difficult to review.
Start from the project's actual Jest setup
Supply the target file, package manifest, configuration and a representative test. Identify whether the project uses CommonJS or ES modules and which environment runs the tests. Configuration matters because examples from another repository may rely on different transforms or setup files. The official Jest introduction demonstrates test structure and explains TypeScript integration; use the documentation matching your installed release for specific APIs.
Tell the agent whether it may edit production code. A review-only request and a bug-fix request need different outputs. In both cases, require it to report commands actually run rather than treating generated code as a verified result.
Reproduce the smallest incorrect behavior
Begin with a concrete example from an issue or support report. Remove unrelated data while preserving the rule that fails. Ask the model to state the expected result in ordinary language first. If nobody can explain why that expectation is correct, the missing input is a product decision, not another matcher.
Create a Jest regression for {{reported_bug}} in {{target_module}}.
Read {{nearby_test}} and the test setup before choosing APIs.
Explain the input, expected result and current failure. Write one focused
test through the public interface. If authorized, apply the smallest fix.
Run the existing targeted command and report the observed outcome.
Keep unrelated refactoring out of this change.
Make errors from async work reach the test
An asynchronous test can accidentally finish before its important assertion runs. For callbacks, promises and timers, ask the agent to identify completion explicitly. Include the expected failure path, not only the successful response. If a test uses a fake clock, review how its pending work is drained and restored before the next case.
Review asynchronous tests in {{test_file}} for false passes.
Trace returned promises, callbacks and timer-driven work. Find assertions
that can run after Jest considers a test complete. Add a rejection case
for {{dependency_failure}} and make completion explicit using our
existing style. Explain which broken implementation each test detects.
Replace noisy assertions with readable contracts
Large snapshots can make a reviewer approve unrelated changes simply to unblock a build. Pick one snapshot that is frequently updated and ask what it protects. Sometimes a short snapshot is the clearest answer. Sometimes three field assertions explain the contract better. Judge the result by review clarity, not the number of lines removed.
Improve assertions in {{test_file}} without reducing useful coverage.
For each broad snapshot, name the contract it protects. Keep snapshots
with a clear purpose; replace the rest with focused assertions.
Review mocks for return values that bypass the behavior under test.
Show one deliberate behavior change that the revised test would reject.
Review the result before saving the recipe
Check that failures point at meaningful expectations rather than incidental object layout. Inspect fixture names, cleanup and any changed setup file. A small regression should not require a new global convention without a concrete reason. Keep the full-suite invocation for changes that affect shared setup or module loading.
Save the prompt that fits your repository in Kipt with blanks for target module, example test and defect evidence. Keep test reports as fresh inputs. For a Vite-based runner, the Vitest prompts cover the equivalent workflow without assuming identical configuration.