热门 Skill 具体说明
brainstorming
作者
Obra
简介
Brainstorming 是一个强制性的前置设计与需求分析技能，旨在通过协作式对话，将你的初步想法转化为结构化、可执行的设计方案与需求文档。在完成文档并获得用户确认前，禁止执行任何实现类操作（如编写代码、初始化项目等）。
该技能避免了 “需求太简单而无需设计” 的反模式，所有需求均需经过设计阶段，从而降低最终实现的偏差与返工率。
应用场景举例
-
引入全新功能与组件
你可以在需要增加新的业务逻辑、开发独立的模块，或在现有系统中扩展新能力等场景中使用该技能。它会引导你明确新需求，梳理现有代码与新功能的耦合度，并提供最终的设计方案。
-
修改或重构现有逻辑
当你需要修改或重构现有逻辑（例如臃肿的代码）时，该技能会在修改前先探索现有结构和瓶颈，然后提出针对性的改进方案。
-
拆解并规划大型项目
面对搭建类似 Notion 的协作平台等宏大需求时，该技能会在早期阶段对项目范围进行收敛。它会引导你理清各个子系统的依赖关系，确定最小可行性版本（MVP），将整体项目拆分为多个可独立开发的小任务。随后，它会优先为第一个子项目启动设计流程。
-
涉及 UI/UX 的视觉辅助决策
当讨论诸如 “仪表盘布局” 或 “页面交互” 等需要直观展示的需求时，该技能会提供基于浏览器的可视化工具（Visual Companion），直接渲染线框图、架构图或多套布局方案。这种直观的对比展示能够帮助你更准确地完成设计相关的决策。
模板一：新功能开发
帮我头脑风暴一下如何实现[功能名称]。背景：- 当前系统状态：[简要描述现有架构/相关模块]- 目标用户/场景：[谁会用、什么时候用]- 已知约束：[性能要求、兼容性、截止时间等]我希望探索的方向：1. [方向A]2. [方向B]3. 其他你觉得值得考虑的方案请帮我从多个角度分析利弊。
模板二：技术方案选型
帮我头脑风暴一下[技术决策]的选型方案。需求场景：- 核心需求：[必须满足的功能点]- 规模预期：[数据量/并发量/团队规模]- 现有技术栈：[当前用了什么]评估维度：性能、开发效率、社区生态、学习曲线、长期可扩展性候选方案（如果有）：[A、B、C]
frontend-design
作者
Anthropics
简介
frontend-design 用于生成具备独特风格和高质量的前端界面，满足生产级 UI 标准。它的核心目标是避免生成同质化的“AI 风格” 界面，而是通过选择大胆、明确的美学主题（例如：极简、复古、未来感、野兽派等），并注重排版、色彩、动效、空间布局等细节，来打造具有辨识度和艺术感的前端界面。
应用场景举例
-
构建网页组件或页面
在从零开始创建一个具体的 UI 时（如一个 React 组件、一个 HTML/CSS 布局，或一个独立的静态页面），该技能会确保这个 UI 不仅功能完善，而且在视觉上具有辨识度。
-
开发完整的 Web 应用或网站
在构建落地页、仪表盘或小型网站等产品时，该技能会让 AI 从整体出发，确立一个统一且鲜明的设计风格，并将其全局应用到产物中。
-
美化或重塑现有界面
针对已有但设计质量较低的界面，可以使用该技能来提升界面的整体视觉质量，包括优化字体、配色、动效、布局等。
模板一：从零构建页面/组件
帮我设计并实现一个[页面/组件名称]。需求描述：- 功能：[核心功能点]- 目标用户：[使用场景]- 参考风格：[如：极简、brutalist、复古未来主义、玻璃拟态等]技术要求：- 框架：[React/Vue/纯HTML+CSS]- 响应式：[是否需要适配移动端]- 动效：[是否需要动画/交互效果]请确保视觉上有辨识度，避免千篇一律的 AI 风格。
模板二：完整网站/应用开发
帮我构建一个[产品类型]的完整网站。产品信息：- 名称：[产品名]- 定位：[一句话描述]- 核心页面：[首页、关于、定价、文档等]设计要求：- 整体风格：[请确立统一且鲜明的设计调性]- 配色偏好：[暗色/亮色/指定色系]- 字体风格：[现代/经典/手写]技术栈：[Next.js/Astro/HTML+TailwindCSS]
模板三：美化/重塑现有界面
帮我重新设计以下界面，提升视觉品质：当前问题：- [界面看起来很"AI模板感"]- [配色单调/布局死板/缺乏层次]- [具体截图或代码链接]期望方向：- 参考网站/风格：[提供参考]- 保留功能不变，只优化视觉层- 重点改进：[字体/配色/间距/动效/图标]
ui-ux-pro-max
作者
NextLevelBuilder
简介
提供全面的设计智能，用于跨多平台和框架构建专业 UI/UX。旗舰功能为 Design System Generator，支持分析项目需求并在数秒内生成完整、定制的设计系统。内含 50+ 种风格、97 组配色方案、57 组字体搭配的可搜索数据库，以及严格的 UX 和无障碍准则。
应用场景举例
-
做设计决策时查询最佳实践
在需要为产品选择配色方案、字体搭配、图表类型或布局模式时，该技能提供按行业/产品类型/风格筛选的系统化推荐数据库，用数据支撑设计决策。
-
审查与优化 UI 的可用性和合规性
对现有界面进行无障碍审查（对比度、触控目标、焦点状态）、响应式验证、性能指标检测等，确保 UI 满足 WCAG 和各平台 HIG 标准。
-
跨平台设计一致性对齐
同一产品在 Web/iOS/Android 三端需要保持设计一致时，该技能提供各平台的触控规范、安全区域、系统手势等差异化准则，确保一致体验。
模板一：设计决策查询
我正在设计一个[产品类型]的[具体模块]，需要查询设计最佳实践。具体问题：- [如何选择配色方案？适合金融类产品的色系是什么？]- [数据可视化应该用什么图表类型？]- [表单布局的最优实践是什么？]产品上下文：- 行业：[金融/电商/社交/SaaS/...]- 平台：[Web/iOS/Android/多端]- 用户群体：[C端大众/B端专业用户]
模板二：跨平台设计对齐
我的产品需要同时在 [Web/iOS/Android] 上保持一致体验。
当前组件：[如：底部导航栏/下拉菜单/弹窗]
请帮我对比各平台的规范差异：
- 触控规范
- 安全区域
- 系统手势冲突
- 原生组件 vs 自定义组件的取舍
并给出统一设计方案。systematic-debugging
作者
alexanderop
简介
四阶段系统化调试方法论，强调根因分析优先。 “猜测式修复”转变为遵循纪律的工程师，强制执行根因追踪（root-cause-tracing）、纵深防御（defense-in-depth）和条件等待（condition-based-waiting）技术。在提出修复方案之前，必须完成完整的问题诊断流程。
应用场景举例
-
排查任何技术问题的根因
遇到 bug、测试失败、性能退化或构建错误时，该技能强制执行”先调查再修复”的四阶段流程（根因调查 – 模式分析 – 假设测试 – 实施修复），防止盲目试错。
-
诊断多组件系统的故障点
在涉及多层调用链的系统中（CI —> 构建 —> 签名、API —> 服务 —> 数据库），该技能要求先在每个组件边界加诊断日志，定位到具体哪一层出了问题再行动。
-
打破”反复修不好”的僵局
当同一个问题已经尝试修复 3 次以上仍失败时，该技能会触发”质疑架构”机制，引导从根本上重新审视设计模式，而非继续打补丁。
模板一：排查具体 Bug
帮我系统化排查以下问题：问题描述：- 现象：[具体错误信息/异常行为]- 复现步骤：[1.xxx 2.xxx 3.xxx]- 预期行为：[应该怎样]- 实际行为：[实际怎样]环境信息：- 技术栈：[语言/框架/版本]- 出现频率：[必现/偶现/特定条件]- 最近变更：[最近改了什么]请按四阶段流程执行：根因调查 - 模式分析 - 假设测试 - 实施修复。禁止猜测式修复。
模板二：多组件系统故障定位
系统出现[故障现象]，涉及多个组件：调用链路：[客户端] - [API网关] - [服务A] - [服务B] - [数据库]已知信息：- 报错位置：[哪一层报错]- 日志摘要：[关键日志]- 监控指标：[CPU/内存/延迟/错误率]请先在每个组件边界加诊断点，确定故障精确位置后再行动。
模板三：打破反复修不好的僵局
以下问题已经尝试修复[N]次仍然失败：问题：[描述]已尝试的方案：1. [方案A] - 结果：[失败原因]2. [方案B] - 结果：[失败原因]3. [方案C] - 结果：[失败原因]请触发"质疑架构"机制：- 是否当前设计模式本身就不适合这个场景？- 是否需要从更上层重新思考？- 有没有完全不同的实现路径？
writing-plans
作者
Obra
简介
将头脑风暴输出转化为可执行的结构化实施计划。能够将项目拆解为独立的工作流，定义带有明确完成标准的任务，规划风险与缓解策略。支持通过 TUI 或命令同步任务。输出极其细粒度的 2-5 分钟步骤，包含完整代码示例和测试模式。
应用场景举例
-
将设计规格转化为可执行的实施步骤
拿到一份技术设计文档或需求规格后，该技能会生成精确到文件路径、代码片段、测试命令和预期输出的分步任务列表，确保执行者无需额外沟通即可完成。
-
为多人协作或任务编写指南
给团队新人、开源贡献者或子代理编写实施计划时，该技能确保计划本身是零上下文可执行的——不假设读者了解代码库，每步都有完整信息。
模板一：设计文档转实施计划
请将以下技术设计转化为详尽的分步实施计划：
[粘贴设计文档或简要描述设计方案]
要求：
- 精确到文件路径和代码变更位置
- 每步包含：操作、预期输出、验证方法
- 一个零上下文的工程师拿到后能直接执行
- 标注步骤间的依赖关系
- 估算每步耗时模板二：为团队/新人编写指南
请为[目标读者]编写一份实施指南：
任务目标：[需要完成什么]
代码库信息：
- 仓库：[地址]
- 关键目录结构：[列出相关目录]
- 本地运行方式：[如何启动开发环境]
要求：
- 不假设读者了解代码库
- 每步都有完整的命令和文件路径
- 包含常见问题和排错指引
- 标注哪些步骤可以并行find-skills
作者
Vercel
简介
帮助用户从开放的 Agent Skills 生态（skills.sh）中发现和安装第三方 Skill。支持关键词模糊搜索数千个社区 Skill（前端、后端、DevOps、测试等），列出任意 Git 仓库中托管的 Skill，并安装到目标 Agent 中。提供可复现的 Git 安装、Agent 作用域控制和快速发现能力。
应用场景举例
-
快速定位适合当前任务的 Skill
面对一个新任务但不确定该用哪个 skill 时（或者刚安装了一批 skill 包），该技能帮助根据任务描述从已安装集合中检索和推荐最匹配的 skill 或 skill 组合链。
模板一：根据任务查找 Skill
我需要完成以下任务：[任务描述]
请从已安装的 skill 中帮我推荐：
- 最适合的单个 skill
- 如果需要组合使用，建议调用顺序
- 每个推荐的理由模板二：Skill 能力总览
列出当前已安装的所有 skill，按类别分组，注明每个 skill 的核心能力和典型使用场景。using-superpowers
作者
Obra
简介
Superpowers 框架的核心引导 Skill，强制执行 LLM Agent 的标准工作流：在任何回复或操作之前，必须检查并调用相关的 Skill。建立严格的调用规则（只要有任何可能适用就必须调用）、指令优先级排序（用户指令 > Skill 指令 > 默认系统提示）以及 Skill 使用声明。
应用场景举例
-
确保每次行动前都检查可用 Skill
作为框架级 skill，它在对话启动时自动生效，建立”先查 skill 再响应”的强制纪律，防止 AI 跳过合适的 skill 直接用默认行为处理问题。
-
管理多 Skill 间的优先级和调用顺序
当多个 skill 可能适用时（如 bug 同时涉及调试和前端），该技能规定调用顺序：流程 skill（brainstorming/debugging）优先于实施 skill（frontend-design/testing）。
模板一：启动时激活框架
在开始工作之前，请先检查可用的 skill 列表，确保后续每个任务都使用最合适的 skill 来处理。当前任务：[描述任务]请按照以下优先级选择 skill：1. 流程类 skill（brainstorming/debugging）优先于实施类2. 有专用 skill 时禁止用默认行为替代3. 多个 skill 适用时说明选择理由
karpathy-guidelines
作者
Forrest Chang
简介
基于 Andrej Karpathy 对 LLM 编码陷阱的观察提炼而来的行为准则。用一个 CLAUDE.md 文件纠正 AI 编码 Agent 的常见问题：过度假设并盲目执行、过度复杂化代码和 API、堆砌抽象、不清理死代码、随意修改/删除不理解的注释和代码等。核心四原则：先思考再编码、简洁优先、手术式修改、目标驱动执行。
应用场景举例
-
约束 AI 在编码时保持简洁和克制
编写新代码时，该技能防止 AI 过度设计——不加不必要的抽象层、不做推测性功能、不为单一用途的代码创建接口，强制用最少代码解决当前问题。
-
规范对存量代码的修改方式
修改已有代码时，该技能要求只改必须改的部分——不”顺手”重构、不改相邻格式、不删不理解的注释，每一行变更都必须能追溯到用户请求。
-
在需求模糊时显式暴露假设
当任务存在多种理解方式时，该技能禁止 AI 默默选一个方向执行，而是要求列出所有可能的解读、声明不确定性，由用户决定方向。
模板一：编写新代码时约束
请帮我实现[功能描述]。
编码约束（Karpathy 准则）：
- 用最少的代码解决当前问题
- 不加不必要的抽象层或接口
- 不做推测性功能（YAGNI）
- 每个函数/类都必须有明确的当前用途
- 如果需求有歧义，列出假设让我确认，不要自己猜模板二：修改已有代码时约束
请修改以下代码：[描述需要改什么]
修改约束（Karpathy 准则）：
- 只改必须改的部分
- 不"顺手"重构无关代码
- 不修改相邻的格式/注释
- 每一行变更都必须能追溯到我的请求
- 如果发现其他问题，报告但不动手改模板三：需求模糊时的显式确认
[描述一个可能有多种理解的需求]请不要直接开始实现。先：1. 列出你对这个需求的所有可能解读2. 标注每种解读的假设和影响3. 声明你不确定的地方4. 等我确认方向后再修改
webapp-testing
作者
Anthropics
简介
webapp-testing 是一个基于 Playwright 的本地 Web 应用测试工具集，支持前端功能验证、UI 调试、页面截图及浏览器控制台日志采集，遵循 “先侦查后执行” 的流程。该技能提供示例与辅助脚本，覆盖静态 HTML 自动化测试、元素定位、日志抓取能力，并可在多服务场景下统一管理服务器生命周期。
应用场景举例
-
前端功能验证
在本地开发 Web 应用（如 React、Vue、Svelte）时，通过自然语言描述测试需求（如 “测试登录流程”），AI 会调用该技能，自动生成 Playwright 脚本，模拟用户操作并返回结果。
-
UI 行为调试与分析
当你发现页面中某元素渲染异常或交互行为异常时，可向 AI 下达指令（例如：“截取首页完整截图” 或 “检查按钮的 DOM 结构”），AI 会执行该技能中的对应脚本，捕获截图或获取 HTML 内容，并将检查结果返回给你，以帮助你定位问题。
-
多服务应用测试
若你的应用为前后端分离架构，测试前端功能需后端 API 服务同步运行，只需向 AI 提供项目结构与启动命令，AI 会借助该技能中的 with_server.py 脚本来同时启动所有必需服务，再运行测试脚本，确保在完整的环境中执行测试。
-
静态页面测试
若你有不依赖服务器的纯静态 HTML 页面，需验证其内容或结构，只需向 AI 提供文件路径与测试需求，AI 会编写脚本并通过 file:// 协议在浏览器中打开该文件，然后执行自动化验证。
模板一：编写端到端测试
请为以下功能编写 Playwright E2E 测试：测试目标：- 功能：[如：用户登录流程/购物车结算/表单提交]- 关键路径：[列出需要覆盖的步骤]- 边界场景：[异常输入/网络超时/并发操作]技术环境：- 框架：[React/Vue/Next.js]- 测试基础设施：[已有 Playwright 配置？CI/CD 环境？]- 浏览器覆盖：[Chromium/Firefox/WebKit/移动端模拟]请生成可直接在 CI 中运行的测试代码。
Agent-browser
作者
Vercel
简介
agent-browser 是一个面向 AI 智能体的浏览器自动化 CLI 工具，用于执行网页交互与数据操作，包括页面导航、表单填写、点击操作、截图、数据提取及 Web 应用测试等，适用于以编程方式控制浏览器的自动化流程。
该技能支持的典型请求包括：打开页面、填写表单、点击元素、截图、抓取数据、登录网站等。
应用场景举例
-
测试网页中的复杂交互
当一个网页包含复杂的表单填写、下拉选择或多步点击时，可以借助该技能来自动化测试该网页。该技能通过快照命令（snapshot）获取页面内所有元素的简化标识（如 @e1），然后通过批量命令（batch）执行操作，从而提升执行效率并降低 Token 消耗。
-
抓取网页中的数据
当你需要从多个网页提取特定信息或结构化数据时，可以使用该技能。它支持提取页面链接（–urls）及指定元素内容（如 get text），并自动处理 Iframe，非常适用于结构化数据采集。
-
响应式布局与视觉回归验证
当需要验证网页在不同屏幕尺寸或设备上的表现时，可以使用该技能。它支持动态调整视口分辨率、模拟各类设备（如 iPhone 14），并生成全页面或特定元素的截图；结合 diff 功能，该技能非常适用于 UI 回归测试与布局校验。
模板一：网页自动化操作
请使用浏览器自动完成以下操作：目标网站：[URL]操作步骤：1. [打开页面/登录/导航到某处]2. [填写表单/点击按钮/选择选项]3. [提取数据/截图/下载文件]注意事项：- 使用无障碍树定位元素（而非 CSS 选择器）- 如果遇到动态加载，等待元素出现再操作- 操作完成后截图确认结果
pua
这个 Skill 比较有趣，小编刚看到这个 Skill 的时候还愣了一下。
作者
tanweai
简介
高能动性治理 Skill（PUA Debugging Skill），使用结构化压力迫使 AI Agent 进行穷尽式问题解决。采用 4 级升级系统、强制 7 项检查清单和 5 步系统化调试方法论。防止 Agent 被动等待、”差不多就行”和空口完成等失败模式，强制 Owner 意识和任务生命周期管理。
应用场景举例
-
突破 AI 反复失败的僵局
当 AI 在同一问题上连续失败 2 次以上、开始尝试相同方案打转时，该技能通过压力升级机制和强制 7 项检查清单，迫使 AI 切换到本质不同的解题路径。
-
提高 AI 交付物的完整性和可靠性
防止 AI 说”已完成”但没有验证证据、遇到困难就放弃或甩锅”环境问题”，强制要求每次交付都有数据闭环、每个诊断都有工具验证、解决问题后主动扫描同类隐患。
-
按任务类型匹配最优方法论
Debug 场景自动采用华为式 RCA 根因分析，新功能构建采用 Musk 式”质疑-删除-简化-加速-自动化”，代码审查采用 Jobs 式减法思维，让 AI 在不同任务中用最合适的思维框架。
模板一：突破反复失败的僵局
以下任务已经连续失败[N]次：任务：[描述]失败记录：- 第1次：[做了什么] - [为什么失败]- 第2次：[做了什么] - [为什么失败]要求：- 禁止重复之前的方案- 必须切换到本质不同的解题路径- 执行 7 项自查清单- 交付时提供验证证据
模板二：要求高质量交付
请完成以下任务，并满足严格的交付标准：
任务：[描述]
交付要求：
- 每个结论都有数据/工具验证证据
- 不允许说"应该可以"、"理论上"——必须实际验证
- 完成后主动扫描同类潜在问题
- 如果遇到困难，穷尽所有方案再报告，不允许轻易放弃模板三：指定方法论执行
请使用以下方法论完成任务：
任务类型：[Debug/新功能/代码审查/架构设计]
方法论选择：
- Debug：华为 RCA 根因分析——逐层排查、证据链完整
- 新功能：Musk 五步法——质疑需求-删除冗余-简化-加速-自动化
- 代码审查：Jobs 减法思维——每一行代码都要证明存在的必要性
- 架构设计：第一性原理——从基本事实出发推导，不接受"业界惯例"
任务描述：[具体内容]
如何在 SOLO 中安装 Skill
你可以在 SOLO 侧边技能市场中，点击右上角「上传技能」，导入包含 Skill.md 的文件即可。
为什么 Skill 调用失败 / 效果不好
如果你在对话中要求调用某个 Skill，但发现它没有按预期工作（比如报错、返回废话或答非所问），有可能是以下原因导致的：
1. 描述没有写对
-
现象：Skill 已安装且可用，但 Agent 在该用的时候不用，或不该用的时候乱用。
-
如何解决：Agent 是通过读取 Skills 的 Description 来判断“什么时候该用哪个 Skill”的。如果你的描述写得含糊不清、太专业或者太简单，Agent 就很难明白你的意思，自然在需要的时候就不会调用这个 Skill。用大白话写的清晰、准确的 Description。
2. Skill 未安装或未激活
-
现象：系统直接以普通对话回复你，完全没有触发特定工具链。
-
如何解决：检查 Skill 拼写是否正确，或参考上一节方法确保该 Skill 已被安装并在当前工作区启用。
3. 上下文缺失（Prompt 太模糊）
-
现象：Skill 被触发了，但输出的内容全是通用套话。
-
如何解决：Skill 的本质是强化的工作流和 Prompt 工程，如果没有提供明确的输入（如缺文件路径、缺具体目标），它只能”盲猜”，Agent 无法判断该路由到哪个 Skill。可以参考本文提供的提示词模板，补齐四要素（目标、输入、约束、期望输出）。
4. 路径/格式 错误
-
现象：AI 返回“未查询到对应的 Skill”
-
如何解决：
-
确认 Skill 存放路径正确：确认是否把 Skill 创建到了正确的文件夹下（比如项目文件夹下的.trae/skills或者全局路径.trae/skills或者.trae-cn/skills）
-
检查文件结构是否完整：skill.md 必须包含 name、description 等信息
-
验证 Skill 是否被正确加载：重启 IDE 或刷新 Agent 会话，确保新增 / 修改的 Skill 被重新索引；在对话中尝试使用 /skill-name 直接触发，确认 Agent 能否识别到该 Skill
-
排查参数格式问题：核对 SKILL.md 中定义的参数 schema 与实际调用时传入的参数是否一致核对 SKILL.md 中定义的参数 schema 与实际调用时传入的参数是否一致
5. 使用了错误的 Skill
-
现象：Skill 反复尝试但效果较差。
-
如何解决：退回一步，先使用 find-skills 确认当前场景下最适合的专属工具。
