jam-to-e2e git:20261022.cf595bbA

Immutable. This exact content never changes and is served at /api/v1/blob/d343847c3b65c8fd.

---
name: jam-to-e2e
description: Turn a Jam (a jam.dev screen recording with the console, network and user actions attached) into steps and an end-to-end test in the project's own runner and language, with first-class guidance for Playwright and tester-army/e2e, grounded in the current code. A Jam of a flow or demo becomes a test that guards it; a Jam of a bug becomes a failing test the fix turns green. Use when the user pastes a jam.dev link and asks for an e2e test, a regression test, a repro, or to "write a test for this".
---

# jam-to-e2e

The Jam shows what the user did and what the screen, console and network
did in return. The code shows what the labels and routes are today. The
tests assert what the product must do. One test per claim: a Jam that walks
through three screens is three tests, and a Jam of one bug is one.

A Jam is not always a bug report, so the user's request decides what the
test must do today, not the Jam:

- "Cover this flow", "write a test for this demo": the test asserts what the
  Jam shows and **passes** today. It guards the flow.
- "Regression test", "reproduce this bug", "test for this bug": the test
  asserts what should have happened and **fails** until the fix lands.
- Neither said: take the Jam's title and description as the hint, state
  which reading you took, and ask when you can.

## Pick the interface

Use the Jam MCP tools when they are connected. Otherwise read
[references/cli.md](references/cli.md) for the `jam` CLI setup; the table
below gives the command for each read.

## 1. Read the Jam

Fetch in this order and stop when you have the steps and the expected results.

| What | MCP | CLI |
| --- | --- | --- |
| Title, description, URL, type | `getDetails` | `jam get jam <id> --json` |
| Clicks, inputs, navigation | `getUserEvents` | `jam get user-events <id> --json` |
| What the reporter said | `getVideoTranscript` | `jam get transcript <id>` |
| What was on screen | `getFrames({ overview: true })` | `jam get frames <id> --overview` |
| Errors and requests, when the test is about them | `getConsoleLogs`, `getNetworkRequests` | `jam get console`, `jam get network` |

- Video Jams often carry the numbered steps in the title, not the description.
- User events can be empty, especially on extension recordings. Treat them as a
  bonus and fall back to the transcript and frames.
- Write down the **expected result** in one sentence. Most Jams do not state
  it. If the Jam and the user leave it unclear, ask. If you cannot ask, write
  the expected result you assumed and flag it in the hand-off; the expected
  result is the assertion, and a test with a guessed assertion proves nothing.

## 2. Ground it in code

Never take a label, route or button name from the Jam. Find the component
that renders the screen and read it. Labels get renamed, toasts get removed,
buttons become autosave. List every difference between the Jam and today's
code in your reply.

## 3. Pick the runner

Use what the project already has, in whatever language it is. Look for the
runner's config and existing end-to-end tests: `e2e.config.*`,
`playwright.config.*`, `cypress.config.*`, `pytest.ini` with
`playwright`, `wdio.conf.*`, Capybara specs, a `selenium` dependency, a
`make e2e` target. Reuse its fixtures, sign-in setup and page objects, put
the test next to the existing ones, and follow their naming. Run one with
the project's own command.

Only when there is nothing: Playwright, in the project's language, and say
so. For a JavaScript project the setup is
`npm init playwright@latest -- --quiet --browser=chromium` plus one test
file; `--quiet` takes the defaults without prompting.

The test title is the expected result in plain English. The first line is a
comment with the source Jam URL.

## 4. Write the test

These rules hold in every runner; the names of the calls differ.

- **Locate by what a person sees.** Role and accessible name, label,
  placeholder, visible text. Not parent traversal, CSS classes standing in
  for a label, or positional picks (last, nth). Those break on unrelated
  markup changes.
- **A control you cannot name is an accessibility bug.** Add the label or
  `aria-label` in the product when that is in scope and locate by it. When
  it is not, fall back to CSS and leave a comment naming the follow-up.
- **Assert what the server must have done.** A URL change, text that only
  exists after the action, or state that survives a reload. Wait on a
  network response only as synchronization, then still assert the visible
  outcome.
- **Assertions that retry.** Use the runner's auto-waiting expectation, not
  a one-shot read followed by a plain equality. The one-shot samples once
  and flakes.
- **Never** a fixed sleep, a loop that clicks whatever is visible, an
  assertion that only says the URL does *not* contain something, or a
  `try/catch` that turns a failure into `false`.

### Playwright

Locators: `getByRole`, `getByLabel`, `getByPlaceholder`, `getByText`, then
`.filter({ hasText })` to narrow. Assertions: `await expect(locator).toBeVisible()`,
`toHaveText`, `toHaveValue`, `toHaveURL`; never `expect(await locator.isVisible())`.
No `waitForTimeout`. The same calls exist in the Python, Java and .NET
bindings. https://playwright.dev/docs/best-practices wins any disagreement
with this file.

### tester-army/e2e

`e2e.config.*` and `*.e2e.ts` files mean [tester-army/e2e](https://github.com/tester-army/e2e).
Read `.agents/skills/e2e/SKILL.md` if it exists, or run `npx e2e guide`.
Agent steps (`agent.act`, `agent.assert`) are for reaching a state in plain
language; the claim the test exists for is still a locator assertion
(`expect(screen.getByRole(...))`), so it fails for the right reason. Run one
with `npx e2e run <file>`.

### Cypress

`cy.findByRole` and `cy.findByLabelText` from Testing Library give the
locators above; `should(...)` assertions retry on their own. No `cy.wait(ms)`.

## 5. Run it and check the reason

Run the test with the project's normal browser mode, headless by default.

- **Flow test:** it must pass, twice in a row, with no sleeps. A pass on the
  first run and a timeout on the second is a flaky locator, not a test.
- **Bug test:** it must fail **on the assertion that encodes the bug**, not on
  a locator timeout or a setup error. A test that fails for the wrong reason
  is not a repro yet. If the bug does not reproduce, say so: report what you
  ran, what you saw, and how it differs from the Jam (environment, data,
  account state). Do not weaken the assertion until it passes.

## 6. Hand off

Return:

1. The steps, numbered, as the tests perform them.
2. The test file paths and the command that runs them.
3. The run output: the passes, or each failure trimmed to its assertion.
4. Differences between the Jam and the current code.

For a bug test, the same test must pass twice in a row with no sleeps once
the fix lands. From then on the test is the source of truth; the Jam is the
evidence.

Offer to turn the passing run into an "after" Jam; do not create it without
a yes. With Playwright, run with `--trace on` and `video: "on"`, convert the
`.webm` to MP4 with `ffmpeg`, then `jam create jam` with `"kind":"video"`,
`videoPath` and `playwrightTracePath`; the trace's console, network and test
actions are synced to the video. With any other runner, record the run with
the `jam-proof` skill when it is installed, or `jam record run -- <test
command>`. Return the URL. Comment on the source Jam or post to a PR or
ticket only when the user requested that destination.

## Send feedback to Jam

When this skill, a Jam MCP tool, a `jam` command or a Jam doc was wrong,
stale or confusing, or worked unusually well, tell Jam. Send it yourself:
Jam's agents read it, so it needs no approval.

Call the `submitFeedback` MCP tool with `body`, `category` and `subject`.

When MCP is unavailable, use the CLI:

```bash
jam feedback "<what you were doing, what you expected, what happened, the mistake>" --category <skills|mcp|cli|docs> --subject <skill name, tool name or command>
```

- Jam surfaces only, not the user's code or other tools.
- At most once per session, and never for a slip you corrected yourself.
- No secrets, customer data, source code, stack traces or recording content.