verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verify UI Changes

验证UI变更

Use the Shiplight MCP browser tools to visually verify that your code changes look and behave correctly in a real browser.

使用Shiplight MCP浏览器工具，在真实浏览器中直观验证代码变更的外观和行为是否符合预期。

When to use

适用场景

Use

/verify

after making UI changes to confirm they render correctly. This is useful for:

Checking layout, styling, or component changes visually
Verifying interactive behavior (clicks, form inputs, navigation)
Pre-commit sanity checks on UI work
Debugging visual regressions

在进行UI变更后使用

/verify

命令，确认渲染效果是否正确。适用于：

直观检查布局、样式或组件变更
验证交互行为（点击、表单输入、导航）
UI工作提交前的 sanity 检查
调试视觉回归问题

When NOT to use

不适用场景

Skip

/verify

when changes don't affect UI rendering:

Backend-only changes (API logic, database, config)
Dependency version bumps with no UI impact
Documentation, comments, or test-only changes

当变更不影响UI渲染时，无需使用

/verify

：

仅后端变更（API逻辑、数据库、配置）
无UI影响的依赖版本更新
文档、注释或仅测试代码的变更

Steps

操作步骤

The following steps are a general guideline — adapt based on what makes sense for the specific changes:

Understand what changed — analyze the code changes and build a verification plan:
- What files/components changed
- What pages and interactions to check
- Pass/fail criteria (what "correct" looks like)
This is the most important step — it determines your test coverage. Balance thoroughness with cost.
Start the dev server (if not already running) — check if the app's dev server is running. If not, start it in the background using the appropriate command (e.g.
```
npm run dev
```
,
```
yarn dev
```
). Wait a few seconds for it to be ready.
Open a browser session — call
```
new_session
```
with the
```
starting_url
```
pointing to the page you want to verify. If you want to generate a report afterwards, set
```
record_evidence: true
```
. Multiple concurrent sessions are supported — you can open several to compare different pages or states.
Inspect the page — call
```
inspect_page
```
to get the DOM tree with element indices and a screenshot. Always read the DOM file first — it provides the element indices needed for
```
act
```
and consumes far fewer tokens. Only view the screenshot when you specifically need visual information (layout, colors, images), as screenshots consume significantly more tokens than DOM.
Interact and verify — use
```
act
```
to simulate user actions based on the element indices from
```
inspect_page
```
. Use
```
act
```
with verify actions to assert expected UI state (e.g. text is visible, element exists).
Check for errors — call
```
get_browser_console_logs
```
to check for any JavaScript errors that may have been introduced.
Report findings — summarize what you verified:
- What pages/components were checked
- Whether the UI renders correctly
- Any console errors or visual issues found
- Screenshots showing the verified state
Close the session — call
```
close_session
```
when done. It returns
```
local_video_path
```
and
```
local_trace_path
```
.

Generate the report — if the session was started with

record_evidence: true

, call

generate_html_report

with the local paths:

json

{
  "session_id": "<session_id>",
  "local_video_path": "<local_video_path from close_session>",
  "local_trace_path": "<local_trace_path from close_session>",
  "title": "...",
  "summary": "...",
  "checks": [...]
}

Show the returned

file_path

to the user so they can open and review it.

Upload the report for sharing — when the user wants a shareable link (e.g. to attach to a PR), and
```
upload_html_report
```
is available:
json
```
{
  "report_path": "<file_path from generate_html_report>",
  "local_video_path": "<local_video_path from close_session>",
  "local_trace_path": "<local_trace_path from close_session>"
}
```
This uploads the video, trace, and report HTML to Shiplight cloud, patches the HTML with cloud URLs, and returns a permanent shareable
```
report_url
```
.

以下为通用指南，可根据具体变更调整：

明确变更内容 —— 分析代码变更并制定验证计划：
- 哪些文件/组件发生了变更
- 需要检查哪些页面和交互
- 判定标准（“正确”的效果是什么样的）
这是最重要的一步——决定了测试覆盖范围。需在全面性和成本之间找到平衡。
启动开发服务器（若未运行）—— 检查应用的开发服务器是否已启动。若未启动，使用对应命令在后台启动（例如
```
npm run dev
```
、
```
yarn dev
```
）。等待几秒直至服务器就绪。
打开浏览器会话 —— 调用
```
new_session
```
，将
```
starting_url
```
指向需要验证的页面。若后续需要生成报告，设置
```
record_evidence: true
```
。支持多并发会话——可打开多个会话以对比不同页面或状态。
检查页面 —— 调用
```
inspect_page
```
获取带元素索引的DOM树和截图。请优先查看DOM文件——它提供了
```
act
```
命令所需的元素索引，且消耗的token远少于截图。仅当需要获取视觉信息（布局、颜色、图片）时才查看截图，因为截图消耗的token远多于DOM。
交互与验证 —— 根据
```
inspect_page
```
返回的元素索引，使用
```
act
```
模拟用户操作。结合验证型
```
act
```
操作断言预期UI状态（例如文本可见、元素存在）。
检查错误 —— 调用
```
get_browser_console_logs
```
检查是否引入了JavaScript错误。
报告验证结果 —— 总结验证内容：
- 检查了哪些页面/组件
- UI渲染是否正确
- 发现的任何控制台错误或视觉问题
- 展示验证状态的截图
关闭会话 —— 完成后调用
```
close_session
```
，它会返回
```
local_video_path
```
和
```
local_trace_path
```
。

生成报告 —— 若启动会话时设置了

record_evidence: true

，使用本地路径调用

generate_html_report

：

json

{
  "session_id": "<session_id>",
  "local_video_path": "<local_video_path from close_session>",
  "local_trace_path": "<local_trace_path from close_session>",
  "title": "...",
  "summary": "...",
  "checks": [...]
}

将返回的

file_path

告知用户，以便他们打开查看报告。

上传报告用于分享 —— 当用户需要可分享链接（例如附加到PR）且
```
upload_html_report
```
可用时：
json
```
{
  "report_path": "<file_path from generate_html_report>",
  "local_video_path": "<local_video_path from close_session>",
  "local_trace_path": "<local_trace_path from close_session>"
}
```
此操作会将视频、追踪文件和报告HTML上传至Shiplight云，用云URL修补HTML，并返回永久可分享的
```
report_url
```
。

Apps that require login

需要登录的应用

If the app requires authentication, log in once and save the session so future sessions skip the login step:

Open a browser session with
```
new_session
```
at the app's login page.
Ask the user to switch to the browser and log in manually. Wait for them to confirm.

Call

save_storage_state

to save cookies and localStorage to

~/.shiplight/<site_url>/storage-state.json

(e.g.

~/.shiplight/http_localhost_3000/storage-state.json

For all future sessions, pass the same path as
```
storage_state_path
```
to
```
new_session
```
to restore the authenticated state instantly.

If a saved storage state file already exists, use it automatically. If authentication fails with a saved state (page redirects to login, auth errors in console), the state is likely expired — ask the user to log in again and re-save.

若应用需要认证，只需登录一次并保存会话，后续会话可跳过登录步骤：

在应用的登录页面调用
```
new_session
```
打开浏览器会话。
请用户切换到浏览器手动登录。等待用户确认登录完成。

调用

save_storage_state

将cookie和localStorage保存至

~/.shiplight/<site_url>/storage-state.json

（例如

~/.shiplight/http_localhost_3000/storage-state.json

）。

后续所有会话中，将同一路径作为
```
storage_state_path
```
传入
```
new_session
```
，即可立即恢复认证状态。

若已存在保存的存储状态文件，自动使用该文件。若使用保存的状态认证失败（页面重定向到登录页、控制台出现认证错误），则状态可能已过期——请用户重新登录并重新保存状态。