What should the recording prove?
Choose one observable claim about your change. Include the starting URL, the steps, and the expected result. A video shows the run; assertions establish whether the expected behavior occurred.
For example: “From Getting started, the CLI reference link opens the reference page, and the Playwright example contains a CDP connection.” For a bug fix, capture the same reproduction before and after the change.
Record the commit or build you tested, browser, viewport, and relevant test data alongside the link. These details make the result reproducible.
How do I ask my coding agent to record it?
First install and authenticate Rill in the environment where your agent runs. Browser recording requires macOS or Linux, Node.js 22 or newer, Chrome or Chromium, and ffmpeg. Your agent’s browser tool must connect to the existing browser over CDP.
Use Rill to record the changed flow at <app-url>.
Claim to verify: <expected behavior>.
Steps: <specific steps and test data>.
Run rill doctor. Start a recording and connect your browser tool
to the returned cdpUrl. Perform the steps in the recorded page
and check the expected result with assertions.
Stop the recording even if an assertion fails. Wait for status
ready and a non-null shareUrl, then run rill inspect on that URL.
Return the link, tested commit, passed and failed checks, and
anything you could not verify. Draft a PR evidence section.The underlying CLI loop is:
rill doctor
rill record start --url <app-url> --title "PR: <claim to verify>"
# Save recordingId and cdpUrl from the JSON response.
# Connect your browser tool to cdpUrl and perform your checks.
rill record stop <recording-id>
rill inspect <share-url>Use the actual values returned by Rill in place of the placeholders. Keep the recorded page open until stopping. The Playwright connection example shows how to use that page.
A successful stop returns status: "ready" and a non-null shareUrl. If processing is still underway or upload fails, resolve that before attaching the link. See recording recovery.
What does a real evidence recording look like?
This public example records a small navigation check on Rill’s own documentation: open Getting started, follow CLI reference, then open the Playwright example.
Recorded September 12, 2026 in Chrome at 1280 × 720. This seven-second video is an archived copy of a Rill capture. It has no spoken audio; the steps and results are described below.
Verified in this run
The CLI reference link reached /docs/cli, its heading was visible, and the Playwright section included chromium.connectOverCDP.
Outside this check
This run did not test login, billing, CLI installation, or every docs link. It demonstrates the evidence format; it is not a claim that the whole application passed.
What did the diagnostics show?
The capture reported eight console errors, eight HTTP errors, and two failed requests. The eight HTTP errors were 401 responses from /api/session while browsing signed out. The navigation assertions still passed. Error counts alone do not establish whether a particular product flow works.
Network-body capture was disabled and the diagnostic bundle was not truncated. This archived example includes the video and this diagnostic summary; your own ready Rill link lets reviewers explore the captured diagnostics.
For your own PR, replace this example with the changed flow and its assertions. Keep failed runs when they help explain the fix.
What should I put in the pull request?
Paste the ready recording link next to a short verification summary. State the tested commit and the result so reviewers know how the recording relates to the patch.
### Browser verification
- Tested commit/build: <commit SHA or build ID>
- Environment: <local/staging URL, browser, viewport>
- Claim: <expected behavior>
- Steps: <reproduction steps>
- Result: <passed, failed, or inconclusive, with assertion results>
- Recording: <ready Rill share URL>
- Before-fix recording: <link, if applicable>
- Not verified: <remaining cases or limitations>Open the link as a reviewer and check playback and diagnostics. If the code changes after the run, record again or state which revision the existing evidence covers.
Common questions
Can an AI agent inspect the recording?
Yes. Give it the share URL and ask it to run rill inspect <share-url>. That command returns bounded JSON context without a Rill login. A summary may be incomplete; use it with the captured evidence and the claim being checked.
Can I upload an existing Playwright video?
Yes. Run rill upload ./test-results/checkout.webm --title "Checkout test" and wait for readiness. Uploaded videos are video-only evidence: Rill does not reconstruct console logs, network events, or a Playwright trace from the video.
Does it record multiple tabs?
Capture follows the initially selected page. Keep the check in that page; new tabs and popups do not receive complete video and diagnostic coverage.
Who can view the link?
Anyone with an active share link can access its recording and shared diagnostics. A private PR does not make the Rill link private. Review the captured data before sharing, use test accounts, and read the privacy boundary.
Does a recording replace tests or code review?
No. A recording captures one execution. Keep automated tests and code review, and report the assertions and untested cases alongside the video.