Skip to main content
Today a bug report becomes a test when someone replays it and writes the repro steps by hand, and a demo never becomes one. Give your agent the Jam instead. The agent writes a test in your own runner: a failing regression test for a bug, or a passing test that protects a flow. The test’s first line links back to the Jam it came from. When the test fails later, the failure can come back as a Jam.
  • A coding agent with your code open, such as Claude Code, Cursor, Codex, GitHub Copilot CLI, or Gemini CLI.
  • The jam-to-e2e skill. Install the Jam plugin (see Connect your client), or run npx skills add jamdotdev/skills --skill jam-to-e2e. The source is in jamdotdev/skills.
  • Jam MCP or the Jam CLI, so the agent can read the Jam.
  • For a Jam of each failure in CI, the Jam CLI in the CI job and a personal access token.

​
Steps

1

Say which test you want

A Jam is not always a bug report, so your request decides whether the test must pass or fail today.
2

Read the hand-off

The agent returns the numbered steps in the order the test performs them, the test file and the command that runs it, the run output, and every difference between the Jam and your current code. Read the differences first. A renamed button is expected. A step that no longer exists means the flow changed since the recording.Then review the test as you would a colleague’s. Each test checks one claim. Locators find elements by role, label, or visible text. The assertion checks an outcome the person would see, such as a new URL or text that appears only after the action. There are no fixed sleeps.
3

Check why it passed or failed

Run the command from the hand-off twice. A flow test passes both times. A bug test fails on the assertion that encodes the bug, not on a locator timeout or a setup error. If the bug did not reproduce, the agent says so and what differed. Do not accept a test whose assertion was weakened until it passed.
4

Set up a Jam for every failure (optional)

Do this once per repo, and skip it when your suite already uploads a Jam of each failure. It changes the test config and the CI job, not the tests. From then on, every failure comes back the way the bug came in: a Jam with the video and the browser’s console and network. Hand it to your agent like any other Jam. See Hand a Jam to your agent.

​
FAQ

Title and description first, since narrated Jams often carry the numbered steps in the title. Then the user events for clicks, inputs, and navigation, the transcript for what the person said, and a frame overview for what was on screen. Console and network only when the test is about them. It writes the expected result down in one sentence, because that sentence is the assertion.Labels, routes, and button names come from the component that renders the screen today, never from the recording. That is where the differences in the hand-off come from.
It uses whatever runner the repo has, such as Playwright, Cypress, tester-army/e2e, pytest with Playwright, or Capybara. It follows that runner’s fixtures, sign-in setup, and naming. Only a project with no runner gets Playwright. One test per claim: a Jam that walks three screens is three tests.
Locators by role, label, and visible text. Assertions that retry. Outcomes the server must have produced: a URL change, text that exists only after the action, state that survives a reload. No fixed sleeps, no try/catch that turns a failure into false.
Yes, with the Jam CLI installed. Once the test passes, the agent offers an “after” Jam of the passing run. Say yes and it returns a link, so the ticket has the bug Jam, the test, and the proof. Say “Mark it as proof for the bug Jam and attach the pull request” and the bug Jam lists the passing run under Related Jams.
With Playwright, the test keeps the video and the trace of each failure, and a CI step uploads them with jam create jam. The Jam plays the video with the console and network from the trace.With any other runner, jam record run --cdp wraps the test command and records the browser while it runs. It records every run, passing or failing, and keeps the test’s exit code, so a failing test still fails the job.CI signs in with a personal access token in JAM_TOKEN. The commands are in Record end-to-end tests.
Yes, with limits. The agent takes the steps from the clicks and inputs when the Jam has them, and from the frames when it does not. It cannot know the expected result from a silent recording, so it asks you or names the result it assumed. Say the expected result in the prompt instead: “The order total should update when the coupon is applied.”
Anyone can record one, a customer can send one through a Recording Link, or the agent can record its own proof runs. See Request Jams from customers to create Recording Links from a script.