> ## Documentation Index
> Fetch the complete documentation index at: https://jam.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Prove a fix

> Have your agent record the fix running and post the Jam on the pull request or the ticket, with the browser's console and network attached.

A pull request that says "tested e2e locally" asks the reviewer to trust it. A short recording of the fix working lets them check. The Jam carries the browser's console and network, so a reviewer (a person or an agent) checks the request that used to fail without pulling the branch.

You end up with a Jam link on the pull request or the ticket that shows the fix running. When a still image says it better, such as a fixed layout or a corrected number, the agent files an annotated screenshot instead.

> [!NOTE]
>
> * A coding agent with your code open, such as Claude Code, Cursor, or Codex.
> * The [Jam CLI](https://jam.dev/docs/cli.md#quickstart), signed in. `jam doctor` says whether recording works on this machine.
> * The Jam skills. Install the Jam plugin (see [Connect your client](https://jam.dev/docs/jam-mcp.md#connect-your-client)), or run `npx skills add jamdotdev/skills`.
> * Browser pages record on macOS, Linux, and Windows. Recording an app window or a display needs macOS or Linux.

## Steps

**1. Ask for the fix and a recorded Jam**

```text wrap theme={"theme":"css-variables"}
Fix this, record a Jam showing it works, link it to this Jam and the pull request, and post it on the pull request: https://jam.dev/c/abc123
```

Say "record a Jam" in the request. "Verify it" alone may not record anything. Name where the Jam goes: either an open pull request or the ticket. Otherwise, ask for the link in the reply. "Link it" makes the proof findable from both sides: the bug Jam points to the fix, and the fix points to the pull request.

For a change that has no Jam, say "Record a Jam showing the new export button works." For a still image, say "Screenshot the fixed checkout page, box what changed, and file it as a Jam." After several fixes, get all the proof at once. Say "Give me the Jams for each fix."

**2. Check the claim in the Jam**

The title says what the recording shows, such as "Checkout completes after fix". Watch it through: it should start from a clean page and show the change. Then find the request that used to fail in the Jam's [DevTools](https://jam.dev/docs/devtools.md) and check its new status. A failing check still leaves a Jam, so a red run is visible instead of reported as a pass.

For several fixes, the agent returns one table. Each Jam is named and filed in one folder, and each row also links the ticket or the Jam it came from:

| Claim | Status | Jam |
| - | - | - |
| Pro price wraps on narrow cards | works | ENG-412 fix check: Pro price wraps |
| Sign-in after sign-out | broken | ENG-415 repro |

Status is one of works, broken, unconfirmed, or not recorded. Unconfirmed means the Jam does not settle the claim. Each row that is not "works" gets a line under the table that says why. Check the rows that say "works" the same way: open each Jam at the moment its claim shows.

**3. Check the links on both Jams**

Open the proof Jam's Info. The pull request is under **Resources**, and the bug Jam is under **Related Jams**. On the bug Jam, the proof shows as fixed by. Each Jam's timeline names who added the link, such as "via Claude Code". When a link is missing, say "Attach the pull request to the proof Jam and mark it as the fix for the bug Jam."

**4. Check the note on the pull request**

The agent posts the Jam link with a note on what the Jam shows. The note should claim only what you saw in the recording. Edit it, or ask the agent to, before anyone reviews the change.

## FAQ

> **What does the agent run?**
>
> By default it records a browser page, headless, over `--cdp`. That needs no screen permission, and nothing else from your machine appears in the video. It launches its own Chrome with a debug port and drives the page with your project's own driver, such as Playwright, or with [agent-browser](https://agent-browser.dev). It records one window only when the change needs the address bar, a native dialog, or an app that is not a browser. It records the whole display only as a last resort, and asks you first when someone is using the machine.
>
> It wraps the command that exercises the fix in `jam record run`, so the recording starts with the command and stops when it exits:
>
> ```bash theme={"theme":"css-variables"}
> jam record run --cdp 9222 --title "Checkout completes after fix" -- node e2e/checkout.js
> ```
>
> The command drives the recorded browser through the address the Jam CLI passes in `JAM_CDP_PROXY`, so the recording follows the page it opens and records its navigations. When there is no single command, the agent runs `jam record start` before the steps and `jam record stop` after them. The receipt prints the Jam's `url`.
>
> To link the Jams, it runs one command per link:
>
> ```bash theme={"theme":"css-variables"}
> jam update jam <proof-jam> --resource https://github.com/acme/app/pull/42
> jam update jam <proof-jam> --mark-related <bug-jam> --type fixes
> ```
>
> `--type proves` marks a Jam that shows a claim holds, rather than a fix. Every link flag is in [Create and update Jams](https://jam.dev/docs/cli-reference.md#create-and-update-jams).

> **What makes a good recording?**
>
> The agent follows these by default. Tell it when you want something different.
>
> * The title says what the recording shows: "Deep link scrolls to comment 6", not "proof".
> * It starts from a clean state: reload the page or restart the app first.
> * It is short. Show the change and stop.
> * `--cdp` is on whenever a browser is involved, so the console and network come along. Without it, the Jam is video only.
>
> When the change needs several checks, ask for one Jam per check. One long recording of everything goes unwatched. With one Jam per check, a reviewer opens the one that matters.
>
> Every `jam record` flag, receipt field, and platform note is in [Record a window or the desktop](https://jam.dev/docs/cli-reference.md#record-a-window-or-the-desktop).

> **How does the agent name and file the Jams in the table?**
>
> Each title is the ticket or the source, then what the Jam shows, such as "ENG-412 fix check: Pro price wraps". A Jam that checks a fix for an earlier Jam reuses that Jam's title with "fix check:" in front, so one search finds both. All the Jams from one run go in one folder. The agent renames and moves only the Jams it recorded.
>
> Before it lists a Jam, the agent opens it at the moment of its claim. A blank page, a frozen frame, or the wrong tab is not proof, so it records that claim again. A claim that happens off screen, such as an API status, is checked in the Jam's network, console, or user events, and the table says which part the video shows. The agent posts the table in chat. It posts it on the pull request or the ticket only when you ask.

> **When is a screenshot enough?**
>
> When the change is a state, not a flow: a fixed layout, a new label, a corrected number. The agent takes the screenshot, and the `jam-annotate` skill draws the marks into it and uploads it with `jam create jam`. Boxes and arrows get numbered badges that match the description, and the agent redacts the emails, names, tokens, and customer IDs it finds. Check the image before you share it. Keep it to three to five marks. A change that needs more is a video.
>
> A screenshot Jam the agent files carries no console logs or network requests. When the proof depends on them, such as a request that now returns 200, ask for a video. Every annotation type and payload field is in [Create and update Jams](https://jam.dev/docs/cli-reference.md#create-and-update-jams).

> **The Jam has video but no console or network**
>
> The recording ran without `--cdp`. Say "record over CDP" or point the agent at [Record an agent's browser](https://jam.dev/docs/cli-record-browser.md), which shows how to connect Playwright, agent-browser, and chrome-devtools-mcp to the recorder.

> **Can it record every test run, including in CI?**
>
> Yes. Wrap the test command in `jam record run` and sign in with a personal access token. See [Record end-to-end tests](https://jam.dev/docs/cli-e2e-tests.md).

> **Several agents record on one machine**
>
> Give each agent its own browser and debug port, so the recorder attaches to the right one. Pass `--folder` with one folder's name, so the proof lands in one place. Then ask one agent for the table. Say "Give me the Jams for each fix."


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.