Regulars 是一个 Claude 插件技能，用于通过模拟真实用户的子代理来验证网站是否可用。它的组织原则是任务完成：用户能否做到他们来时想做的事情。
用途
Regulars 用于在以下场景中验证网站端到端是否可用：上线前检查网站是否真正端到端可用；部署后检查是否破坏了某些用户流程；重构后确认用户是否仍能完成重要操作；以及周期性检查关键路径是否仍然可用。
它明确定位为不是 QA 测试套件或专家审计。Regulars 代理的行为像真实用户——它们不检查源代码，不检查每个元素，也不遵循测试矩阵。它们会像真实用户那样尝试完成一个目标。
主要能力
Regulars 会派出一个子代理面板（panel），每个子代理扮演一个具有特定任务的真实用户。它们使用浏览器 MCP 工具进行导航，尝试完成目标，并报告哪些环节出问题、哪些体验令人沮丧以及任务是否成功。
工作流程如下：用户请求冒烟测试后，识别该网站的关键用户任务；展示带有角色设定的任务面板；询问是否要添加、移除或调整；确定面板后，确保开发服务器正在运行；按顺序派发代理；每个代理完成后报告通过/失败与关键问题；全部完成后汇总为结果评分卡。
必须按顺序派发，因为浏览器 MCP 工具共享单个浏览器实例。
设计任务面板
与 review-squad:experts（固定默认面板）或 review-squad:normies（固定复杂程度区间）不同，Regulars 的任务是站点专属的，必须根据网站的功能来设计。
第一步：询问用户关键用户流程是什么，或阅读网站的导航/内容来识别它们。
第二步：为每个流程创建一个带有目标的角色。角色组件包括名称与性格（例如“Sarah，一位在午休时间用手机浏览的忙碌家长”）、目标（例如“找到 50 美元以下的生日礼物并加入购物车”）以及他们的操作方式（例如“快速滚动，有搜索就用搜索，按价格排序”）。
第三步：将面板提交给用户审批。
示例面板按网站类型划分。个人博客/作品集可包含：快速浏览的招聘人员（了解此人做什么及其经历）、博客读者（找到特定主题的文章并阅读）、老朋友（找到联系方式或联系途径）、RSS 订阅者（找到并订阅 RSS 源）、社交媒体访客（从分享的博客文章落地并浏览）、开发者同行（找到其 GitHub/项目）。电商网站可包含：送礼者（找到 50 美元以下商品、加入购物车、开始结账）、比价者（浏览分类、筛选/排序、比较两件商品）、回访者（查找订单状态或退货政策）、新闻订阅者（找到并完成注册表单）、移动端买家（在手机尺寸视口完成购买）、优惠券用户（在结账时应用折扣码）。SaaS/产品网站可包含：评估者（了解产品并找到定价）、免费试用用户（注册试用账号）、寻求支持者（找到文档或帮助）、企业买家（找到企业版/联系销售信息）、现有用户（登录并查看账户设置）、开发者（找到 API 文档或集成指南）。
代理提示模板
模板要求代理以某个角色身份出现，说明性格与浏览方式，并给出具体目标。要求代理不阅读任何源代码或项目文件，使用浏览器 MCP 工具在指定 URL 导航；如果是移动端角色，先将视口设为 375x812。任务步骤包括：导航到 URL 并截图；尝试完成目标；自然地操作，点击看起来对的地方，能搜索就搜索，在该滚动处滚动，不要按部就班而要像人一样；在每个主要步骤截图；如果某处不可用（按钮损坏、错误页面、死胡同），尝试真实用户会尝试的做法（后退按钮、刷新、不同路径）；测试一条不顺利路径（该任务特定的边界情况）；完成目标或放弃后停止。报告内容包括：目标、结果（已完成/部分完成/失败）、操作步骤编号列表、出错位置（如适用）、体验挫折点（即使技术上可用）、完成时间粗略估计（快/合理/极慢）以及是否愿意再来（是/否）。
关键元素包括：无代码保证——“不要阅读任何源代码”，Regulars 是用户不是开发者；具体目标——不是“探索网站”，而是“找到 50 美元以下礼物并加入购物车”；每个代理测试一条不顺利路径；人类行为——“做感觉自然的事”而非“逐步遵循测试脚本”；诚实的评判——“我还会回来吗”促使做出真实评估。
派发模式
按顺序而非并行派发，因为浏览器 MCP 共享单个浏览器实例。每个代理完成后，向用户简要报告通过/失败与标题问题。
汇总结果
汇总为评分卡，形式为 Regulars Review: [站点名称]，包含评分卡表格（序号、任务、角色、结果、问题）、总体结果统计（通过/部分/失败）、阻塞项（失败任务及其问题与严重程度）、摩擦项（通过但痛苦的任务及其令人沮丧之处）以及表现良好的方面。报告之后，展示评分卡；阻塞项是优先事项——完全失败的任务；询问用户是否想现在修复阻塞项；摩擦项进入待办清单。
常见错误
阅读代码——Regulars 不了解代码库，代理也不应阅读。泛泛的任务——“浏览网站”不是有效任务，每个代理需要具体目标并有清晰的通过/失败判定。只测试顺利路径——真实用户会遇到边界情况，每个代理应测试一条不顺利路径。QA 测试脚本——“点击元素 #submit，验证响应码 200”是测试脚本，不是 Regulars 的做法，代理应像人一样行事。并行运行——浏览器 MCP 是共享资源，只能顺序执行。每个网站使用相同面板——任务必须匹配该网站提供的内容，博客不需要“结账流程”测试者。