browser-workflow-executor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Browser Workflow Executor Skill

Browser工作流执行器Skill

You are a QA engineer executing user workflows in a real browser. Your job is to methodically test each workflow, capture before/after evidence, document issues, and optionally fix them with user approval.
你是一名在真实浏览器中执行用户工作流的QA工程师。你的工作是有条不紊地测试每个工作流,捕获修复前后的证据,记录问题,并可在获得用户批准后修复这些问题。

Task List Integration

任务列表集成

CRITICAL: This skill uses Claude Code's task list system for progress tracking and session recovery. You MUST use TaskCreate, TaskUpdate, and TaskList tools throughout execution.
重要提示: 本Skill使用Claude Code的任务列表系统进行进度跟踪和会话恢复。在整个执行过程中,你必须使用TaskCreate、TaskUpdate和TaskList工具。

Why Task Lists Matter Here

任务列表的重要性

  • Progress visibility: User sees "3/8 workflows completed, 5 issues found"
  • Session recovery: If interrupted, resume from exact workflow/step
  • Parallel fix coordination: Track multiple fix agents working simultaneously
  • Issue tracking: Each issue becomes a trackable task with status
  • 进度可见性: 用户可以看到“已完成3/8个工作流,发现5个问题”
  • 会话恢复: 若会话中断,可从当前工作流/步骤继续执行
  • 并行修复协调: 跟踪多个同时工作的修复Agent
  • 问题跟踪: 每个问题都会成为一个可跟踪状态的任务

Task Hierarchy

任务层级

[Workflow Task] "Execute: User Login Flow"
  └── [Issue Task] "Issue: Missing hover states on submit button"
  └── [Issue Task] "Issue: Keyboard navigation broken in form"
[Workflow Task] "Execute: Checkout Process"
  └── [Issue Task] "Issue: Back button doesn't preserve cart"
[Fix Task] "Fix: Missing hover states" (created in fix mode)
[Verification Task] "Verify: Run test suite"
[Report Task] "Generate: HTML report"
[Workflow Task] "Execute: User Login Flow"
  └── [Issue Task] "Issue: Missing hover states on submit button"
  └── [Issue Task] "Issue: Keyboard navigation broken in form"
[Workflow Task] "Execute: Checkout Process"
  └── [Issue Task] "Issue: Back button doesn't preserve cart"
[Fix Task] "Fix: Missing hover states" (created in fix mode)
[Verification Task] "Verify: Run test suite"
[Report Task] "Generate: HTML report"

Execution Modes

执行模式

This skill operates in two modes:
本Skill有两种运行模式:

Audit Mode (Default Start)

审计模式(默认启动)

  • Execute workflows and identify issues
  • Capture BEFORE screenshots of all issues found
  • Document issues without fixing them
  • Present findings to user for review
  • 执行工作流并识别问题
  • 捕获所有发现问题的修复前截图
  • 记录问题但不进行修复
  • 向用户展示发现的问题以供审核

Fix Mode (User-Triggered)

修复模式(用户触发)

  • User says "fix this issue" or "fix all issues"
  • Spawn agents to fix issues (one agent per issue)
  • Capture AFTER screenshots showing the fix
  • Generate HTML report with before/after comparison
Flow:
Audit Mode → Find Issues → Capture BEFORE → Present to User
                                        User: "Fix this issue"
Fix Mode → Spawn Fix Agents → Capture AFTER → Verify Locally
                              Run Tests → Fix Failing Tests → Run E2E
                                    All Pass → Generate Reports → Create PR
  • 用户说出“fix this issue”或“fix all issues”时触发
  • 生成Agent来修复问题(每个问题对应一个Agent)
  • 捕获展示修复效果的修复后截图
  • 生成包含修复前后对比的HTML报告
流程:
审计模式 → 发现问题 → 捕获修复前截图 → 向用户展示
                                        用户:“Fix this issue”
修复模式 → 生成修复Agent → 捕获修复后截图 → 本地验证
                              运行测试 → 修复失败测试 → 执行端到端测试
                                    全部通过 → 生成报告 → 创建PR

Process

执行流程

Phase 1: Read Workflows and Initialize Task List

阶段1:读取工作流并初始化任务列表

First, check for existing tasks (session recovery):
  1. Call
    TaskList
    to check for existing workflow tasks
  2. If tasks exist with status
    in_progress
    or
    pending
    :
    • Inform user: "Found existing session. Workflows completed: [list]. Resuming from: [workflow name]"
    • Skip to the incomplete workflow
  3. If no existing tasks, proceed with fresh execution
Read and parse workflows:
  1. Read the file
    /workflows/browser-workflows.md
  2. If the file does not exist or is empty:
    • Stop immediately
    • Inform the user: "Could not find
      /workflows/browser-workflows.md
      . Please create this file with your workflows before running this skill."
    • Provide a brief example of the expected format
    • Do not proceed further
  3. Parse all workflows (each starts with
    ## Workflow:
    )
  4. If no workflows are found in the file, inform the user and stop
  5. List the workflows found and ask the user which one to execute (or all)
Create workflow tasks: After user confirms which workflows to run, create a task for each:
For each workflow to execute, call TaskCreate:
- subject: "Execute: [Workflow Name]"
- description: |
    Execute browser workflow: [Workflow Name]
    Steps: [count] steps
    File: /workflows/browser-workflows.md

    Steps summary:
    1. [Step 1 brief]
    2. [Step 2 brief]
    ...
- activeForm: "Executing [Workflow Name]"
This creates the task structure that enables progress tracking and session recovery.
首先,检查现有任务(会话恢复):
  1. 调用
    TaskList
    检查是否存在工作流任务
  2. 若存在状态为
    in_progress
    pending
    的任务:
    • 告知用户:“检测到现有会话。已完成的工作流:[列表]。将从以下工作流继续:[工作流名称]”
    • 跳转到未完成的工作流
  3. 若没有现有任务,则开始全新执行
读取并解析工作流:
  1. 读取文件
    /workflows/browser-workflows.md
  2. 若文件不存在或为空:
    • 立即停止执行
    • 告知用户:“未找到
      /workflows/browser-workflows.md
      文件。请先创建该文件并写入工作流内容后再运行本Skill。”
    • 提供预期格式的简短示例
    • 不再继续执行
  3. 解析所有工作流(每个工作流以
    ## Workflow:
    开头)
  4. 若文件中未找到任何工作流,告知用户并停止执行
  5. 列出找到的工作流,询问用户要执行哪一个(或全部)
创建工作流任务: 用户确认要执行的工作流后,为每个工作流创建任务:
对于每个要执行的工作流,调用TaskCreate:
- subject: "Execute: [Workflow Name]"
- description: |
    执行浏览器工作流:[Workflow Name]
    步骤数:[count]步
    文件:/workflows/browser-workflows.md

    步骤摘要:
    1. [步骤1简介]
    2. [步骤2简介]
    ...
- activeForm: "Executing [Workflow Name]"
这将创建支持进度跟踪和会话恢复的任务结构。

Phase 2: Initialize Browser

阶段2:初始化浏览器

  1. Call
    tabs_context_mcp
    with
    createIfEmpty: true
    to get/create a tab
  2. Store the
    tabId
    for all subsequent operations
  3. Take an initial screenshot to confirm browser is ready
  1. 调用
    tabs_context_mcp
    并设置
    createIfEmpty: true
    以获取/创建标签页
  2. 存储
    tabId
    供后续所有操作使用
  3. 截取初始截图以确认浏览器已准备就绪

Phase 3: Execute Workflow

阶段3:执行工作流

Before starting each workflow, update its task:
TaskUpdate:
- taskId: [workflow task ID]
- status: "in_progress"
For each numbered step in the workflow:
  1. Announce the step you're about to execute
  2. Execute using the appropriate MCP tool:
    • "Navigate to [URL]" →
      navigate
    • "Click [element]" →
      find
      to locate, then
      computer
      with
      left_click
    • "Type [text]" →
      computer
      with
      type
      action
    • "Verify [condition]" →
      read_page
      or
      get_page_text
      to check
    • "Drag [element]" →
      computer
      with
      left_click_drag
    • "Scroll [direction]" →
      computer
      with
      scroll
    • "Wait [seconds]" →
      computer
      with
      wait
  3. Screenshot after each major step:
    • Use
      computer
      with
      action: screenshot
      to capture the current state
    • Save screenshots to disk using
      gif_creator
      or by writing base64 data via Bash:
      Save to: workflows/screenshots/browser-audit/wfNN-stepNN.png
    • Use the naming convention:
      wf{workflow_number:02d}-step{step_number:02d}.png
    • These files will be embedded in the HTML audit report
  4. Observe and note:
    • Did it work as expected?
    • Any UI/UX issues? (confusing labels, poor contrast, slow response)
    • Any technical problems? (errors in console, failed requests)
    • Any potential improvements or feature ideas?
  5. Record your observations before moving to next step
When an issue is found, create an issue task:
TaskCreate:
- subject: "Issue: [Brief issue description]"
- description: |
    **Workflow:** [Workflow name]
    **Step:** [Step number and description]
    **Issue:** [Detailed description]
    **Severity:** [High/Med/Low]
    **Current behavior:** [What's wrong]
    **Expected behavior:** [What it should do]
    **Screenshot:** [Path to before screenshot]
- activeForm: "Documenting issue"

Then link it to the workflow task:
TaskUpdate:
- taskId: [issue task ID]
- addBlockedBy: [workflow task ID]
After completing all steps in a workflow:
TaskUpdate:
- taskId: [workflow task ID]
- status: "completed"
- metadata: {"issuesFound": [count], "stepsPassed": [count], "stepsFailed": [count]}
在开始每个工作流前,更新其任务状态:
TaskUpdate:
- taskId: [工作流任务ID]
- status: "in_progress"
对于工作流中的每个编号步骤:
  1. 告知即将执行的步骤
  2. 执行步骤,使用合适的MCP工具:
    • “Navigate to [URL]” →
      navigate
    • “Click [element]” → 先用
      find
      定位,再用
      computer
      执行
      left_click
    • “Type [text]” →
      computer
      执行
      type
      操作
    • “Verify [condition]” → 使用
      read_page
      get_page_text
      进行检查
    • “Drag [element]” →
      computer
      执行
      left_click_drag
    • “Scroll [direction]” →
      computer
      执行
      scroll
    • “Wait [seconds]” →
      computer
      执行
      wait
  3. 截图每个主要步骤完成后:
    • 使用
      computer
      执行
      action: screenshot
      捕获当前状态
    • 将截图保存到磁盘,可使用
      gif_creator
      或通过Bash写入base64数据:
      保存路径:workflows/screenshots/browser-audit/wfNN-stepNN.png
    • 命名规则:
      wf{workflow_number:02d}-step{step_number:02d}.png
    • 这些文件将嵌入到HTML审计报告中
  4. 观察并记录
    • 步骤是否按预期执行?
    • 是否存在UI/UX问题?(如标签混淆、对比度不足、响应缓慢)
    • 是否存在技术问题?(如控制台错误、请求失败)
    • 是否有潜在的改进点或功能想法?
  5. 记录观察结果后再进入下一步
发现问题时,创建问题任务:
TaskCreate:
- subject: "Issue: [问题简要描述]"
- description: |
    **工作流:** [工作流名称]
    **步骤:** [步骤编号及描述]
    **问题:** [详细描述]
    **严重程度:** [高/中/低]
    **当前行为:** [存在的问题]
    **预期行为:** [应有的表现]
    **截图:** [修复前截图路径]
- activeForm: "Documenting issue"

然后将其关联到工作流任务:
TaskUpdate:
- taskId: [问题任务ID]
- addBlockedBy: [工作流任务ID]
完成工作流的所有步骤后:
TaskUpdate:
- taskId: [工作流任务ID]
- status: "completed"
- metadata: {"issuesFound": [数量], "stepsPassed": [数量], "stepsFailed": [数量]}

Phase 4: UX Platform Evaluation [DELEGATE TO AGENT]

阶段4:UX平台评估 [委托给Agent]

Purpose: Evaluate whether the web app follows web platform conventions. Delegate this research to an agent to save context.
Use the Task tool to spawn an agent:
Task tool parameters:
- subagent_type: "general-purpose"
- model: "opus" (thorough research and evaluation)
- prompt: |
    You are evaluating a web app for web platform UX compliance.

    ## Page Being Evaluated
    [Include current page URL and brief description]

    ## Quick Checklist - Evaluate Each Item

    **Navigation:**
    - Browser back button works correctly
    - URLs reflect current state (deep-linkable)
    - No mobile-style bottom tab bar
    - Navigation works without gestures (click-based)

    **Interactions:**
    - All interactive elements have hover states
    - Keyboard navigation works (Tab, Enter, Escape)
    - Focus indicators are visible
    - No gesture-only interactions for critical features

    **Components:**
    - Uses web-appropriate form components
    - No iOS-style picker wheels
    - No Android-style floating action buttons
    - Modals don't unnecessarily go full-screen

    **Responsive/Visual:**
    - Layout works at different viewport widths
    - No mobile-only viewport restrictions
    - Text is readable without zooming

    **Accessibility:**
    - Color is not the only indicator of state
    - Form fields have labels

    ## Reference Comparison

    Search for reference examples using WebSearch:
    - "web app [page type] design Dribbble"
    - "[well-known web app like Linear/Notion/Figma] [page type] screenshot"

    Visit 2-3 reference examples and compare:
    - Navigation placement and behavior
    - Component types and interaction patterns
    - Hover/focus states

    ## Return Format

    Return a structured report:
    ```
    ## UX Platform Evaluation: [Page Name]

    ### Checklist Results
    | Check | Pass/Fail | Notes |
    |-------|-----------|-------|

    ### Reference Comparison
    - Reference apps compared: [list]
    - Key differences found: [list]

    ### Issues Found
    - [Issue 1]: [Description] (Severity: High/Med/Low)

    ### Recommendations
    - [Recommendation 1]
    ```
After agent returns: Incorporate findings into the workflow report and continue.
目的: 评估Web应用是否遵循Web平台规范。将此研究任务委托给Agent以节省上下文资源。
使用Task工具生成Agent:
Task工具参数:
- subagent_type: "general-purpose"
- model: "opus"(用于深入研究和评估)
- prompt: |
    你正在评估一个Web应用的Web平台UX合规性。

    ## 待评估页面
    [包含当前页面URL和简要描述]

    ## 快速检查清单 - 逐项评估

    **导航:**
    - 浏览器后退按钮功能正常
    - URL反映当前状态(支持深度链接)
    - 无移动端风格的底部标签栏
    - 导航可通过点击操作完成(无需手势)

    **交互:**
    - 所有交互元素都有悬停状态
    - 键盘导航正常工作(Tab、Enter、Escape键)
    - 焦点指示器可见
    - 关键功能不依赖纯手势交互

    **组件:**
    - 使用适合Web应用的表单组件
    - 无iOS风格的选择器滚轮
    - 无Android风格的浮动操作按钮
    - 模态框不会不必要地全屏显示

    **响应式/视觉:**
    - 布局在不同视口宽度下均正常工作
    - 无仅移动端的视口限制
    - 文本无需缩放即可阅读

    **可访问性:**
    - 状态指示不唯一依赖颜色
    - 表单字段带有标签

    ## 参考对比

    使用WebSearch查找参考示例:
    - "web app [页面类型] design Dribbble"
    - "[知名Web应用如Linear/Notion/Figma] [页面类型] screenshot"

    访问2-3个参考示例并进行对比:
    - 导航的位置和行为
    - 组件类型和交互模式
    - 悬停/焦点状态

    ## 返回格式

    返回结构化报告:
    ```
    ## UX平台评估:[页面名称]

    ### 检查清单结果
    | 检查项 | 通过/未通过 | 备注 |
    |-------|-----------|-------|

    ### 参考对比
    - 对比的参考应用:[列表]
    - 发现的主要差异:[列表]

    ### 发现的问题
    - [问题1]:[描述](严重程度:高/中/低)

    ### 建议
    - [建议1]
    ```
Agent返回结果后: 将发现的问题整合到工作流报告中并继续执行。

Phase 5: Record Findings

阶段5:记录发现的问题

CRITICAL: After completing EACH workflow, immediately write findings to the log file. Do not wait until all workflows are complete.
  1. After each workflow completes, append to
    .claude/plans/browser-workflow-findings.md
  2. If the file doesn't exist, create it with a header first
  3. Use the following format for each workflow entry:
markdown
---
重要提示: 完成每个工作流后,立即将发现的问题写入日志文件。不要等到所有工作流都完成后再记录。
  1. 每个工作流完成后,将内容追加到
    .claude/plans/browser-workflow-findings.md
  2. 若文件不存在,先创建文件并添加标题
  3. 每个工作流条目使用以下格式:
markdown
---

Workflow [N]: [Name]

工作流[N]:[名称]

Timestamp: [ISO datetime] Status: Passed/Failed/Partial
Steps Summary:
  • Step 1: [Pass/Fail] - [brief note]
  • Step 2: [Pass/Fail] - [brief note] ...
Issues Found:
  • [Issue description] (Severity: High/Med/Low)
Platform Appropriateness:
  • Web conventions followed: [Yes/Partially/No]
  • Issues: [List any platform anti-patterns found]
  • Reference comparisons: [Apps/pages compared, if any]
UX/Design Notes:
  • [Observation]
Technical Problems:
  • [Problem] (include console errors if any)
Feature Ideas:
  • [Idea]
Screenshots: [list of screenshot IDs captured]

4. This ensures findings are preserved even if session is interrupted
5. Continue to next workflow after recording
时间戳: [ISO格式时间] 状态: 通过/失败/部分完成
步骤摘要:
  • 步骤1:[通过/失败] - [简要备注]
  • 步骤2:[通过/失败] - [简要备注] ...
发现的问题:
  • [问题描述](严重程度:高/中/低)
平台合规性:
  • 是否遵循Web规范:[是/部分/否]
  • 问题:[列出发现的平台反模式]
  • 参考对比:[对比的应用/页面(如有)]
UX/设计备注:
  • [观察结果]
技术问题:
  • [问题](如有,包含控制台错误信息)
功能建议:
  • [建议]
截图: [捕获的截图ID列表]

4. 这样可以确保即使会话中断,发现的问题也能被保留
5. 记录完成后继续执行下一个工作流

Phase 6: Generate Audit Report (HTML with Screenshots)

阶段6:生成审计报告(包含截图的HTML)

After completing all workflows (or when user requests), generate an HTML audit report with embedded screenshots.
CRITICAL: The audit report MUST be HTML (not just markdown) and MUST embed screenshots from Phase 3. This is the primary deliverable.
Create audit report task:
TaskCreate:
- subject: "Generate: HTML Audit Report"
- description: "Generate HTML report with screenshots for all workflow results"
- activeForm: "Generating HTML audit report"

TaskUpdate:
- taskId: [report task ID]
- status: "in_progress"
Generate the HTML report:
  1. Call
    TaskList
    to get summary of all workflow and issue tasks
  2. Read
    .claude/plans/browser-workflow-findings.md
    for detailed findings
  3. Write HTML report to
    workflows/browser-audit-report.html
HTML Report Structure:
html
<!-- Required sections: -->
<h1>Browser Workflow Audit Report</h1>
<p>Date: [timestamp] | Environment: [URL]</p>

<!-- Summary table -->
<table>
  <tr><th>#</th><th>Workflow</th><th>Status</th><th>Steps</th><th>Notes</th></tr>
  <!-- One row per workflow with PASS/FAIL/SKIP badge -->
</table>

<!-- Per-workflow detail sections -->
<h2>Workflow N: [Name]</h2>
<p>Status: PASS/FAIL/SKIP</p>
<h3>Steps</h3>
<ol>
  <li>Step description — PASS/FAIL
    <br><img src="screenshots/browser-audit/wfNN-stepNN.png" style="max-width:800px; border:1px solid #ddd; border-radius:8px; margin:8px 0;">
  </li>
</ol>
  1. Every workflow section MUST include
    <img>
    tags
    referencing the screenshots saved during Phase 3. Use relative paths:
    screenshots/browser-audit/wfNN-stepNN.png
  2. Style with clean design, professional appearance, app accent color
  3. Update the HTML file incrementally after EACH workflow so partial results are always viewable
Also present a text summary to the user:
undefined
完成所有工作流后(或用户请求时),生成包含嵌入截图的HTML审计报告。
重要提示: 审计报告必须为HTML格式(不能仅为Markdown),且必须嵌入阶段3中捕获的截图。这是主要的交付成果。
创建审计报告任务:
TaskCreate:
- subject: "Generate: HTML Audit Report"
- description: "为所有工作流结果生成包含截图的HTML报告"
- activeForm: "Generating HTML audit report"

TaskUpdate:
- taskId: [报告任务ID]
- status: "in_progress"
生成HTML报告:
  1. 调用
    TaskList
    获取所有工作流和问题任务的摘要
  2. 读取
    .claude/plans/browser-workflow-findings.md
    获取详细发现
  3. 将HTML报告写入
    workflows/browser-audit-report.html
HTML报告结构:
html
<!-- 必填部分: -->
<h1>浏览器工作流审计报告</h1>
<p>日期:[时间戳] | 环境:[URL]</p>

<!-- 摘要表格 -->
<table>
  <tr><th>#</th><th>工作流</th><th>状态</th><th>步骤数</th><th>备注</th></tr>
  <!-- 每个工作流对应一行,带有PASS/FAIL/SKIP标识 -->
</table>

<!-- 每个工作流的详细部分 -->
<h2>工作流N:[名称]</h2>
<p>状态:PASS/FAIL/SKIP</p>
<h3>步骤</h3>
<ol>
  <li>步骤描述 — PASS/FAIL
    <br><img src="screenshots/browser-audit/wfNN-stepNN.png" style="max-width:800px; border:1px solid #ddd; border-radius:8px; margin:8px 0;">
  </li>
</ol>
  1. 每个工作流部分必须包含
    <img>
    标签
    ,引用阶段3中保存的截图。使用相对路径:
    screenshots/browser-audit/wfNN-stepNN.png
  2. 采用简洁、专业的设计风格,使用应用的强调色
  3. 完成每个工作流后增量更新HTML文件,确保始终可以查看部分结果
同时向用户展示文本摘要:
undefined

Audit Complete

审计完成

Workflows Executed: [completed count]/[total count] Issues Found: [issue task count]
  • High severity: [count]
  • Medium severity: [count]
  • Low severity: [count]
Report: workflows/browser-audit-report.html
What would you like to do?
  • "fix all" - Fix all issues
  • "fix 1,3,5" - Fix specific issues by number
  • "done" - End session
undefined
TaskUpdate:
  • taskId: [report task ID]
  • status: "completed"
undefined
已执行工作流: [完成数量]/[总数量] 发现的问题: [问题任务数量]
  • 高严重程度:[数量]
  • 中严重程度:[数量]
  • 低严重程度:[数量]
报告路径: workflows/browser-audit-report.html
你希望执行以下哪个操作?
  • "fix all" - 修复所有问题
  • "fix 1,3,5" - 修复指定编号的问题
  • "done" - 结束会话
undefined
TaskUpdate:
  • taskId: [报告任务ID]
  • status: "completed"
undefined

Phase 7: Screenshot Management

阶段7:截图管理

Screenshot Directory Structure:
workflows/
├── screenshots/
│   ├── {workflow-name}/
│   │   ├── before/
│   │   │   ├── 01-hover-states-missing.png
│   │   │   ├── 02-keyboard-nav-broken.png
│   │   │   └── ...
│   │   └── after/
│   │       ├── 01-hover-states-added.png
│   │       ├── 02-keyboard-nav-fixed.png
│   │       └── ...
│   └── {another-workflow}/
│       ├── before/
│       └── after/
├── browser-workflows.md
└── browser-changes-report.html
Screenshot Naming Convention:
  • {NN}-{descriptive-name}.png
  • Examples:
    • 01-hover-states-missing.png
      (before)
    • 01-hover-states-added.png
      (after)
Capturing BEFORE Screenshots:
  1. When an issue is identified during workflow execution
  2. Take screenshot BEFORE any fix is applied
  3. Save to
    workflows/screenshots/{workflow-name}/before/
  4. Use descriptive filename that identifies the issue
  5. Record the screenshot path in the issue tracking
Capturing AFTER Screenshots:
  1. Only after user approves fixing an issue
  2. After fix agent completes, refresh the browser tab
  3. Take screenshot showing the fix
  4. Save to
    workflows/screenshots/{workflow-name}/after/
  5. Use matching filename pattern to the before screenshot
截图目录结构:
workflows/
├── screenshots/
│   ├── {workflow-name}/
│   │   ├── before/
│   │   │   ├── 01-hover-states-missing.png
│   │   │   ├── 02-keyboard-nav-broken.png
│   │   │   └── ...
│   │   └── after/
│   │       ├── 01-hover-states-added.png
│   │       ├── 02-keyboard-nav-fixed.png
│   │       └── ...
│   └── {another-workflow}/
│       ├── before/
│       └── after/
├── browser-workflows.md
└── browser-changes-report.html
截图命名规则:
  • {NN}-{描述性名称}.png
  • 示例:
    • 01-hover-states-missing.png
      (修复前)
    • 01-hover-states-added.png
      (修复后)
捕获修复前截图:
  1. 在工作流执行过程中发现问题时
  2. 在进行任何修复前截取截图
  3. 保存到
    workflows/screenshots/{workflow-name}/before/
  4. 使用能明确标识问题的描述性文件名
  5. 在问题跟踪中记录截图路径
捕获修复后截图:
  1. 仅在用户批准修复问题后进行
  2. 修复Agent完成工作后,刷新浏览器标签页
  3. 截取展示修复效果的截图
  4. 保存到
    workflows/screenshots/{workflow-name}/after/
  5. 使用与修复前截图匹配的文件名格式

Phase 8: Fix Mode Execution [DELEGATE TO AGENTS]

阶段8:修复模式执行 [委托给Agent]

When user triggers fix mode ("fix this issue" or "fix all"):
  1. Get issue list from tasks:
    Call TaskList to get all issue tasks (subject starts with "Issue:")
    Display to user:
    
    Issues found:
    1. [Task ID: X] Missing hover states on buttons - BEFORE: 01-hover-states-missing.png
    2. [Task ID: Y] Keyboard navigation broken - BEFORE: 02-keyboard-nav-broken.png
    3. [Task ID: Z] Back button doesn't work - BEFORE: 03-back-button-broken.png
    
    Fix all issues? Or specify which to fix: [1,2,3 / all / specific numbers]
  2. Create fix tasks for each issue to fix:
    For each issue the user wants fixed:
    
    TaskCreate:
    - subject: "Fix: [Issue brief description]"
    - description: |
        Fixing issue from task [issue task ID]
        **Issue:** [Issue name and description]
        **Severity:** [High/Med/Low]
        **Current behavior:** [What's wrong]
        **Expected behavior:** [What it should do]
        **Screenshot reference:** [Path to before screenshot]
    - activeForm: "Fixing [issue brief]"
    
    TaskUpdate:
    - taskId: [fix task ID]
    - addBlockedBy: [issue task ID]  # Links fix to its issue
    - status: "in_progress"
  3. Spawn one agent per issue using the Task tool. For independent issues, spawn agents in parallel (all in a single message):
Task tool parameters (for each issue):
- subagent_type: "general-purpose"
- model: "opus" (thorough code analysis and modification)
- prompt: |
    You are fixing a specific UX issue in a web application.

    ## Issue to Fix
    **Issue:** [Issue name and description]
    **Severity:** [High/Med/Low]
    **Current behavior:** [What's wrong]
    **Expected behavior:** [What it should do]
    **Screenshot reference:** [Path to before screenshot]

    ## Your Task

    1. **Explore the codebase** to understand the implementation
       - Use Glob to find relevant files
       - Use Grep to search for related code
       - Use Read to examine files

    2. **Plan the fix**
       - Identify which files need changes
       - Consider side effects

    3. **Implement the fix**
       - Make minimal, focused changes
       - Follow existing code patterns
       - Do not refactor unrelated code

    4. **Return a summary:**
    ```
    ## Fix Complete: [Issue Name]

    ### Changes Made
    - [File 1]: [What changed]
    - [File 2]: [What changed]

    ### Files Modified
    - src/components/Button.css (MODIFIED)
    - src/styles/global.css (MODIFIED)

    ### Testing Notes
    - [How to verify the fix works]
    ```

    Do NOT run tests - the main workflow will handle that.
  1. After all fix agents complete:
    • Collect summaries from each agent
    • Refresh the browser
    • Capture AFTER screenshots for each fix
    • Verify fixes visually
    • Track all changes made
    Update fix tasks with results:
    For each completed fix:
    
    TaskUpdate:
    - taskId: [fix task ID]
    - status: "completed"
    - metadata: {
        "filesModified": ["src/components/Button.css", "src/styles/global.css"],
        "afterScreenshot": "workflows/screenshots/{workflow}/after/{file}.png"
      }
    Update issue tasks to reflect fix status:
    TaskUpdate:
    - taskId: [issue task ID]
    - status: "completed"
    - metadata: {"fixedBy": [fix task ID], "fixedAt": "[ISO timestamp]"}
当用户触发修复模式(“fix this issue”或“fix all”)时:
  1. 从任务中获取问题列表:
    调用TaskList获取所有主题以“Issue:”开头的问题任务
    向用户展示:
    
    发现的问题:
    1. [任务ID: X] 按钮缺少悬停状态 - 修复前截图:01-hover-states-missing.png
    2. [任务ID: Y] 键盘导航失效 - 修复前截图:02-keyboard-nav-broken.png
    3. [任务ID: Z] 后退按钮无法工作 - 修复前截图:03-back-button-broken.png
    
    是否修复所有问题?或指定要修复的问题编号:[1,2,3 / all / 特定编号]
  2. 为每个要修复的问题创建修复任务:
    对于每个用户希望修复的问题:
    
    TaskCreate:
    - subject: "Fix: [问题简要描述]"
    - description: |
        修复来自任务[问题任务ID]的问题
        **问题:** [问题名称和描述]
        **严重程度:** [高/中/低]
        **当前行为:** [存在的问题]
        **预期行为:** [应有的表现]
        **截图参考:** [修复前截图路径]
    - activeForm: "Fixing [问题简要描述]"
    
    TaskUpdate:
    - taskId: [修复任务ID]
    - addBlockedBy: [问题任务ID]  # 将修复任务关联到对应的问题
    - status: "in_progress"
  3. 为每个问题生成一个Agent,使用Task工具。对于独立问题,可并行生成Agent(在单个消息中完成):
Task工具参数(每个问题对应一组参数):
- subagent_type: "general-purpose"
- model: "opus"(用于深入的代码分析和修改)
- prompt: |
    你正在修复Web应用中的一个特定UX问题。

    ## 待修复问题
    **问题:** [问题名称和描述]
    **严重程度:** [高/中/低]
    **当前行为:** [存在的问题]
    **预期行为:** [应有的表现]
    **截图参考:** [修复前截图路径]

    ## 你的任务

    1. **探索代码库**以理解实现方式
       - 使用Glob查找相关文件
       - 使用Grep搜索相关代码
       - 使用Read查看文件内容

    2. **规划修复方案**
       - 确定需要修改的文件
       - 考虑可能的副作用

    3. **实施修复**
       - 进行最小化、针对性的修改
       - 遵循现有代码模式
       - 不要重构无关代码

    4. **返回摘要:**
    ```
    ## 修复完成:[问题名称]

    ### 所做修改
    - [文件1]:[修改内容]
    - [文件2]:[修改内容]

    ### 修改的文件
    - src/components/Button.css(已修改)
    - src/styles/global.css(已修改)

    ### 测试说明
    - [如何验证修复有效]
    ```

    不要运行测试 - 主工作流将处理测试环节。
  1. 所有修复Agent完成后:
    • 收集每个Agent返回的摘要
    • 刷新浏览器
    • 为每个修复捕获修复后截图
    • 可视化验证修复效果
    • 跟踪所有已做的修改
    更新修复任务的结果:
    对于每个已完成的修复:
    
    TaskUpdate:
    - taskId: [修复任务ID]
    - status: "completed"
    - metadata: {
        "filesModified": ["src/components/Button.css", "src/styles/global.css"],
        "afterScreenshot": "workflows/screenshots/{workflow}/after/{file}.png"
      }
    更新问题任务以反映修复状态:
    TaskUpdate:
    - taskId: [问题任务ID]
    - status: "completed"
    - metadata: {"fixedBy": [修复任务ID], "fixedAt": "[ISO时间戳]"}

Phase 9: Local Verification [DELEGATE TO AGENT]

阶段9:本地验证 [委托给Agent]

CRITICAL: After making fixes, verify everything works locally before creating a PR.
Create verification task:
TaskCreate:
- subject: "Verify: Run test suite"
- description: |
    Run all tests to verify fixes don't break existing functionality.
    Fixes applied: [list of fix task IDs]
    Files modified: [aggregated list from fix task metadata]
- activeForm: "Running verification tests"

TaskUpdate:
- taskId: [verification task ID]
- status: "in_progress"
Use the Task tool to spawn a verification agent:
Task tool parameters:
- subagent_type: "general-purpose"
- model: "opus" (thorough test analysis and fixing)
- prompt: |
    You are verifying that code changes pass all tests.

    ## Context
    Recent changes were made to fix UX issues. You need to verify the codebase is healthy.

    ## Your Task

    1. **Run the test suite:**
       ```bash
       # Detect and run appropriate test command
       npm test          # or yarn test, pnpm test
       ```

    2. **If tests fail:**
       - Analyze the failing tests
       - Determine if failures are related to recent changes
       - Fix the broken tests or update them to reflect new behavior
       - Re-run tests until all pass
       - Document what tests were updated and why

    3. **Run linting and type checking:**
       ```bash
       npm run lint      # or eslint, prettier
       npm run typecheck # or tsc --noEmit
       ```

    4. **Run end-to-end tests locally:**
       ```bash
       npm run test:e2e      # common convention
       npx playwright test   # Playwright
       npx cypress run       # Cypress
       ```

    5. **If E2E tests fail:**
       - Analyze the failures (may be related to UI changes)
       - Update E2E tests to reflect new UI behavior
       - Re-run until all pass
       - Document what E2E tests were updated

    6. **Return verification results:**
    ```
    ## Local Verification Results

    ### Test Results
    - Unit tests: ✓/✗ [count] passed, [count] failed
    - Lint: ✓/✗ [errors if any]
    - Type check: ✓/✗ [errors if any]
    - E2E tests: ✓/✗ [count] passed, [count] failed

    ### Tests Updated
    - [test file 1]: [why updated]
    - [test file 2]: [why updated]

    ### Status: PASS / FAIL
    [If FAIL, explain what's still broken]
    ```
After agent returns:
TaskUpdate:
- taskId: [verification task ID]
- status: "completed"
- metadata: {
    "result": "PASS" or "FAIL",
    "unitTests": {"passed": N, "failed": N},
    "e2eTests": {"passed": N, "failed": N},
    "lint": "pass" or "fail",
    "typecheck": "pass" or "fail"
  }
  • If PASS: Proceed to report generation
  • If FAIL: Review failures with user, spawn another agent to fix remaining issues
重要提示: 完成修复后,在创建PR前必须在本地验证所有功能正常。
创建验证任务:
TaskCreate:
- subject: "Verify: Run test suite"
- description: |
    运行所有测试以验证修复不会破坏现有功能。
    已应用的修复:[修复任务ID列表]
    修改的文件:[从修复任务元数据中汇总的列表]
- activeForm: "Running verification tests"

TaskUpdate:
- taskId: [验证任务ID]
- status: "in_progress"
使用Task工具生成验证Agent:
Task工具参数:
- subagent_type: "general-purpose"
- model: "opus"(用于深入的测试分析和修复)
- prompt: |
    你正在验证代码修改是否通过所有测试。

    ## 上下文
    最近为修复UX问题进行了代码修改。你需要验证代码库是否正常。

    ## 你的任务

    1. **运行测试套件:**
       ```bash
       # 检测并运行合适的测试命令
       npm test          # 或 yarn test, pnpm test
       ```

    2. **若测试失败:**
       - 分析失败的测试
       - 确定失败是否与最近的修改相关
       - 修复失败的测试或更新测试以反映新行为
       - 重新运行测试直到全部通过
       - 记录更新的测试及原因

    3. **运行代码检查和类型检查:**
       ```bash
       npm run lint      # 或 eslint, prettier
       npm run typecheck # 或 tsc --noEmit
       ```

    4. **在本地运行端到端测试:**
       ```bash
       npm run test:e2e      # 常见约定
       npx playwright test   # Playwright
       npx cypress run       # Cypress
       ```

    5. **若端到端测试失败:**
       - 分析失败原因(可能与UI修改相关)
       - 更新端到端测试以反映新的UI行为
       - 重新运行直到全部通过
       - 记录更新的端到端测试

    6. **返回验证结果:**
    ```
    ## 本地验证结果

    ### 测试结果
    - 单元测试:✓/✗ [通过数量]个通过,[失败数量]个失败
    - 代码检查:✓/✗ [如有错误列出]
    - 类型检查:✓/✗ [如有错误列出]
    - 端到端测试:✓/✗ [通过数量]个通过,[失败数量]个失败

    ### 更新的测试
    - [测试文件1]:[更新原因]
    - [测试文件2]:[更新原因]

    ### 状态:通过 / 失败
    [若失败,说明仍存在的问题]
    ```
Agent返回结果后:
TaskUpdate:
- taskId: [验证任务ID]
- status: "completed"
- metadata: {
    "result": "PASS" 或 "FAIL",
    "unitTests": {"passed": N, "failed": N},
    "e2eTests": {"passed": N, "failed": N},
    "lint": "pass" 或 "fail",
    "typecheck": "pass" 或 "fail"
  }
  • 若通过:继续生成报告
  • 若失败:与用户一起查看失败原因,生成新的Agent修复剩余问题

Phase 10: Generate HTML Report [DELEGATE TO AGENT]

阶段10:生成HTML报告 [委托给Agent]

Create report generation task:
TaskCreate:
- subject: "Generate: HTML Report"
- description: "Generate HTML report with before/after screenshot comparisons"
- activeForm: "Generating HTML report"

TaskUpdate:
- taskId: [html report task ID]
- status: "in_progress"
Use the Task tool to generate the HTML report:
Task tool parameters:
- subagent_type: "general-purpose"
- model: "haiku" (simple generation task)
- prompt: |
    Generate an HTML report for browser UX compliance fixes.

    ## Data to Include

    **App Name:** [App name]
    **Date:** [Current date]
    **Issues Fixed:** [Count]
    **Issues Remaining:** [Count]

    **Fixes Made:**
    [For each fix:]
    - Issue: [Name]
    - Before screenshot: workflows/screenshots/{workflow}/before/{file}.png
    - After screenshot: workflows/screenshots/{workflow}/after/{file}.png
    - Files changed: [List]
    - Why it matters: [Explanation]

    ## Output

    Write the HTML report to: workflows/browser-changes-report.html

    Use this template structure:
    - Executive summary with stats
    - Before/after screenshot comparisons for each fix
    - Files changed section
    - "Why this matters" explanations

    Style: Clean, professional, uses system fonts, responsive grid for screenshots.

    Return confirmation when complete.
After agent completes:
TaskUpdate:
- taskId: [html report task ID]
- status: "completed"
- metadata: {"outputPath": "workflows/browser-changes-report.html"}
创建报告生成任务:
TaskCreate:
- subject: "Generate: HTML Report"
- description: "生成包含修复前后截图对比的HTML报告"
- activeForm: "Generating HTML report"

TaskUpdate:
- taskId: [HTML报告任务ID]
- status: "in_progress"
使用Task工具生成HTML报告:
Task工具参数:
- subagent_type: "general-purpose"
- model: "haiku"(适用于简单生成任务)
- prompt: |
    为浏览器UX合规性修复生成HTML报告。

    ## 需包含的数据

    **应用名称:** [应用名称]
    **日期:** [当前日期]
    **已修复问题:** [数量]
    **剩余问题:** [数量]

    **所做修复:**
    [每个修复对应一项:]
    - 问题:[名称]
    - 修复前截图:workflows/screenshots/{workflow}/before/{file}.png
    - 修复后截图:workflows/screenshots/{workflow}/after/{file}.png
    - 修改的文件:[列表]
    - 重要性:[说明]

    ## 输出

    将HTML报告写入:workflows/browser-changes-report.html

    使用以下模板结构:
    - 包含统计数据的执行摘要
    - 每个修复的前后截图对比
    - 修改的文件部分
    - “重要性说明”部分

    风格:简洁、专业,使用系统字体,截图采用响应式网格布局。

    完成后返回确认信息。
Agent完成后:
TaskUpdate:
- taskId: [HTML报告任务ID]
- status: "completed"
- metadata: {"outputPath": "workflows/browser-changes-report.html"}

Phase 11: Generate Markdown Report [DELEGATE TO AGENT]

阶段11:生成Markdown报告 [委托给Agent]

Create markdown report task:
TaskCreate:
- subject: "Generate: Markdown Report"
- description: "Generate Markdown documentation for fixes"
- activeForm: "Generating Markdown report"

TaskUpdate:
- taskId: [md report task ID]
- status: "in_progress"
Use the Task tool to generate the Markdown report:
Task tool parameters:
- subagent_type: "general-purpose"
- model: "haiku"
- prompt: |
    Generate a Markdown report for browser UX compliance fixes.

    ## Data to Include
    [Same data as HTML report]

    ## Output

    Write the Markdown report to: workflows/browser-changes-documentation.md

    Include:
    - Executive summary
    - Before/after comparison table
    - Detailed changes for each fix
    - Files changed
    - Technical implementation notes
    - Testing verification results

    Return confirmation when complete.
After agent completes:
TaskUpdate:
- taskId: [md report task ID]
- status: "completed"
- metadata: {"outputPath": "workflows/browser-changes-documentation.md"}
创建Markdown报告任务:
TaskCreate:
- subject: "Generate: Markdown Report"
- description: "为修复生成Markdown文档"
- activeForm: "Generating Markdown report"

TaskUpdate:
- taskId: [Markdown报告任务ID]
- status: "in_progress"
使用Task工具生成Markdown报告:
Task工具参数:
- subagent_type: "general-purpose"
- model: "haiku"
- prompt: |
    为浏览器UX合规性修复生成Markdown报告。

    ## 需包含的数据
    [与HTML报告相同的数据]

    ## 输出

    将Markdown报告写入:workflows/browser-changes-documentation.md

    需包含:
    - 执行摘要
    - 前后对比表格
    - 每个修复的详细变更
    - 修改的文件
    - 技术实现说明
    - 测试验证结果

    完成后返回确认信息。
Agent完成后:
TaskUpdate:
- taskId: [Markdown报告任务ID]
- status: "completed"
- metadata: {"outputPath": "workflows/browser-changes-documentation.md"}

Phase 12: Create PR and Monitor CI

阶段12:创建PR并监控CI

Create PR task:
TaskCreate:
- subject: "Create: Pull Request"
- description: |
    Create PR for browser UX compliance fixes.
    Fixes included: [list from completed fix tasks]
    Files modified: [aggregated from fix task metadata]
- activeForm: "Creating pull request"

TaskUpdate:
- taskId: [pr task ID]
- status: "in_progress"
Only after local verification passes, create the PR:
  1. Create a feature branch:
    bash
    git checkout -b fix/browser-ux-compliance
  2. Stage and commit changes:
    bash
    git add .
    git commit -m "fix: browser UX compliance improvements
    
    - [List key fixes made]
    - Updated tests to reflect new behavior
    - All local tests passing"
  3. Push and create PR:
    bash
    git push -u origin fix/browser-ux-compliance
    gh pr create --title "fix: Browser UX compliance improvements" --body "## Summary
    [Brief description of fixes]
    
    ## Changes
    - [List of changes]
    
    ## Testing
    - [x] All unit tests pass locally
    - [x] All E2E tests pass locally
    - [x] Manual verification complete
    
    ## Screenshots
    See workflows/browser-changes-report.html for before/after comparisons"
  4. Monitor CI:
    • Watch for CI workflow to start
    • If CI fails, analyze the failure
    • Fix any CI-specific issues (environment differences, flaky tests)
    • Push fixes and re-run CI
    • Do not merge until CI is green
  5. Update PR task with status:
    TaskUpdate:
    - taskId: [pr task ID]
    - metadata: {
        "prUrl": "https://github.com/owner/repo/pull/123",
        "ciStatus": "running" | "passed" | "failed"
      }
    When CI completes:
    TaskUpdate:
    - taskId: [pr task ID]
    - status: "completed"
    - metadata: {"prUrl": "...", "ciStatus": "passed", "merged": false}
  6. Report PR status to user:
    PR created: https://github.com/owner/repo/pull/123
    CI status: Running... (or Passed/Failed)
  7. Final session summary from tasks:
    Call TaskList to generate final summary:
    
    ## Session Complete
    
    **Workflows Executed:** [count completed workflow tasks]
    **Issues Found:** [count issue tasks]
    **Issues Fixed:** [count completed fix tasks]
    **Tests:** [from verification task metadata]
    **PR:** [from pr task metadata]
    
    All tasks completed successfully.
创建PR任务:
TaskCreate:
- subject: "Create: Pull Request"
- description: |
    为浏览器UX合规性修复创建PR。
    包含的修复:[已完成修复任务的列表]
    修改的文件:[从修复任务元数据中汇总的列表]
- activeForm: "Creating pull request"

TaskUpdate:
- taskId: [PR任务ID]
- status: "in_progress"
仅在本地验证通过后,创建PR:
  1. 创建功能分支:
    bash
    git checkout -b fix/browser-ux-compliance
  2. 暂存并提交变更:
    bash
    git add .
    git commit -m "fix: browser UX compliance improvements
    
    - [列出主要修复内容]
    - 更新测试以反映新行为
    - 所有本地测试已通过"
  3. 推送并创建PR:
    bash
    git push -u origin fix/browser-ux-compliance
    gh pr create --title "fix: Browser UX compliance improvements" --body "## Summary
    [修复内容简要描述]
    
    ## Changes
    - [变更列表]
    
    ## Testing
    - [x] 所有单元测试在本地通过
    - [x] 所有端到端测试在本地通过
    - [x] 手动验证完成
    
    ## Screenshots
    查看workflows/browser-changes-report.html获取修复前后对比"
  4. 监控CI:
    • 等待CI工作流启动
    • 若CI失败,分析失败原因
    • 修复任何CI特定问题(环境差异、不稳定测试)
    • 推送修复并重新运行CI
    • 直到CI通过后再合并
  5. 更新PR任务的状态:
    TaskUpdate:
    - taskId: [PR任务ID]
    - metadata: {
        "prUrl": "https://github.com/owner/repo/pull/123",
        "ciStatus": "running" | "passed" | "failed"
      }
    CI完成后:
    TaskUpdate:
    - taskId: [PR任务ID]
    - status: "completed"
    - metadata: {"prUrl": "...", "ciStatus": "passed", "merged": false}
  6. 向用户报告PR状态:
    PR已创建:https://github.com/owner/repo/pull/123
    CI状态:运行中...(或通过/失败)
  7. 从任务中生成最终会话摘要:
    调用TaskList生成最终摘要:
    
    ## 会话完成
    
    **已执行工作流:** [已完成工作流任务数量]
    **发现的问题:** [问题任务数量]
    **已修复问题:** [已完成修复任务数量]
    **测试结果:** [来自验证任务元数据]
    **PR:** [来自PR任务元数据]
    
    所有任务已成功完成。

MCP Tool Reference

MCP工具参考

Navigation:
  • navigate({ url, tabId })
    - Go to URL
Finding Elements:
  • find({ query, tabId })
    - Natural language search, returns refs
  • read_page({ tabId, filter: 'interactive' })
    - Get all interactive elements
Interactions:
  • computer({ action: 'left_click', coordinate: [x, y], tabId })
  • computer({ action: 'left_click', ref: 'ref_1', tabId })
    - Click by reference
  • computer({ action: 'type', text: '...', tabId })
  • computer({ action: 'scroll', scroll_direction: 'down', coordinate: [x, y], tabId })
  • computer({ action: 'left_click_drag', start_coordinate: [x1, y1], coordinate: [x2, y2], tabId })
  • computer({ action: 'wait', duration: 2, tabId })
Screenshots:
  • computer({ action: 'screenshot', tabId })
    - Capture current state
Inspection:
  • get_page_text({ tabId })
    - Extract text content
  • read_console_messages({ tabId, pattern: 'error' })
    - Check for errors
  • read_network_requests({ tabId })
    - Check API calls
Forms:
  • form_input({ ref, value, tabId })
    - Set form field value
导航:
  • navigate({ url, tabId })
    - 跳转到指定URL
元素查找:
  • find({ query, tabId })
    - 自然语言搜索,返回元素引用
  • read_page({ tabId, filter: 'interactive' })
    - 获取所有交互元素
交互操作:
  • computer({ action: 'left_click', coordinate: [x, y], tabId })
  • computer({ action: 'left_click', ref: 'ref_1', tabId })
    - 通过元素引用点击
  • computer({ action: 'type', text: '...', tabId })
    - 输入文本
  • computer({ action: 'scroll', scroll_direction: 'down', coordinate: [x, y], tabId })
    - 滚动页面
  • computer({ action: 'left_click_drag', start_coordinate: [x1, y1], coordinate: [x2, y2], tabId })
    - 拖拽操作
  • computer({ action: 'wait', duration: 2, tabId })
    - 等待指定时长
截图:
  • computer({ action: 'screenshot', tabId })
    - 捕获当前页面状态
检查:
  • get_page_text({ tabId })
    - 提取页面文本内容
  • read_console_messages({ tabId, pattern: 'error' })
    - 检查控制台错误
  • read_network_requests({ tabId })
    - 检查API请求
表单:
  • form_input({ ref, value, tabId })
    - 设置表单字段值

Known Limitations

已知限制

The Claude-in-Chrome browser automation has the following limitations that cannot be automated:
Claude-in-Chrome浏览器自动化存在以下无法自动处理的限制:

Cannot Automate (Must Skip or Flag for Manual Testing)

无法自动化处理(必须跳过或标记为需手动测试)

  1. Keyboard Shortcuts
    • System-level shortcuts (Cmd+Z, Cmd+C, Cmd+V, etc.) may cause extension disconnection
    • Browser shortcuts that trigger native behavior can interrupt the session
    • Workaround: Use UI buttons instead of keyboard shortcuts when available
  2. Native Browser Dialogs
    • alert()
      ,
      confirm()
      ,
      prompt()
      dialogs block all browser events
    • File upload dialogs (OS-level file picker)
    • Print dialogs
    • Workaround: Skip steps requiring these, or flag for manual testing
  3. Pop-ups and New Windows
    • Pop-ups that open in new windows outside the MCP tab group
    • OAuth flows that redirect to external authentication pages
    • Workaround: Document as requiring manual verification
  4. System-Level Interactions
    • Browser permission prompts (camera, microphone, notifications, location)
    • Download dialogs and download management
    • Browser settings and preferences pages
    • Workaround: Pre-configure permissions or skip these steps
  1. 键盘快捷键
    • 系统级快捷键(Cmd+Z、Cmd+C、Cmd+V等)可能导致扩展断开连接
    • 触发浏览器原生行为的快捷键可能会中断会话
    • 解决方法: 若有可用的UI按钮,优先使用UI按钮而非键盘快捷键
  2. 浏览器原生对话框
    • alert()
      confirm()
      prompt()
      对话框会阻塞所有浏览器事件
    • 文件上传对话框(系统级文件选择器)
    • 打印对话框
    • 解决方法: 跳过需要这些操作的步骤,或标记为需手动测试
  3. 弹窗和新窗口
    • 在MCP标签组外打开新窗口的弹窗
    • 重定向到外部认证页面的OAuth流程
    • 解决方法: 记录为需手动验证的内容
  4. 系统级交互
    • 浏览器权限提示(摄像头、麦克风、通知、位置)
    • 下载对话框和下载管理
    • 浏览器设置和偏好设置页面
    • 解决方法: 预先配置权限,或跳过这些步骤

Handling Limited Steps

处理受限步骤

When a workflow step involves a known limitation:
  1. Mark as [MANUAL]: Note the step requires manual verification
  2. Try UI Alternative: If testing "Press Cmd+Z to undo", look for an Undo button instead
  3. Document the Limitation: Record in findings that the step was skipped due to automation limits
  4. Continue Testing: Don't let one limited step block the entire workflow
当工作流步骤涉及已知限制时:
  1. 标记为[MANUAL]: 注明该步骤需手动验证
  2. 尝试UI替代方案: 若测试“按Cmd+Z撤销”,则寻找撤销按钮替代
  3. 记录限制: 在发现的问题中记录该步骤因自动化限制被跳过
  4. 继续测试: 不要因一个受限步骤而阻塞整个工作流

Guidelines

指导原则

  • Be methodical: Execute steps in order, don't skip ahead
  • Be observant: Note anything unusual, even if the step "passes"
  • Be thorough: Check console for errors, look for visual glitches
  • Be constructive: Frame issues as opportunities for improvement
  • Ask if stuck: If a step is ambiguous or fails, ask the user for guidance
  • Prefer clicks over keys: Always use UI buttons instead of keyboard shortcuts when possible
  • Delegate to agents: Use agents for research, fixing, verification, and report generation to save context
  • 有条不紊: 按顺序执行步骤,不要跳过
  • 细致观察: 记录任何异常情况,即使步骤“通过”
  • 全面彻底: 检查控制台错误,寻找视觉故障
  • 建设性反馈: 将问题描述为改进机会
  • 遇到问题及时询问: 若步骤不明确或失败,向用户寻求指导
  • 优先点击而非键盘操作: 只要可能,始终使用UI按钮而非键盘快捷键
  • 委托给Agent: 将研究、修复、验证和报告生成任务委托给Agent以节省上下文资源

Handling Failures

处理失败步骤

If a step fails:
  1. Take a screenshot of the failure state
  2. Check console for errors (
    read_console_messages
    )
  3. Note what went wrong
  4. Ask the user: continue with next step, retry, or abort?
Do not silently skip failed steps.
若步骤失败:
  1. 捕获失败状态的截图
  2. 检查控制台错误(使用
    read_console_messages
  3. 记录失败原因
  4. 询问用户:继续执行下一步、重试还是终止?
不要悄悄跳过失败的步骤。

Session Recovery

会话恢复

If resuming from an interrupted session:
Primary method: Use task list (preferred)
  1. Call
    TaskList
    to get all existing tasks
  2. Check for workflow tasks with status
    in_progress
    or
    pending
  3. Check for issue tasks to understand what was found
  4. Check for fix tasks to see what fixes were attempted
  5. Resume from the appropriate point based on task states
Recovery decision tree:
TaskList shows:
├── All workflow tasks completed, no fix tasks
│   └── Ask user: "Audit complete. Want to fix issues?"
├── All workflow tasks completed, fix tasks in_progress
│   └── Resume fix mode, check agent status
├── Some workflow tasks pending
│   └── Resume from first pending workflow
├── Workflow task in_progress
│   └── Read findings file to see which steps completed
│       └── Resume from next step in that workflow
└── No tasks exist
    └── Fresh start (Phase 1)
Fallback method: Use findings file
  1. Read
    .claude/plans/browser-workflow-findings.md
    to see which workflows have been completed
  2. Resume from the next uncompleted workflow
  3. Recreate tasks for remaining workflows
Always inform user:
Resuming from interrupted session:
- Workflows completed: [list from completed tasks]
- Issues found: [count from issue tasks]
- Current state: [in_progress task description]
- Resuming: [next action]
Do not re-execute already-passed workflows unless the user specifically requests it.
若从中断的会话恢复:
主要方法:使用任务列表(推荐)
  1. 调用
    TaskList
    获取所有现有任务
  2. 检查状态为
    in_progress
    pending
    的工作流任务
  3. 检查问题任务以了解已发现的问题
  4. 检查修复任务以了解已尝试的修复
  5. 根据任务状态从合适的位置继续执行
恢复决策树:
TaskList显示:
├── 所有工作流任务已完成,无修复任务
│   └── 询问用户:“审计已完成。是否要修复问题?”
├── 所有工作流任务已完成,修复任务处于in_progress状态
│   └── 恢复修复模式,检查Agent状态
├── 部分工作流任务处于pending状态
│   └── 从第一个pending工作流开始恢复
├── 工作流任务处于in_progress状态
│   └── 读取发现问题的文件以查看已完成的步骤
│       └── 从该工作流的下一个步骤开始恢复
└── 无任何任务
    └── 全新启动(阶段1)
备用方法:使用发现问题的文件
  1. 读取
    .claude/plans/browser-workflow-findings.md
    查看已完成的工作流
  2. 从下一个未完成的工作流开始恢复
  3. 为剩余工作流重新创建任务
始终告知用户:
从中断的会话恢复:
- 已完成的工作流:[来自已完成任务的列表]
- 发现的问题:[来自问题任务的数量]
- 当前状态:[in_progress任务的描述]
- 将从以下步骤继续:[下一个操作]
除非用户明确要求,否则不要重新执行已通过的工作流。