Communitygithub.com

竞品对比重设计

用于用户希望借鉴竞品(如Loom/Notion/Linear)来改进或重构自己应用功能时的场景。支持“看看竞品怎么做”、“截图对比”、“我们能从其他应用学到什么”、“将我们的X与Y对标”等任务,并生成包含当前UI和重设计对比的可视化提案。

竞品对比重设计 是什么?

该技能是一个系统化的竞品分析到重设计工作流,适用于开发者希望基于竞品洞察改进自己应用功能时的场景。技能分为四个阶段:第一阶段使用最多3个并行子代理(采用成本较低的Sonnet模型),分别截取当前应用和2-3个竞品的功能截图,子代理必须使用Playwright MCP的`screenshot`工具并保存截图到磁盘,同时要避免共享浏览器会话导致的交叉污染。主线程则同步调研代码库中的schema、读写层和页面。第二阶段将调研结果合成一份决策报告,包含现状、竞品对比、分阶段建议和批次决策题。第三阶段调用设计子技能,将当前UI截图与重设计画布并排展示,并用强调色标记所有修改和新元素。第四阶段(按需)写入实施计划。技能自带的参考运行记录在LOCAL.md中,展示了如何避免常见陷阱(如Playwright浏览器缺失、登录凭据无效等)。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Pure-Water-Automations/agent-skills/tree/HEAD/competitive-redesign

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

竞品对比重设计 是做什么的?

如果此SKILL.md旁有LOCAL.md文件,请先阅读它——该文件包含本工作区的具体信息(路径、工具、示例),并覆盖下方通用默认值。

研究 → 决策 → 设计。并行子代理截取我们功能的截图以及2-3个竞品产品的截图,调研结果形成差距分析,附带批次决策供用户选择;确定的方向构建设计画布:当前UI截图与重设计画板并排展示,每个差异都标记清楚。输出为一份决策+一份设计(+可选的实施计划)——该技能不编写产品代码。

下方提到的“参考运行”是该技能的首次真实运行(录音资料库重设计);LOCAL.md(如果存在)会指向它。这只是一个工作示例,用于证明形态和校准深度;不要为新的功能内容参考它。

阶段1 — 并行调研(低成本子代理,最多同时3个)

在同一条消息中最多启动3个子代理——使用Agent工具,general-purpose,model: "sonnet"(低成本模型足以完成基础调研工作,切勿超过3个并发——速率限制会杀死突发的子代理):

  1. 我们的——在我们的应用上截取该功能的截图。
      1. 竞品——用户命名了的产品优先占满这些位置,每个代理一个。剩余位置(用户命名了0或1个):由“调研”代理选择该功能领域公开文档最丰富的2-3个竞品。用户命名了3个或更多:给一个代理主要竞品,给另一个代理剩余所有产品。

在它们运行时,在主线程上熟悉我们的代码库:该功能的schema、读/操作层和页面。建议必须映射到真实字段(例如“project标签已存在,但UI从未暴露它”)——没有代码基础的竞品调研会生成一个无人能实现的愿望清单。

子代理简报——缺少这些部分会导致失败:

  • 仅使用Playwright MCP,绝不使用浏览器窗格——浏览器窗格截图无法保存到磁盘,协调器不可见。明确告知代理:使用mcp__playwright__playwright_screenshot,设置savePng: true + downloadsDir指向每个代理专用的临时子目录(ours/、loom/、competitors/),先执行mkdir -p,然后报告用ls验证过的绝对路径。
  • 并发代理共享同一个Playwright浏览器,必然导致会话交叉污染(一个代理截取了另一个代理页面的截图——在参考运行中发生过)。告知每个代理:在保留截图前,验证每张截图在视觉上是否与刚导航到的URL匹配;如果发现过时或外部截图,关闭Playwright浏览器,重新打开,重新截取。
  • Playwright chromium可能缺失(“Executable doesn't exist …”):从MCP的npx缓存目录执行npx playwright install chromium,然后继续(这是一个长期存在的问题,版本升级后依然存在)。
  • 我们的应用登录:给代理提供精确的配方——例如一个仅开发使用的登录表单(在/login上使用电子邮件+密码),使用在开发数据库中确实存在的活跃用户的电子邮件以及开发服务器环境中的开发登录密码。在启动代理前,你自己也要验证这两项(读取开发服务器上的环境变量,查询开发DB中活跃用户)。参考运行曾因使用了一个不在开发DB中的电子邮件而消耗了一个完整的代理在CredentialsSignin上。在应用的AGENTS.md/README中找到应用的开发认证路径。切勿将代理指向生产环境。
  • 竞品库位于登录后——指示代理使用帮助中心文章、营销/功能页面和文档(如support.loom.com等),不要尝试注册。要求提供一个结构化的功能清单(组织、发现/搜索、分享、工作流、AI、管理)+ 哪些功能是核心/受好评的 vs 企业级限制 + 一个“值得借鉴的独特创意”列表。

阶段2 — 综合整理并做出批量决策

为用户整合成一条消息:

  1. 当前状态——我们功能具备和缺少的内容,同时根据截图和代码(引用文件)进行验证。
  2. 竞品的做法——每个产品几行描述,只列可移植的部分。
  3. 分阶段建议——优先级从低到高:(a) 暴露代码已支持的、但UI未展示的功能,(b) 小规模迁移的组织特性,(c) 工作流特性。包括用户提示中的初始想法。标出有意跳过的内容(企业级形状、YAGNI原则)。
  4. 批量多选决策:2-4个会改变最终交付物的分叉点,每个提供带字母的选项+建议。不要零散地提问。

停下来等待决策。在未确定范围前不要开始设计。

阶段3 — 所选方向的设计画布

必备子技能: design技能(Claude设计画布 → Artifact)。它负责画布本身的机制;本阶段增加了对比惯例:

  • 当前UI截图作为独立画板(“当前 — X”)放在重设计画板(“重设计 — X”)旁边。在植入前将截图缩小至约70-100 KB的JPEG(使用sips -Z 900 -s format jpeg -s formatOptions 60 …)。
  • 重设计画板匹配应用的真实设计系统——先读取token文件和组件,复制精确的值(字体、颜色token、卡片圆角、按钮形状)。
  • 标记每一处差异:使用应用的强调色画虚线轮廓 + 在每个当前不存在的新元素上加小型“NEW”标签(修改过的元素用“CHANGED”标签变体)。未改变区域不做装饰——这种空白感让标记更易读。
  • 画布上的便签总结每个画板的差异 + 一个概览便签。模拟数据可以使用示例数据;在交接时说明。
  • 默认交付物为静态线框图;仅当用户要求时才构建可点击原型。

阶段4(仅当用户提出时)— 实施计划

必备子技能: superpowers:writing-plans。将每个任务基于阶段1的代码阅读;逐字搬运分阶段的范围和决策;最后给出执行模式选项(并行扇出/子代理/内联),不要未经提示就开始构建。

常见陷阱(都曾在参考运行中出现过)

症状修复方案
代理报告截图,但协调器看不到使用了浏览器窗格——重新简报:Playwright MCP的savePng + downloadsDir
截图显示的是代理导航之外的其他网站共享Playwright会话污染——关闭浏览器,重新打开,重新截取,视觉验证
开发登录时提示CredentialsSignin电子邮件在开发DB中不是活跃用户——查询开发DB,使用真正的活跃用户
"Executable doesn't exist … chromium"npx playwright install chromium(每个缓存目录,Playwright更新后重新运行)
扇出返回空或速率限制超过3个并发代理——每批≤3个,重试失败的节点,大声报告部分结果
建议与代码不匹配阶段1主线程代码基础调研被跳过——在综合之前完成它

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Pure-Water-Automations/agent-skills

Score any app (the user's own or a competitor's) on a research-backed rubric and produce a reusable, comparable scorecard — 0–5 per dimension with an evidence grade, noncompensatory gates checked first, and one "smallest fix" per weak dimension. Adapts to product stage: a pre-PMF app under ~100 users is scored on 9 dimensions, a growth-stage app on the full 23. Use whenever the user says "score this app", "grade the app", "rate the UI/UX", "how good is [app]", "app scorecard", "run the scorecard on [app]", "how does [app] stack up", "is this ready to launch / promote to prod", or wants a before/after number after a build sprint or a beta round. Reads the codebase + deploy + docs, optionally beta feedback / analytics, and refuses to invent retention, revenue, or PMF from code alone. Outputs a chat table plus a published HTML scorecard artifact. Pairs with ui-usability-audit (UI depth), qa-sweep (functional pass), dev-to-prod-promotion-review (release gate).

Pure-Water-Automations/agent-skills

Use when the user wants a multi-perspective brainstorm on a feature, app, or product area — "spin up agents with different personalities/job titles", "look at it from different angles", "panel of experts", "come up with 30 ideas and a top 5", "how can we make X more useful", "brainstorm what to do next with X" — especially when they also want to DECIDE on the ideas (implement / hold / reject) rather than just read a list. Also use when they ask to re-run or extend a previous panel, or to "make the ideas decidable like dev-to-prod-promotion-review".

相关技能