Verify a change

View as Markdown

Use /shiplight verify to check a UI change in the browser before you create a test or commit the code.

Verify the workflow

Describe the workflow and expected result. For example:

/shiplight verify https://www.saucedemo.com — log in as standard_user
with password secret_sauce, add the backpack to the cart, and confirm
the cart badge shows 1.

Add "record the session" if you also want Shiplight to save a video and trace.

Verify a page that requires login

If the page requires authentication, ask Shiplight to open it and wait while you sign in. Do not include private credentials in the request. For example:

/shiplight verify http://localhost:3000/dashboard — wait for me to sign in,
then save the session and confirm that the dashboard loads correctly.

When the browser opens, complete the login yourself and tell your coding agent when you are finished. Shiplight saves the cookies and local storage for that site, then reuses them in later verification sessions. If the saved session expires, the agent asks you to sign in again and saves the new session.

For OAuth, SSO, two-factor authentication, or other login flows that depend on a full Chrome profile, use a persistent Chrome profile.

Authentication for automated tests

The saved browser session described here is for interactive verification. To configure repeatable authentication for YAML E2E tests, run /shiplight auth and see Authentication.

Review the results

The agent first reviews your code changes and creates a verification plan that identifies the relevant pages, interactions, and expected results. It then completes the workflow in the browser and reports what it checked, whether the UI rendered correctly, any console errors or visual issues, and screenshots of the verified state.

If you requested a recording, the agent saves a video and Playwright trace when the session closes. It can also generate a shareable HTML report from the captured evidence.

The verification does not add or change files in your repository.

Do not use verify for changes that do not affect the rendered UI, such as backend-only logic, dependency updates, or documentation changes.

Save the workflow as a test

To repeat the same check in future runs, convert it to a test. /shiplight create-yaml-tests writes the workflow as YAML:

goal: A shopper can add a product to the cart
statements:
  - URL: /inventory.html

  - intent: Add Sauce Labs Backpack to cart
    action: click
    locator: 'locator(''[data-test="add-to-cart-sauce-labs-backpack"]'')'

  - VERIFY: The shopping cart badge shows the number 1
    js: 'await expect(page.locator(''[data-test="shopping-cart-badge"]'')).toHaveText(''1'', { timeout: 2000 })'

A saved test becomes part of your project and requires ongoing maintenance. See Decide what to test before converting an ad hoc verification into a permanent test.

Request browser actions

Describe browser actions in plain language:

• Click, type, select — "Click the Sign In button" or "Select 'Monthly' from the billing dropdown."
• Scroll, navigate — "Scroll to the pricing section" or "Go back to the previous page."
• Files — "Upload the file at /tmp/report.pdf."
• Keyboard — "Press Enter to submit" or "Press Escape to close the modal."
• Tabs — "Switch to the second tab" or "Close the current tab."

The MCP server performs these actions deterministically and does not require an LLM API key. For the complete tool list, see the MCP Tool Reference.

Choose another workflow

Situation	Instead
You want this checked on every future change	YAML E2E test
You don't know which flows are worth testing	Decide what to test
The login is slow or needs SSO	Persistent Chrome profile
An existing test is failing	/shiplight fix