browser-workflow-executor
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBrowser 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 → 捕获修复后截图 → 本地验证
↓
运行测试 → 修复失败测试 → 执行端到端测试
↓
全部通过 → 生成报告 → 创建PRProcess
执行流程
Phase 1: Read Workflows and Initialize Task List
阶段1:读取工作流并初始化任务列表
First, check for existing tasks (session recovery):
- Call to check for existing workflow tasks
TaskList - If tasks exist with status or
in_progress:pending- Inform user: "Found existing session. Workflows completed: [list]. Resuming from: [workflow name]"
- Skip to the incomplete workflow
- If no existing tasks, proceed with fresh execution
Read and parse workflows:
- Read the file
/workflows/browser-workflows.md - If the file does not exist or is empty:
- Stop immediately
- Inform the user: "Could not find . Please create this file with your workflows before running this skill."
/workflows/browser-workflows.md - Provide a brief example of the expected format
- Do not proceed further
- Parse all workflows (each starts with )
## Workflow: - If no workflows are found in the file, inform the user and stop
- 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.
首先,检查现有任务(会话恢复):
- 调用检查是否存在工作流任务
TaskList - 若存在状态为或
in_progress的任务:pending- 告知用户:“检测到现有会话。已完成的工作流:[列表]。将从以下工作流继续:[工作流名称]”
- 跳转到未完成的工作流
- 若没有现有任务,则开始全新执行
读取并解析工作流:
- 读取文件
/workflows/browser-workflows.md - 若文件不存在或为空:
- 立即停止执行
- 告知用户:“未找到文件。请先创建该文件并写入工作流内容后再运行本Skill。”
/workflows/browser-workflows.md - 提供预期格式的简短示例
- 不再继续执行
- 解析所有工作流(每个工作流以开头)
## Workflow: - 若文件中未找到任何工作流,告知用户并停止执行
- 列出找到的工作流,询问用户要执行哪一个(或全部)
创建工作流任务:
用户确认要执行的工作流后,为每个工作流创建任务:
对于每个要执行的工作流,调用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:初始化浏览器
- Call with
tabs_context_mcpto get/create a tabcreateIfEmpty: true - Store the for all subsequent operations
tabId - Take an initial screenshot to confirm browser is ready
- 调用并设置
tabs_context_mcp以获取/创建标签页createIfEmpty: true - 存储供后续所有操作使用
tabId - 截取初始截图以确认浏览器已准备就绪
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:
- Announce the step you're about to execute
- Execute using the appropriate MCP tool:
- "Navigate to [URL]" →
navigate - "Click [element]" → to locate, then
findwithcomputerleft_click - "Type [text]" → with
computeractiontype - "Verify [condition]" → or
read_pageto checkget_page_text - "Drag [element]" → with
computerleft_click_drag - "Scroll [direction]" → with
computerscroll - "Wait [seconds]" → with
computerwait
- "Navigate to [URL]" →
- Screenshot after each major step:
- Use with
computerto capture the current stateaction: screenshot - Save screenshots to disk using or by writing base64 data via Bash:
gif_creatorSave 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
- Use
- 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?
- 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"对于工作流中的每个编号步骤:
- 告知即将执行的步骤
- 执行步骤,使用合适的MCP工具:
- “Navigate to [URL]” →
navigate - “Click [element]” → 先用定位,再用
find执行computerleft_click - “Type [text]” → 执行
computer操作type - “Verify [condition]” → 使用或
read_page进行检查get_page_text - “Drag [element]” → 执行
computerleft_click_drag - “Scroll [direction]” → 执行
computerscroll - “Wait [seconds]” → 执行
computerwait
- “Navigate to [URL]” →
- 截图每个主要步骤完成后:
- 使用执行
computer捕获当前状态action: screenshot - 将截图保存到磁盘,可使用或通过Bash写入base64数据:
gif_creator保存路径:workflows/screenshots/browser-audit/wfNN-stepNN.png - 命名规则:
wf{workflow_number:02d}-step{step_number:02d}.png - 这些文件将嵌入到HTML审计报告中
- 使用
- 观察并记录:
- 步骤是否按预期执行?
- 是否存在UI/UX问题?(如标签混淆、对比度不足、响应缓慢)
- 是否存在技术问题?(如控制台错误、请求失败)
- 是否有潜在的改进点或功能想法?
- 记录观察结果后再进入下一步
发现问题时,创建问题任务:
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.
- After each workflow completes, append to
.claude/plans/browser-workflow-findings.md - If the file doesn't exist, create it with a header first
- Use the following format for each workflow entry:
markdown
---重要提示: 完成每个工作流后,立即将发现的问题写入日志文件。不要等到所有工作流都完成后再记录。
- 每个工作流完成后,将内容追加到
.claude/plans/browser-workflow-findings.md - 若文件不存在,先创建文件并添加标题
- 每个工作流条目使用以下格式:
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:
- Call to get summary of all workflow and issue tasks
TaskList - Read for detailed findings
.claude/plans/browser-workflow-findings.md - 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>- Every workflow section MUST include tags referencing the screenshots saved during Phase 3. Use relative paths:
<img>screenshots/browser-audit/wfNN-stepNN.png - Style with clean design, professional appearance, app accent color
- 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报告:
- 调用获取所有工作流和问题任务的摘要
TaskList - 读取获取详细发现
.claude/plans/browser-workflow-findings.md - 将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>- 每个工作流部分必须包含标签,引用阶段3中保存的截图。使用相对路径:
<img>screenshots/browser-audit/wfNN-stepNN.png - 采用简洁、专业的设计风格,使用应用的强调色
- 完成每个工作流后增量更新HTML文件,确保始终可以查看部分结果
同时向用户展示文本摘要:
undefinedAudit 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
undefinedTaskUpdate:
- taskId: [report task ID]
- status: "completed"
undefined已执行工作流: [完成数量]/[总数量]
发现的问题: [问题任务数量]
- 高严重程度:[数量]
- 中严重程度:[数量]
- 低严重程度:[数量]
报告路径: workflows/browser-audit-report.html
你希望执行以下哪个操作?
- "fix all" - 修复所有问题
- "fix 1,3,5" - 修复指定编号的问题
- "done" - 结束会话
undefinedTaskUpdate:
- taskId: [报告任务ID]
- status: "completed"
undefinedPhase 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.htmlScreenshot Naming Convention:
{NN}-{descriptive-name}.png- Examples:
- (before)
01-hover-states-missing.png - (after)
01-hover-states-added.png
Capturing BEFORE Screenshots:
- When an issue is identified during workflow execution
- Take screenshot BEFORE any fix is applied
- Save to
workflows/screenshots/{workflow-name}/before/ - Use descriptive filename that identifies the issue
- Record the screenshot path in the issue tracking
Capturing AFTER Screenshots:
- Only after user approves fixing an issue
- After fix agent completes, refresh the browser tab
- Take screenshot showing the fix
- Save to
workflows/screenshots/{workflow-name}/after/ - 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
捕获修复前截图:
- 在工作流执行过程中发现问题时
- 在进行任何修复前截取截图
- 保存到
workflows/screenshots/{workflow-name}/before/ - 使用能明确标识问题的描述性文件名
- 在问题跟踪中记录截图路径
捕获修复后截图:
- 仅在用户批准修复问题后进行
- 修复Agent完成工作后,刷新浏览器标签页
- 截取展示修复效果的截图
- 保存到
workflows/screenshots/{workflow-name}/after/ - 使用与修复前截图匹配的文件名格式
Phase 8: Fix Mode Execution [DELEGATE TO AGENTS]
阶段8:修复模式执行 [委托给Agent]
When user triggers fix mode ("fix this issue" or "fix all"):
-
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] -
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" -
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.-
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”)时:
-
从任务中获取问题列表:
调用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 / 特定编号] -
为每个要修复的问题创建修复任务:
对于每个用户希望修复的问题: TaskCreate: - subject: "Fix: [问题简要描述]" - description: | 修复来自任务[问题任务ID]的问题 **问题:** [问题名称和描述] **严重程度:** [高/中/低] **当前行为:** [存在的问题] **预期行为:** [应有的表现] **截图参考:** [修复前截图路径] - activeForm: "Fixing [问题简要描述]" TaskUpdate: - taskId: [修复任务ID] - addBlockedBy: [问题任务ID] # 将修复任务关联到对应的问题 - status: "in_progress" -
为每个问题生成一个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(已修改)
### 测试说明
- [如何验证修复有效]
```
不要运行测试 - 主工作流将处理测试环节。-
所有修复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:
-
Create a feature branch:bash
git checkout -b fix/browser-ux-compliance -
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" -
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" -
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
-
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} -
Report PR status to user:
PR created: https://github.com/owner/repo/pull/123 CI status: Running... (or Passed/Failed) -
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:
-
创建功能分支:bash
git checkout -b fix/browser-ux-compliance -
暂存并提交变更:bash
git add . git commit -m "fix: browser UX compliance improvements - [列出主要修复内容] - 更新测试以反映新行为 - 所有本地测试已通过" -
推送并创建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获取修复前后对比" -
监控CI:
- 等待CI工作流启动
- 若CI失败,分析失败原因
- 修复任何CI特定问题(环境差异、不稳定测试)
- 推送修复并重新运行CI
- 直到CI通过后再合并
-
更新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} -
向用户报告PR状态:
PR已创建:https://github.com/owner/repo/pull/123 CI状态:运行中...(或通过/失败) -
从任务中生成最终会话摘要:
调用TaskList生成最终摘要: ## 会话完成 **已执行工作流:** [已完成工作流任务数量] **发现的问题:** [问题任务数量] **已修复问题:** [已完成修复任务数量] **测试结果:** [来自验证任务元数据] **PR:** [来自PR任务元数据] 所有任务已成功完成。
MCP Tool Reference
MCP工具参考
Navigation:
- - Go to URL
navigate({ url, tabId })
Finding Elements:
- - Natural language search, returns refs
find({ query, tabId }) - - Get all interactive elements
read_page({ tabId, filter: 'interactive' })
Interactions:
computer({ action: 'left_click', coordinate: [x, y], tabId })- - Click by reference
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 })
Screenshots:
- - Capture current state
computer({ action: 'screenshot', tabId })
Inspection:
- - Extract text content
get_page_text({ tabId }) - - Check for errors
read_console_messages({ tabId, pattern: 'error' }) - - Check API calls
read_network_requests({ tabId })
Forms:
- - Set form field value
form_input({ ref, value, tabId })
导航:
- - 跳转到指定URL
navigate({ url, tabId })
元素查找:
- - 自然语言搜索,返回元素引用
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' }) - - 检查API请求
read_network_requests({ tabId })
表单:
- - 设置表单字段值
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)
无法自动化处理(必须跳过或标记为需手动测试)
-
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
-
Native Browser Dialogs
- ,
alert(),confirm()dialogs block all browser eventsprompt() - File upload dialogs (OS-level file picker)
- Print dialogs
- Workaround: Skip steps requiring these, or flag for manual testing
-
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
-
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
-
键盘快捷键
- 系统级快捷键(Cmd+Z、Cmd+C、Cmd+V等)可能导致扩展断开连接
- 触发浏览器原生行为的快捷键可能会中断会话
- 解决方法: 若有可用的UI按钮,优先使用UI按钮而非键盘快捷键
-
浏览器原生对话框
- 、
alert()、confirm()对话框会阻塞所有浏览器事件prompt() - 文件上传对话框(系统级文件选择器)
- 打印对话框
- 解决方法: 跳过需要这些操作的步骤,或标记为需手动测试
-
弹窗和新窗口
- 在MCP标签组外打开新窗口的弹窗
- 重定向到外部认证页面的OAuth流程
- 解决方法: 记录为需手动验证的内容
-
系统级交互
- 浏览器权限提示(摄像头、麦克风、通知、位置)
- 下载对话框和下载管理
- 浏览器设置和偏好设置页面
- 解决方法: 预先配置权限,或跳过这些步骤
Handling Limited Steps
处理受限步骤
When a workflow step involves a known limitation:
- Mark as [MANUAL]: Note the step requires manual verification
- Try UI Alternative: If testing "Press Cmd+Z to undo", look for an Undo button instead
- Document the Limitation: Record in findings that the step was skipped due to automation limits
- Continue Testing: Don't let one limited step block the entire workflow
当工作流步骤涉及已知限制时:
- 标记为[MANUAL]: 注明该步骤需手动验证
- 尝试UI替代方案: 若测试“按Cmd+Z撤销”,则寻找撤销按钮替代
- 记录限制: 在发现的问题中记录该步骤因自动化限制被跳过
- 继续测试: 不要因一个受限步骤而阻塞整个工作流
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:
- Take a screenshot of the failure state
- Check console for errors ()
read_console_messages - Note what went wrong
- Ask the user: continue with next step, retry, or abort?
Do not silently skip failed steps.
若步骤失败:
- 捕获失败状态的截图
- 检查控制台错误(使用)
read_console_messages - 记录失败原因
- 询问用户:继续执行下一步、重试还是终止?
不要悄悄跳过失败的步骤。
Session Recovery
会话恢复
If resuming from an interrupted session:
Primary method: Use task list (preferred)
- Call to get all existing tasks
TaskList - Check for workflow tasks with status or
in_progresspending - Check for issue tasks to understand what was found
- Check for fix tasks to see what fixes were attempted
- 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
- Read to see which workflows have been completed
.claude/plans/browser-workflow-findings.md - Resume from the next uncompleted workflow
- 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.
若从中断的会话恢复:
主要方法:使用任务列表(推荐)
- 调用获取所有现有任务
TaskList - 检查状态为或
in_progress的工作流任务pending - 检查问题任务以了解已发现的问题
- 检查修复任务以了解已尝试的修复
- 根据任务状态从合适的位置继续执行
恢复决策树:
TaskList显示:
├── 所有工作流任务已完成,无修复任务
│ └── 询问用户:“审计已完成。是否要修复问题?”
├── 所有工作流任务已完成,修复任务处于in_progress状态
│ └── 恢复修复模式,检查Agent状态
├── 部分工作流任务处于pending状态
│ └── 从第一个pending工作流开始恢复
├── 工作流任务处于in_progress状态
│ └── 读取发现问题的文件以查看已完成的步骤
│ └── 从该工作流的下一个步骤开始恢复
└── 无任何任务
└── 全新启动(阶段1)备用方法:使用发现问题的文件
- 读取查看已完成的工作流
.claude/plans/browser-workflow-findings.md - 从下一个未完成的工作流开始恢复
- 为剩余工作流重新创建任务
始终告知用户:
从中断的会话恢复:
- 已完成的工作流:[来自已完成任务的列表]
- 发现的问题:[来自问题任务的数量]
- 当前状态:[in_progress任务的描述]
- 将从以下步骤继续:[下一个操作]除非用户明确要求,否则不要重新执行已通过的工作流。