用途：当 PR 因 E2E 失败被阻塞、或 GitHub Actions 中上传了失败运行的 trace/Playwright report 制品时，使用本技能把“CI 失败到 PR 通过”的整个流程串起来。它只处理工作流与判断，Playwright/浏览器 CLI 语法由 playwright-cli 技能负责。
四个阶段：
- 失败识别：从 PR 号或运行 URL 入手，用 gh pr checks 找出失败的检查，记下 RUN_ID；用 gh run view <RUN_ID> --log-failed 只看失败步骤日志，确认 run-id、失败 spec 名、失败类型（断言/超时/初始化）。
- trace 收集：用 gh api repos/{owner}/{repo}/actions/runs/<RUN_ID>/artifacts --jq '.artifacts[].name' 列出制品名，再用 gh run download <RUN_ID> -n playwright-report -D /tmp/e2e-trace/<RUN_ID> 下载到工作树之外的隔离目录，避免污染仓库。
- 根因分析：用 npx playwright show-trace <trace.zip> 打开 trace，查看失败动作的 DOM、网络、控制台与时间线，形成一行假设，如选择器失效或产品回归。
- 修复与重验：实际修复交由 e2e-test-healer 处理；本技能负责用 git add -A && git commit && git push 推到同一 PR，再用 gh pr checks <PR号> --watch 观察 CI 重新变绿。若再次失败，从新运行的 trace 重复第 2 步。
适用场景：CI 中 E2E 失败需要从失败运行出发定位原因，并在同一 PR 上闭合验证环路。
限制与注意：若起点是“写新场景”则不属于本技能，应使用 e2e-flow-planner 和 e2e-test-generator；若已有本地 trace.zip 并只需修复，可直接使用 e2e-test-healer。若根因是产品代码回归，不应强行让测试通过，而应明确报告。简单失败可跳过 trace 直接进入第 4 步。E2E 作业与制品名因仓库而异，需先列出而非猜测；不要把 trace 截图或网络体中的机密信息写入代码或评论。各仓库的作业名、制品名等具体信息暂未提供。