菜单
页面健康检查与优化 SOP。对指定 URL 执行完整体检，发现问题直接修复或列出待修复清单。当用户提到"检查页面""页面体检""优化页面""页面很慢"或给出一个 URL 要求检查时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Go 语言项目的开发模式和最佳实践。当用户提到"写 Go 代码""Go 服务""Go 接口""goroutine""Go 测试"时使用。
macOS 桌面应用开发的模式和最佳实践。当用户提到"开发 Mac 应用""SwiftUI""Swift 代码""桌面应用""菜单栏应用"时使用。
创建或更新 Skill 的交互式 SOP，通过分步提问引导用户完成 Skill 设计与实现。当用户提到「创建 skill」「帮我做一个 skill」「更新 skill」时使用。
Agent 闭环自验证工作流，在完成代码修改后自动执行"写代码→构建→验证UI→查日志→修复→再验证"的完整循环。当 Agent 完成功能开发、Bug 修复、UI 修改、API 变更或任何代码改动后，应主动触发此验证流程，确保改动真正生效且无副作用。适用于 Web 前后端项目的闭环验证。
统一 AI 调用服务，三服务商策略（4sapi+sodao+OpenRouter），支持文本对话、图片理解、PDF/音视频分析、图像生成、流式输出、智能降级。当需要接入大语言模型或实现多模态 AI 功能时使用。
企微聊天记录查看方案，后端统一处理消息同步/解密/媒体下载/语音转文字，前端按业务场景分散在各模块。当需要展示聊天记录、实现会话历史查看或消息渲染时使用。
| name | page-health-check |
| description | 页面健康检查与优化 SOP。对指定 URL 执行完整体检，发现问题直接修复或列出待修复清单。当用户提到"检查页面""页面体检""优化页面""页面很慢"或给出一个 URL 要求检查时使用。 |
给一个 URL，用 Cursor 内置浏览器完成完整体检。能修的当场修，不能修的列清单。
打开页面 → 截屏 → 交互探索 → 逐项审查(数据/视觉/控制台/性能) → 修复 → 再验证
最多 3 轮修复循环。每轮修复后重新截图验证。
打开目标 URL，等待渲染完成（至少 2s），先 snapshot 获取 DOM 结构，再 fullPage 截图。内部滚动容器截不全时分段滚动截图。
点击页面内的交互元素，暴露子视图和弹窗，确保所有可达视图都被检查到。
安全分类：
| 级别 | 举例 | 操作 |
|---|---|---|
| 安全 | Tab 切换、折叠展开、筛选、排序、分页、查看详情、搜索 | 放心点 |
| 只读弹窗 | 新增按钮、编辑按钮 | 打开看布局就关闭，不提交 |
| 危险 | 删除、禁用开关、审批、确认提交 | 不点 |
去重：同类重复元素只点一个代表（如表格每行的编辑按钮只点第一行）。
顺序：Tab/分段器 → 筛选/搜索 → 查看/编辑弹窗 → 新增弹窗 → 展开折叠。每步截图，对新视图同样执行后续审查。
不做的事：不切换导航、不提交表单、不点删除、不做破坏性测试。
对主页面及交互探索中暴露的每个视图，逐一检查以下维度。不打分，只找问题。
乱码 — 观察截图和 DOM 文本中是否有 �、锟斤拷、â€"、???、□□□、emoji 异常等。可通过 browser_snapshot 获取 DOM 文本后检测。常见原因：charset 未声明、数据库连接字符集不匹配、utf8 应升级 utf8mb4。
模拟数据 — 疑似特征：规律姓名（张三李四）、整齐数字（100/200）、不合理时间、Lorem ipsum、占位图、虚假联系方式（13800138000）、数据量太规律。同时检查网络请求是否指向 mock 服务。
异常空数据 — 空表格、全零统计、空下拉选项、全空详情页。空数据大概率是 bug，排查路径：前端是否发请求 → API 是否正常返回 → 查询参数是否正确 → 数据库是否有数据。即使确认真无数据，也要确保空状态 UI 友好。
整体视觉 — 关注：色彩是否统一、排版层次是否清晰、间距是否一致、对齐是否规整、信息密度是否适中、视觉焦点是否明确。
交互反馈 — 关注：hover 是否有反馈、状态切换是否有过渡动效、数据加载是否有 loading/skeleton、空状态 UI 是否友好、长文本是否正确 ellipsis/换行。
组件一致性 — 关注：按钮主次是否分明、表格表头是否固定且列宽合理、表单标签是否对齐、卡片圆角阴影是否统一、弹窗尺寸是否适中、图标风格是否统一。
获取控制台消息。error 判断是否为业务错误（排除 Permissions-Policy 等环境噪音），忽略 [CursorBrowser] 前缀消息。
API 响应 — 从网络请求分析耗时：< 300ms 正常，300ms-1s 记录，1-3s 需优化（应有 loading），> 3s 必须优化。慢接口用 curl 测 TTFB，TTFB > 600ms 需排查后端。
前端加载 — 通过 Performance API 获取 FCP（< 1s 优秀 / > 2.5s 需优化）、Page Load（< 3s 优秀 / > 6s 需优化）。
体感 — 首屏 1s 内应可见主要内容、切换筛选 < 500ms、翻页应有 loading、弹窗应立即弹出。
发现问题就修，不要只列清单。agent 做检查的价值就是修完交付，不是当 QA 提工单。
定位源码 → 修改 → docker compose up --build -d <service> → 回到 Step 1 再验证。
只有以下情况才不当场修，而是列清单说明原因：
除此之外，CSS 修复、前端布局调整、添加 loading/hover、修复 mock 数据对接、修复空数据 bug 等——全部直接修。
检查完成后输出结果。已修复是主体，待修复是例外。
## 页面检查结果
**URL**: https://...
**检查时间**: YYYY-MM-DD HH:MM
**探索范围**: 主页面 + N 个 Tab + N 个弹窗
### 已修复（N 项）
| # | 优先级 | 问题 | 改动 |
|---|--------|------|------|
| 1 | P0 | 客户列表显示空数据 | 修复 API 查询参数 |
| 2 | P1 | 编辑弹窗内容贴边 | padding 0→20px |
| 3 | P2 | 按钮缺 hover 效果 | 添加 hover 样式 |
### 待修复（N 项，需人工介入）
| # | 优先级 | 问题 | 未修原因 |
|---|--------|------|----------|
| 1 | P0.5 | /api/customers 响应 2.8s | 需 DBA 加索引 |
### 检查通过项
数据正确性 ✓ | 控制台 ✓ | 前端加载 FCP 800ms ✓
每个页面必须使用独立的子 agent 执行检查。 这是硬性要求，不可在主 agent 中直接执行检查流程。