Agent 新手 Skill 优先级指南：从第一套必装工作流，到专业能力补全
刚接触 Agent 时，很多人都有同一个错觉：只要模型够强，给一句"帮我把项目做好"，它就能自动写代码、查资料、跑测试、修 Bug、做文档。
真用起来才发现：Agent 不缺"聪明"，缺的是一套稳定的做事方法。
如果把大模型比作一个能力很强的新同事，那么 Skill 就像团队交给他的 SOP：遇到 Bug 先收集证据，开发功能先写测试，查第三方库先看当前文档，制作 Word 或 PDF 必须渲染检查，而不是生成文件就算完成。
本文不堆几十个名字，而是从一套真实安装的 Skill 清单里，挑出最适合新手的高频组合，并给出可以直接复制的触发话术。
你可以把它当成一份 Agent 入门配置单：不知道装什么，照着第一梯队选；不知道怎么用，直接复制每一节的提示词。
一、Skill 到底是什么？
Skill 可以理解为一个可复用的任务工作流。
它通常以 SKILL.md 为入口，里面会写清楚：
- 什么情况下应该触发；
- Agent 应该按照什么步骤工作；
- 哪些事情必须检查；
- 哪些操作不能擅自执行；
- 需要读取哪些参考资料；
- 是否要调用配套脚本、模板或资源。
因此，Skill 不是给模型"增加一段知识"那么简单。一个设计良好的 Skill，会改变 Agent 完成任务的过程。
例如，同样是"修复登录失败"：
text
没有调试 Skill：
看到报错 → 猜一个原因 → 改代码 → 宣布修复
使用调试 Skill：
复现问题 → 收集日志 → 缩小范围 → 建立假设
→ 用实验验证 → 定位根因 → 实施修复 → 回归验证两者最大的区别，不是回答写得长不长，而是结果能不能被证据支撑。
Skill、Plugin、MCP，不要混在一起
| 名称 | 解决什么问题 | 可以怎么理解 |
|---|---|---|
| Skill | 告诉 Agent 怎样完成某类任务 | SOP / 操作手册 |
| Plugin | 打包多个 Skill、工具、应用或配置 | 扩展安装包 |
| MCP | 让 Agent 连接外部数据和操作能力 | 标准化连接器 |
举个例子：
- "处理 PR 失败检查的步骤"适合写成 Skill；
- 一整套 GitHub 协作能力可以通过 Plugin 提供；
- 真正读取仓库、Issue、PR 和 Actions 数据，可能通过 GitHub 连接器或 CLI 完成。
一句话记忆：
Skill 负责流程，Plugin 负责打包，MCP 负责连接。
二、新手不要一口气装 50 个：先看优先级总榜
我更推荐按任务频率和失败成本排序，而不是看到名字有趣就全部安装。
下面的优先级针对的是"刚开始让 Agent 参与真实项目的开发者"，不是下载量榜单，也不是所有人的唯一答案。排名综合考虑四项指标：
- 覆盖面：能否用于多数软件项目；
- 纠错价值：能否减少返工、误改和假完成；
- 上手成本：新手是否可以快速获得收益；
- 闭环能力：是否包含计划、执行和验证，而不只是生成内容。
新手 Skill 优先级总榜
| 优先级 | Skill / Skill 组合 | 为什么排在这里 | 新手建议 |
|---|---|---|---|
| 1 | Superpowers |
一次补齐需求澄清、计划、TDD、调试、审查和完成前验证 | 第一套工程工作流，优先安装 |
| 2 | diagnosing-bugs |
能阻止 Agent 在证据不足时乱猜、乱改 | 所有人都值得使用 |
| 3 | tdd |
用失败测试证明问题，用回归测试保护结果 | 写功能、修 Bug 的基本盘 |
| 4 | context7-cli |
降低模型使用过期第三方库 API 的概率 | 前端和 Node.js 项目尤其推荐 |
| 5 | browser:control-in-app-browser |
让 Agent 在真实页面验证，而不是只看代码 | Web 开发必备 |
| 6 | GitHub Skill 组合 | 打通 PR、CI、审查意见和发布流程 | 使用 GitHub 的团队推荐 |
| 7 | frontend-design |
从 Brief 快速生成有明确方向的完整页面 | 前端新手的第一套设计 Skill |
| 8 | UI UX Pro Max |
系统处理风格、配色、字体、组件、状态和可访问性 | 做后台、产品 UI 时优先 |
| 9 | taste-skill |
专治模板化落地页、作品集和营销页的"AI 味" | 有页面基础后再用 |
| 10 | prototype |
在正式开发前，用可丢弃代码验证交互和业务逻辑 | 需求不确定时使用 |
| 11 | mattpocock-skills |
把想法推进为领域文档、PRD、Issues 和多会话实现 | 中大型持续项目推荐 |
| 12 | handoff |
在会话或 Agent 之间保留关键上下文 | 长任务必备，短任务可省略 |
| 13 | grill-me / grilling |
通过追问暴露隐藏假设和需求冲突 | 需求模糊时启用 |
| 14 | domain-modeling |
统一业务术语，减少"同词不同义" | 复杂业务项目推荐 |
| 15 | codebase-design |
改善模块接口、职责和可测试性 | 项目进入维护期后使用 |
| 16 | improve-codebase-architecture |
对整个代码库进行系统化架构体检 | 有一定规模后再使用 |
| 17 | 文档与内容 Skill | 处理 Word、PDF、表格、PPT 和图片 | 按交付物安装，不必全装 |
最小安装顺序
如果你不想研究整张表，直接按这个顺序开始：
text
第 1 步：Superpowers
建立完整的软件工程流程
↓
第 2 步：Context7
补充当前第三方库文档
↓
第 3 步：Browser
建立真实页面验收能力
↓
第 4 步：GitHub Skills
接入 PR、CI 和代码审查
↓
第 5 步：按项目类型补前端、产品或文档 Skill需要注意：Superpowers 已经包含系统调试和 TDD 工作流。如果你启用了完整 Superpowers，可以不再重复安装同类 Skill；但单独列出 diagnosing-bugs 和 tdd，是因为很多人希望在不启用整套流程时，也能独立获得这两项能力。
text
第一层：编码基本盘
调试、测试、查文档
↓
第二层：交付闭环
浏览器验证、GitHub、代码审查
↓
第三层：复杂项目
原型、架构、领域建模、需求拷问
↓
第四层：非代码产物
Word、PDF、表格、PPT、图片如果你主要让 Agent 写代码，先完成第一层和第二层就足够了。
三、按照优先级逐个介绍
优先级 1：Superpowers------给 Agent 装上一套严格的软件工程流程
推荐词
如果你总觉得 Agent 写代码太急、喜欢跳过设计、测试和验证，那么 Superpowers 值得优先尝试。它不是某一个功能，而是一套覆盖头脑风暴、计划、TDD、系统调试、代码审查、并行开发和完成前验证的工程工作流。
Superpowers 不是"让模型更聪明"的魔法插件，它做的是让 Agent 按纪律办事。一套典型流程可能是：
text
brainstorming
↓
writing-plans
↓
test-driven-development
↓
systematic-debugging
↓
requesting-code-review
↓
verification-before-completion目前这套能力常见的组成包括：
brainstorming：编码前澄清目标和设计；writing-plans：把方案写成可以逐步执行的计划；executing-plans：按照计划执行并设置检查点；test-driven-development：先写失败测试，再写实现；systematic-debugging：从证据出发定位根因；requesting-code-review/receiving-code-review：请求和处理审查；verification-before-completion：宣布完成前必须提供验证证据；using-git-worktrees：用独立 Worktree 隔离并行任务；dispatching-parallel-agents：把可以独立完成的工作拆给多个 Agent；finishing-a-development-branch：收尾开发分支并决定合并方式。
适合谁？
- 刚开始用 Agent 做真实项目的新手；
- 经常遇到"代码写完了，但没测试"的人；
- 希望 Agent 在动手前先完成设计与计划的团队；
- 中大型功能、Bug 修复和多人协作项目。
不适合什么？
修改一个错别字、替换一条文案这类极小任务，如果机械执行整套流程，成本会大于收益。Superpowers 偏向严谨，应该把它用在值得建立工程闭环的任务上。
新手直接复制
text
请使用 Superpowers 工作流完成"为用户资料增加头像上传"功能。
先通过 brainstorming 澄清需求和边界，再写实施计划；
实现阶段遵循 TDD，完成后运行验证，并在宣布完成前列出测试证据和未覆盖风险。
不要擅自扩展图片编辑、裁剪或社交分享功能。优先级 2：diagnosing-bugs------别让 Agent 靠猜修 Bug
它解决什么问题？
很多 Agent 在看到报错后，会立即修改最可疑的代码。偶尔能成功，但也可能掩盖真正原因，甚至引入新的回归。
diagnosing-bugs 强调完整诊断循环：确认现象、收集证据、缩小范围、验证假设，最后定位根因。
适合场景
- 接口报 500；
- 页面白屏；
- 构建或测试失败；
- 内存、CPU 或请求耗时异常；
- "昨天还能用，今天坏了"。
新手直接复制
text
请使用 diagnosing-bugs Skill 诊断这个问题。
先复现并收集证据，不要直接修改代码；给出最小复现、候选原因、验证实验和最终根因。
问题现象：点击登录后页面一直转圈，Network 中 /api/login 返回 401。如果只想查原因，可以加一句：
text
只诊断和解释根因，暂时不要实施修复。这是一个重要习惯："诊断"与"修复"不是同一个授权。
优先级 3：tdd------让 Agent 先证明问题，再动实现
没有测试约束时，Agent 很容易出现"假完成"：代码看起来合理，但没有证明功能真的工作，也没有保护旧行为。
TDD 的基本节奏是：
text
Red：先写一个会失败的测试
↓
Green：写最少的实现让测试通过
↓
Refactor：在测试保护下整理代码新手直接复制
text
请使用 tdd Skill 实现"优惠券不能与新人折扣叠加"。
先写一个能复现当前错误行为的失败测试，确认测试确实失败；
然后做最小实现让测试通过，最后重构并运行相关测试集。修 Bug 时可以这样说：
text
这个 Bug 会让 0 元订单仍然收取服务费。
请用 TDD 修复：先写回归测试证明问题存在，再修改实现，最后运行测试并报告结果。TDD 不是"改完代码后补几个测试"。如果失败测试从未出现过，你就无法确认它真的捕获了问题。
优先级 4：context7-cli------查当前库文档，不靠过期记忆
前端和 Node.js 生态更新很快。模型可能记得旧版 API，却不知道当前版本已经改名、弃用或改变配置方式。
context7-cli 用于通过 Context7 获取当前库文档，也可以管理面向编码 Agent 的文档能力。
新手直接复制
text
请使用 context7-cli 查询当前版本的 Zod 文档，确认 discriminatedUnion 的推荐写法，
然后再检查 src/schema.ts。不要只依赖模型记忆。或者：
text
这段代码使用 Next.js 当前稳定版本。
请先通过 Context7 获取相关文档，再给出修改方案，并说明依据的是哪个版本的用法。Agent 写错代码，很多时候不是推理能力不够，而是上下文中的 API 信息过期。先查文档，能消灭一大类低级错误。
优先级 5：browser:control-in-app-browser------亲自打开页面验收
"代码编译通过"不代表页面真的能用。浏览器控制 Skill 可以让 Agent 打开页面、点击、输入、截图并验证本地 Web 应用，还能利用浏览器中已有的登录状态。
新手直接复制
text
请使用 in-app browser 打开本地网站 http://localhost:3000，
按真实用户路径完成"注册 → 登录 → 新建项目 → 退出登录"，
记录每一步结果；如果失败，保留截图和控制台证据。前端验收可以写得更具体：
text
修改完成后请在浏览器中验证：
1. 1440px 桌面宽度下布局正常；
2. 390px 移动端没有横向滚动；
3. 键盘 Tab 可以访问提交按钮；
4. 表单错误信息清晰可见。浏览器适合页面交互和视觉验证。读取 GitHub PR、Notion 文档或数据库记录时，如果已有专用连接器，应优先使用语义化工具。
优先级 6：GitHub Skill 组合------看 PR、修 CI、处理评论、发 PR
GitHub 场景不建议只装一个"万能 Skill"，而应该按任务拆开。
github:github：先看清仓库、Issue 和 PR
text
请使用 GitHub Skill 阅读这个 PR，概括改动目标、主要文件、风险、测试状态和仍需确认的问题。
暂时不要修改代码，也不要发布评论。github:gh-fix-ci：处理 GitHub Actions 失败
text
请使用 gh-fix-ci 检查当前 PR 的失败项。
先读取失败检查和日志，说明根因与建议修复；得到确认后再实施修改。github:gh-address-comments：处理审查意见
text
请使用 gh-address-comments 汇总当前 PR 尚未解决的审查意见，
按"必须修改、建议修改、需要澄清"分类。先不要自动处理存在争议的意见。github:yeet：提交、推送并创建草稿 PR
text
请使用 yeet 发布当前改动。
先确认 git diff、排除无关文件、运行相关测试；
然后用清晰的提交信息提交并推送，最后创建 Draft PR。读取 PR 是只读操作；提交、推送、评论、关闭 Issue 和创建 PR 都会改变外部状态。即使有 Skill，也要在提示词中明确授权范围。
优先级 7：frontend-design------快速产出有辨识度的前端
推荐词
想让 Agent 直接完成落地页、活动页、作品集或产品界面，可以先选 frontend-design。它适合把模糊的视觉需求转成具有明确设计方向的可运行前端，重点是避免"一眼 AI"的模板化页面。
它适合这样的任务：
- 从零创建一个宣传页；
- 根据品牌关键词设计页面；
- 将截图或设计参考还原成代码；
- 在现有技术栈中实现一套完整视觉界面。
新手直接复制
text
请使用 frontend-design Skill，为一个面向独立开发者的 API 监控工具制作首页。
用户是技术人员，设计气质要可靠、克制、偏工程化；
避免紫色渐变、三张等宽功能卡片和无意义玻璃拟态。
保留现有 React + Tailwind 技术栈，完成后检查桌面端和移动端。frontend-design 更像"从 Brief 到页面"的通用前端设计执行器。如果你已经有明确的设计系统和 UX 规范，下面的 UI/UX Skill 可能更适合。
优先级 8：UI UX Pro / UI UX Pro Max------系统化设计决策
推荐词
UI UX Pro 类 Skill 的优势不是单纯"让页面更好看"，而是帮助 Agent 系统考虑风格、配色、字体、组件、交互、响应式和可访问性。适合不知道该选哪套视觉方向，或者需要先建立设计系统再编码的新手。
不同仓库和版本可能叫 ui-ux-pro、ui-ux-pro-max 或相近名称，包含的数据库、脚本和支持技术栈也可能不同。安装前要以该 Skill 自己的 SKILL.md 和 README 为准，不要只认名字。
适合谁？
- 不会配色和字体的新手；
- 需要仪表盘、后台、移动端产品界面的人；
- 希望先形成设计规范，再批量实现页面的团队；
- 需要兼顾响应式、状态和无障碍的业务项目。
新手直接复制
text
请使用 UI UX Pro Skill 为 SaaS 订阅管理后台确定设计方案。
先根据 B2B 财务人员的使用场景选择布局、颜色、字体和组件规范，
再实现概览页。必须覆盖 Loading、Empty、Error 和成功状态，
检查文字对比度、键盘操作与移动端布局。注意：数据库里有几十种风格，不等于应该全部混在一个页面里。正确用法是基于用户、品牌和场景选择一套方向，然后保持一致。
优先级 9：design-taste-frontend------减少千篇一律的 AI 页面
很多 AI 页面都有相似味道：紫色渐变、三张卡片、巨大圆角、无意义图标和"赋能未来"的文案。
这个 Skill 面向落地页、作品集和改版任务，强调理解 Brief、选择设计方向、建立视觉系统，并在交付前检查。
text
请使用 design-taste-frontend 重新设计这个开发者工具首页。
目标用户是独立开发者，气质应当可靠、克制、偏工程化。
先审计现有页面，再确定设计方向；避免紫色渐变、随机玻璃拟态和模板化三卡片布局。
完成后用浏览器验证桌面端与移动端。如果只是修一个按钮颜色，不必启用它；要做整页设计或品牌级改版时，它才真正有价值。
taste-skill 的重点补充：专治"AI 味"落地页和作品集
推荐词
如果页面功能没有问题，但总有一股模板味，推荐 taste-skill。它会先读懂页面类型、目标受众、品牌资产和审美关键词，再选择设计语言，并主动避免 AI 常见套路。
当前这套 taste-skill 的正式名称是 design-taste-frontend，它尤其适合：
- Landing Page；
- 个人或工作室作品集；
- 营销网站；
- 编辑型页面和博客；
- 已有页面的视觉改版。
它会特别警惕这些 AI 默认答案：
- 没有理由的紫蓝渐变；
- 居中大标题加三张等宽卡片；
- 所有内容都塞进圆角卡片；
- 到处使用玻璃拟态；
- 字体、圆角和强调色不一致；
- 只设计"成功状态"，忽略加载、空内容和错误状态。
它并不是仪表盘、数据表格和多步骤产品 UI 的万能解决方案。这些场景更适合使用成熟设计系统或 UI UX Pro 类 Skill。
新手直接复制
text
请使用 design-taste-frontend 改版这个开发者作品集。
先说明你对页面类型、受众和视觉气质的 Design Read，
再确定布局变化、动效强度和信息密度；
保留现有个人品牌资产，避免默认紫色渐变、居中 Hero 和模板化卡片。
完成后执行移动端、无障碍、按钮对比度和内容溢出检查。三个前端 Skill 怎么选？
| 你的情况 | 优先选择 | 原因 |
|---|---|---|
| 只有一句需求，想快速做出完整页面 | frontend-design |
从 Brief 到页面，通用性强 |
| 不懂设计系统，需要系统选择配色、字体和组件 | UI UX Pro |
更偏设计规范与 UX 决策 |
| 页面能用但 AI 味重，需要提升审美辨识度 | taste-skill |
强调反模板化和交付前审计 |
| 营销页既要定规范又要高完成度 | UI UX Pro + taste-skill |
先确定系统，再做审美约束 |
| 从零开发且需求仍不明确 | Superpowers brainstorming + 前端 Skill |
先搞清楚做什么，再决定长什么样 |
不要默认同时调用三个。Skill 越多不一定越好；先判断当前瓶颈是"需求""设计系统""审美"还是"前端实现"。
优先级 10：prototype------需求没想清楚，先做一次性原型
很多需求在文字里看起来很清楚，做出来才发现核心交互根本不成立。直接进入正式开发，会把大量时间浪费在错误方向上。
prototype 适合构建"用来学习和验证"的一次性原型：状态与业务逻辑问题可以做成终端程序，UI 方向不明确则可以提供多个差异明显的方案。
新手直接复制
text
请使用 prototype Skill 验证这个想法：
做一个 AI 文章标题生成器，用户输入主题后可以切换"技术型、故事型、争议型"三种风格。
先做可丢弃原型，不接真实后端，不追求生产级架构；重点验证交互和状态是否合理。探索 UI 方向可以这样说：
text
请做 3 个差异足够大的首页原型，并在同一个路由中切换查看。
不要只是换颜色，要分别探索：编辑器导向、数据仪表盘导向、对话导向。原型是为了快速回答问题，不是偷偷变成生产代码。验证完成后，应重新确认数据模型、异常处理、权限、安全和测试策略。
优先级 11：mattpocock-skills------像产品团队一样把想法送到交付
推荐词
如果 Superpowers 更像严格的软件工程纪律，那么 mattpocock-skills 更像一条从想法、领域知识、PRD、Issue 到实现的产品工程流水线。它特别适合中大型功能、多会话开发和需要维护项目上下文的代码库。
使用前通常要先运行一次 setup-matt-pocock-skills，为仓库确定三件事：
- Issue 放在哪里，例如 GitHub、GitLab 或本地 Markdown；
- Triage 使用哪些标签；
- 项目的领域文档采用单上下文还是多上下文结构。
它的主流程可以概括为：
text
grill-with-docs
把想法问清楚，并沉淀 CONTEXT.md / ADR
↓
prototype（可选）
用一次性代码回答无法只靠讨论解决的问题
↓
to-prd
把讨论整理成 PRD
↓
to-issues
拆成可以由 Agent 独立领取的纵向任务
↓
implement
每个 Issue 在干净上下文中独立实现
↓
handoff
跨会话传递关键上下文此外还有：
triage：处理外部提交的 Bug 和功能请求；improve-codebase-architecture：持续发现代码库架构问题；domain-modeling：维护统一的领域语言；to-prd/to-issues：把讨论变成可执行项目；ask-matt：不知道该用哪条流程时充当路由器。
新手直接复制
text
请先使用 setup-matt-pocock-skills 检查当前仓库，
向我解释 Issue Tracker、Triage Labels 和 Domain Docs 三项配置，
每次只确认一个决定，不要直接创建文件。
配置确认后，再告诉我这个需求应该从 grill-with-docs、prototype 还是 triage 开始。Superpowers 和 mattpocock-skills 怎么选？
| 对比项 | Superpowers | mattpocock-skills |
|---|---|---|
| 核心定位 | 严格的软件工程执行纪律 | 从想法到 Issue 和实现的产品工程流 |
| 强项 | TDD、调试、计划、审查、验证 | 需求拷问、领域文档、PRD、任务拆分、交接 |
| 项目状态 | 单个任务也能使用 | 更适合已有仓库和持续项目 |
| 上手成本 | 理解每个阶段的触发条件 | 先配置 Issue、标签和领域文档 |
| 最适合 | "把这件事严谨地做完" | "把这个想法变成可持续推进的项目" |
两者并不冲突。一个很实用的组合是：
text
mattpocock-skills 负责把需求问清楚、写 PRD、拆 Issue
↓
Superpowers 负责在每个 Issue 内按计划、TDD 和验证完成实现优先级 12：handoff------给下一个 Agent 一份靠谱交接
复杂任务可能跨越多个会话或多个 Agent。如果只把聊天记录扔给下一个 Agent，它需要重新翻阅上下文，还可能漏掉关键决策。
一个合格的 Handoff 应包含：
- 目标与范围；
- 已完成内容和当前状态；
- 关键决定与相关文件；
- 已验证和未验证事项；
- 下一步行动；
- 风险和阻塞点。
新手直接复制
text
请使用 handoff Skill，把当前任务整理成一份可供另一个 Agent 直接接手的交接文档。
必须写清已修改文件、测试结果、未完成项、关键决策和下一步命令。它看似不直接产出代码，却能显著降低长任务中的上下文损耗。
优先级 13：grill-me / grilling------先把需求问穿，再开工
这类 Skill 会对计划或设计进行高强度追问，适合把隐藏假设、边界条件和冲突提前暴露出来。
text
请使用 grill-me 对这个方案进行压力测试：
"做一个支持多人协作的 AI 笔记应用"。
重点追问用户角色、权限、数据冲突、离线策略、成本、失败恢复和验收指标。
在关键决策没有明确前，不要开始编码。它特别适合"想法很大，但需求只有一句话"的项目。
优先级 14：domain-modeling------先把业务语言说清楚
当团队对"订单""支付""退款""撤销""取消"各有一套理解时，代码再漂亮也会持续返工。
text
请使用 domain-modeling 梳理这个订阅系统。
区分 Plan、Subscription、Entitlement、Invoice、Payment 和 Refund，
列出每个概念的定义、生命周期、约束和容易混淆的术语。如果项目已有相关文档，还可以让它维护术语表或记录架构决策。
优先级 15：codebase-design------寻找更稳定的模块边界
codebase-design 不是普通的格式优化。它关注模块接口、职责归属、可测试性和系统中的抽象边界。
text
请使用 codebase-design 审视支付模块。
重点判断接口是否泄露实现细节、业务规则是否散落、测试是否依赖内部结构，
给出 2～3 个模块深化方案，并说明迁移成本和风险。先评审，不要直接重构。适合出现这些信号时使用：
- 改一个功能需要修改很多不相关文件；
- 测试必须 Mock 大量内部对象；
- 模块名字很抽象，却没有真正封装复杂度；
- 业务规则散落在 Controller、Service 和组件中；
- Agent 每次都需要阅读半个仓库才能做小改动。
优先级 16：improve-codebase-architecture------给代码库做架构体检
这个 Skill 更适合系统级扫描：寻找模块深化机会、产出可视化报告，再选择一个问题继续追问和改进。
text
请使用 improve-codebase-architecture 扫描当前仓库，生成架构改进报告。
重点关注重复业务规则、过浅模块、跨层依赖和难以测试的边界。
先展示候选项，不要一次性重构整个项目。新手最容易犯的错，是让 Agent 看完整个仓库后"一次性优化架构"。正确做法是先扫描、再排序、选一个高价值点小步迁移。
优先级 17：Office 与内容交付 Skill
documents:documents：制作和修改 Word
适合创建、编辑、批注和红线修订 .docx。高质量文档 Skill 不只"生成文件"，还会渲染成页面图片检查版式。
text
请使用 documents Skill，把这份会议记录整理成正式项目周报 .docx。
包含摘要、进展、风险、下周计划和负责人表格；生成后必须渲染检查分页、表格和标题层级。pdf:pdf：阅读、生成和检查 PDF
text
请使用 PDF Skill 阅读这份报告，提取核心结论、数据口径和风险项，
并标注对应页码。不要只依赖纯文本抽取，遇到表格和图表时检查页面渲染。spreadsheets:Spreadsheets：创建与分析表格文件
text
请使用 Spreadsheets Skill 分析 sales.csv，
按月份和渠道统计收入、订单量、客单价与环比变化，生成一个带图表的 xlsx，
并检查公式、格式和异常值。presentations:Presentations：制作演示文稿
text
请使用 Presentations Skill，把这份 PRD 制作成 10 页产品评审 PPT。
受众是研发和设计团队；突出用户问题、核心流程、范围边界、里程碑和风险，避免大段文字。imagegen：生成封面、插画和位图素材
text
请使用 imagegen 为 RAG 技术文章生成 16:9 横版封面。
主题是"文档切分到向量检索"，深蓝科技编辑插画风，左侧预留标题空间，画面不要生成文字、Logo 或水印。如果项目已有 SVG 图标系统，则应优先继续使用可编辑的矢量资产，不要让位图生成器硬凑一套图标。
四、三套组合提示词，直接抄作业
套餐 A：日常写代码
text
Context7 查当前文档
↓
TDD 测试驱动实现
↓
Browser 真实页面验收直接复制：
text
请完成用户资料编辑功能：
1. 先用 context7-cli 查询当前表单库的推荐用法；
2. 使用 tdd 编写验证规则和提交逻辑；
3. 实现完成后运行测试；
4. 使用浏览器验证成功提交、空字段、非法邮箱和服务端失败四条路径；
5. 汇总修改文件、测试结果和仍存在的风险。套餐 B：修复线上 Bug
text
Diagnose 定位根因
↓
TDD 建立回归保护
↓
GitHub 创建 Draft PR直接复制：
text
请处理"重复支付回调导致订单积分增加两次"的问题：
1. 使用 diagnosing-bugs 复现并定位根因，先不要改代码；
2. 根因确认后，使用 tdd 写一个失败的回归测试；
3. 做最小修复并运行相关测试；
4. 检查 git diff，排除无关文件；
5. 经我确认后，再提交并创建 Draft PR。套餐 C：从模糊想法到可开发方案
text
Grill 澄清需求
↓
Domain Modeling 统一语言
↓
Prototype 验证交互
↓
PRD / Issues 形成任务直接复制：
text
我想做一个面向自由职业者的 AI 报价工具。
先使用 grill-me 追问需求和商业假设；
关键问题明确后，用 domain-modeling 定义客户、项目、报价单、版本和付款条款；
再使用 prototype 做一个可丢弃原型验证核心流程；
最后把已确认内容整理成 PRD 和可独立领取的开发任务。
在原型验证前不要进入生产级开发。五、怎样查找和安装 Skill？
如果环境提供 skill-installer，最简单的方式不是背命令，而是直接告诉 Agent：
text
请使用 skill-installer 列出当前可安装的 curated Skills，标注哪些已经安装。
暂时不要安装。选好以后再明确授权：
text
请安装列表中的 <skill-name>，安装完成后告诉我什么时候可以在新任务中使用。也可以从可信的 GitHub 仓库路径安装：
text
请使用 skill-installer 从我提供的 GitHub 仓库路径安装 Skill。
安装前先阅读 SKILL.md 和脚本，说明它将访问哪些文件、网络和外部工具；得到我确认后再安装。官方安装器默认可以查询 curated 清单，实验能力通常位于 experimental 目录。安装第三方 Skill 前，务必先阅读它的 SKILL.md 和配套脚本。
如果确实要手动执行，安装器通常提供类似下面的接口：
bash
# 查看 curated 清单
python scripts/list-skills.py
# 查看 experimental 清单
python scripts/list-skills.py --path skills/.experimental
# 从指定仓库路径安装
python scripts/install-skill-from-github.py \
--repo <owner>/<repo> \
--path <path/to/skill>不同环境中脚本所在目录可能不同，因此新手更推荐通过 skill-installer 发起请求，不要复制未知的本地绝对路径。安装完成后，新 Skill 通常会从后续任务开始可用，实际行为以当前环境提示为准。
六、第三方 Skill 不是越多越好：安装前检查 7 件事
Skill 会影响 Agent 行为，有些还会运行脚本和调用外部工具。安装陌生 Skill 前，至少检查：
- 触发条件是否清晰：声称"任何任务都应该使用"的 Skill 很容易冲突。
- 是否要求危险权限：警惕默认删除、覆盖、修改系统设置或自动推送代码。
- 有没有隐藏网络请求：检查会访问哪些域名、是否上传代码和文档。
- 是否读取密钥：不要把完整 API Key 粘贴到聊天中，密钥应在本地安全配置。
- 输出能否验证：好的 Skill 会要求测试、渲染、截图或日志证据。
- 与现有 Skill 是否重叠：多个"万能开发 Skill"可能相互争夺流程控制。
- 是否仍有人维护：检查最近提交、Issue、依赖版本和安装说明。
七、除了现有清单，还值得搜索哪些能力？
下面不是未经验证的"下载量排名"，而是值得补齐的能力方向。可以在 curated、experimental 或可信社区仓库中搜索关键词。
| 能力方向 | 搜索关键词 | 理想工作流 |
|---|---|---|
| 安全审查 | security review、threat modeling |
输入验证、鉴权、密钥、依赖和威胁模型 |
| 无障碍审计 | accessibility、a11y、WCAG |
键盘、焦点、对比度、表单标签、读屏语义 |
| 数据库迁移 | database migration、zero-downtime |
备份、兼容、回填、回滚、生产验证 |
| 可观测性 | observability、profiling、incident |
指标、Trace、日志、Profiling、复盘 |
| API 设计 | OpenAPI、contract testing |
契约、兼容性、错误模型和版本策略 |
| 发布管理 | release management、changelog |
版本号、Release Notes、发布前检查和回滚 |
推荐能力方向，不等于推荐任意同名仓库。下载第三方 Skill 之前，仍然要完成上一节的安全检查。
八、新手使用 Skill 的 5 条经验
1. 知道名字就直接点名
text
请使用 diagnosing-bugs Skill......比只说"帮我看看"触发更稳定，预期也更清楚。
2. Skill 不代替任务上下文
至少补齐目标行为、当前错误、相关范围、验收标准，以及哪些外部操作需要先确认。
3. 一次只组合必要的 Skill
"调试 + TDD + 浏览器验收"存在清晰的因果顺序；同时调用十几个无关 Skill，只会增加冲突和上下文噪声。
4. 要求交付证据
text
完成后请列出修改文件、执行过的验证、实际结果和未覆盖风险；不要只说"已完成"。5. 先读后写，外部操作单独授权
审查代码不等于允许修改；修好代码不等于允许提交；提交不等于允许推送；推送也不等于允许发布生产环境。
把授权边界写清楚，是使用 Agent 最重要的基本功之一。
九、别只装 Skill：用 CLAUDE.md / AGENTS.md 给项目立规矩
Skill 解决的是"某一类任务应该怎样做"，项目规则文件解决的是"在这个仓库里，Agent 永远应该遵守什么"。
不同 Agent 使用的文件名不完全一样：
| 使用环境 | 推荐文件名 | 用途 |
|---|---|---|
| Claude Code | CLAUDE.md |
保存项目背景、命令、约束和行为规范 |
| OpenAI Codex | AGENTS.md |
保存仓库级或目录级的持久指导 |
| 同时使用两者 | 两个文件都保留 | 共享规则保持一致，工具专属规则分别维护 |
注意是大写复数的 AGENTS.md ，不是 agent.md。文件名写错后，Agent 可能不会自动把它作为约定入口读取。
应该放在哪里？
对于普通单体项目，先放在仓库根目录：
text
my-project/
├── AGENTS.md
├── CLAUDE.md
├── package.json
└── src/大型仓库还可以在子目录放更具体的 AGENTS.md，例如：
text
my-monorepo/
├── AGENTS.md # 全仓库规则
├── apps/
│ └── web/
│ └── AGENTS.md # Web 项目专属规则
└── services/
└── billing/
└── AGENTS.md # 支付服务专属规则离当前文件更近的规则可以描述该子项目特有的命令、风格和验证方式。不要把所有细节都塞进根文件。
新手应该写什么？
一个实用规则文件通常包含：
- 项目是什么；
- 常用安装、开发、测试和构建命令；
- 哪些目录可以或不可以修改；
- 代码风格和架构约束；
- 完成任务前必须执行哪些验证；
- Agent 的通用行为准则。
下面这份模板专门解决 LLM 编码中最常见的四类问题：没想清楚就写、过度设计、顺手改无关代码、没有验证就宣布完成。你可以直接复制。
可直接使用的 CLAUDE.md
markdown
# CLAUDE.md
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
```text
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
```
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.可直接使用的 AGENTS.md
AGENTS.md 可以使用完全相同的行为规范，只需要修改标题：
markdown
# AGENTS.md
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
```text
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
```
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.别停在通用模板：再补上项目自己的信息
通用准则只能减少常见错误，无法告诉 Agent 你的项目怎样运行。建议在模板后追加：
markdown
## Project context
- This repository is a Next.js application for managing subscriptions.
- Application code lives in `src/`.
- Database migrations live in `prisma/migrations/` and must not be edited after deployment.
## Commands
- Install: `pnpm install`
- Develop: `pnpm dev`
- Unit tests: `pnpm test`
- Type check: `pnpm typecheck`
- Lint: `pnpm lint`
- Production build: `pnpm build`
## Verification
- Run tests related to the changed module.
- Run type checking for TypeScript changes.
- For UI changes, verify desktop and mobile behavior in a browser.
- Never claim completion without reporting the commands run and their actual results.怎样判断规则有没有写好？
拿一项真实任务检查：
- Agent 是否知道先读哪些文件？
- 是否知道使用
npm、pnpm还是yarn？ - 是否知道测试和构建命令？
- 是否知道哪些文件不能随便改？
- 是否知道完成的判断标准？
如果这些问题仍然需要每次重复说明，就应该继续完善 CLAUDE.md 或 AGENTS.md。
不要写成几千行的百科全书
规则文件应该短、明确、可以执行。庞大的架构资料应该放在专门文档中，再从规则文件链接过去，例如：
markdown
## Architecture
- Read `docs/architecture.md` before changing module boundaries.
- Read `docs/adr/` before reversing an existing architectural decision.
- Read `CONTEXT.md` for the project's domain terminology.这样既能保持入口清晰，也能让 Agent 在需要时获取更深的上下文。
总结：真正有用的不是"装了多少"，而是有没有形成闭环
刚开始使用 Agent，可以先从这套最小组合开始：
text
diagnosing-bugs ------ 用证据定位问题
tdd ------ 用测试保护实现
context7-cli ------ 获取当前库文档
browser control ------ 在真实页面验收
handoff ------ 长任务可靠交接项目复杂后，再加入：
text
prototype ------ 低成本验证想法
grill-me ------ 把模糊需求问清楚
domain-modeling ------ 统一业务语言
codebase-design ------ 设计更稳定的模块边界
GitHub Skills ------ 连接 PR、CI 和发布流程最后按交付物补充：
text
documents / pdf / spreadsheets / presentations / imagegenSkill 的意义，不是让提示词变得更花哨，而是把"高手知道该怎么做"的隐性经验，变成 Agent 可以稳定执行的工作流。
当 Agent 能够：
text
理解任务
→ 获取正确上下文
→ 按可靠流程执行
→ 用工具验证结果
→ 汇报证据与风险它才真正从一个"会聊天的模型"，变成一个"能完成工作的 Agent"。