Install any skill in seconds. Free to start, no credit card required.
Get Started Free →vercel/router-act
How to write end-to-end tests using createRouterAct and LinkAccordion.
Passed 22 of 22 test cases with the skill, and 8 of 22 without it.
and 24 more in the full report
14 fixed8 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
In a Next.js router act test, a navigation triggers two separate prefetch network responses, both containing the literal string 'Item payload'. How should the assertions object/array argument be configured for act to match both responses? Options include single string, single object, array of objects, or regex.
| Checked | Without skill | With skill |
|---|---|---|
| Passes an array containing two separate { includes: 'Item payload' } objects to act. | Missed | Passed |
| Explains that each includes expectation entry claims exactly one matching response. | Missed | Passed |
The instructions your model reads when the skill loads.
Use this skill when writing or modifying tests that involve prefetch requests, client router navigations, or the segment cache. The createRouterAct utility from test/lib/router-act.ts lets you assert on prefetch and navigation responses in an end-to-end way without coupling to the exact number of requests or the protocol details. This is why most client router-related tests use this pattern.
actDon't bother with act if you don't need to instrument the network responses — either to control their timing or to assert on what's included in them. If all you're doing is waiting for some part of the UI to appear after a navigation, regular Playwright helpers like browser.elementById(), browser.elementByCss(), and browser.waitForElementByCss() are sufficient.
LinkAccordion to control when prefetches happen. Never let links be visible outside an act scope.'no-requests' whenever the data should be served from cache. This is the strongest assertion — it proves the cache is working.act utility exists specifically to replace inherently flaky patterns like retry() loops or setTimeout waits for network activity. If you find yourself wanting to poll, you're probably not using act correctly.block feature. It's prone to false negatives. Prefer includes and 'no-requests' assertions instead.// Assert NO router requests are made (data served from cache).
// Prefer this whenever possible — it's the strongest assertion.
await act(async () => { ... }, 'no-requests')
// Expect at least one response containing this substring
await act(async () => { ... }, { includes: 'Page content' })
// Expect multiple responses (checked in order)
await act(async () => { ... }, [
{ includes: 'First response' },
{ includes: 'Second response' },
])
// Assert the same content appears in two separate responses
await act(async () => { ... }, [
{ includes: 'Repeated content' },
{ includes: 'Repeated content' },
])
// Expect at least one request, don't assert on content
test cases passed, vs 8 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.