
AI Agent Skill 本质上是一组可复用的任务说明,用来约束 Agent 在特定场景下该做什么、怎么做、遵守哪些规则。文章从 skill 和 tool 的区别讲起,解释了为什么 skill 能提升复用性和稳定性,并整理了编程与前端开发中几类常见的实用 skill,包含代码修复、代码审查、无障碍、React 性能优化等方向,同时给出 GitHub 地址和一个最小可用的 `SKILL.md` 示例,方便直接参考或上手编写。
如果你最近在用 Codex、Claude Code,或者别的 coding agent,应该已经见过 skill 这个词,它其实不复杂。
AI Agent Skill,本质上就是一组可复用的任务说明。它通常是一个目录,里面至少有一个 SKILL.md。这个文件会告诉 Agent:这个 skill 是干什么的、什么时候该用、执行时要遵守什么规则、可以参考哪些资料、是否能调用额外脚本。
如果这个 skill 再复杂一点,目录里还会带上 rules/、references/、scripts/ 这些内容。
my-skill/
SKILL.md
rules/
references/
scripts/你可以把它理解成给 Agent 的“任务说明书”。它和 tool 不是一回事:
比如,一个 Agent 可以有“读文件”“执行命令”“联网搜索”这些工具,但它要不要先读项目结构、改完要不要跑 lint、输出是给结论还是给 checklist,这些通常都属于 skill 的范围。
如果你经常让 Agent 做重复工作,skill 基本是值得写的。
下面这几个,是我觉得很容易复用的。所以分享在这里,需要的小伙伴请自取。
fix这个 skill 很适合放在“改完代码以后”的最后一步。它的事情很简单:格式化、跑 lint、把一些能自动修掉的问题先修掉。
很多项目里,最浪费时间的不是改代码本身,而是重复处理格式和静态检查。把这类动作收成一个 skill,Agent 会稳很多。
GitHub:
karpathy-guidelines这个 skill 不是在“加功能”,而是在“约束写法”。它强调的点很实用:先说清楚假设,别过度设计,只做必要改动,改完要有可验证的结果。
如果你不想让 Agent 一上来就写一大坨“看起来很完整、其实没必要”的代码,这类 skill 很有用。
GitHub:
find-skills不是每个 skill 都要自己写。这个 skill 的作用就是帮你找现成的 skill,再决定要不要装进项目。
对于经常换项目、换技术栈的人来说,这类发现型 skill 很省时间。
GitHub:
andrej-karpathy-skills如果你想直接看一组已经整理好的 skills,这个仓库值得翻一下。里面收了一批偏代码写作、工程习惯和任务约束的 skill,比较适合拿来参考结构,或者按自己的项目再拆分。
GitHub:
前端这边更适合做成 skill,因为很多工作天然就是 checklist。
frontend-code-review这个 skill 很适合用来做提交前检查,或者 review 单个组件文件。它会把问题按检查项去看,而不是泛泛说一句“代码还行”。
如果你经常 review tsx、ts、js 文件,这类 skill 几乎是必备的。
GitHub:
frontend-accessibility-best-practices无障碍这类事情,最适合收成 skill。因为它本来就有很多稳定规则,比如语义化标签、键盘可访问性、焦点管理、aria-live、reduced-motion 等。
单靠临时提醒很容易漏,做成 skill 以后,Agent 在生成和 review 组件时会可靠很多。
GitHub:
vercel-react-best-practices这个 skill 更偏性能和 React / Next.js 实战。比如怎么减少 waterfall、怎么拆客户端边界、怎么控制 bundle 体积、怎么减少重复渲染。
如果你的项目本来就是 React 或 Next.js,这类 skill 的收益通常很直接。
GitHub:
optimized-nextjs-typescript这个 skill 更像是一组偏工程化的默认约束,重点在 Next.js + TypeScript 项目里的结构、性能、错误处理和基本 UI 规范。
如果你经常起新项目,或者让 Agent 直接产出页面和模块代码,这种“通用基线型 skill”很好用。
GitHub:
最小可用版本其实不难。先写一个 SKILL.md,把这几件事说清楚就够了:
比如,最小可用版本可以先写成这样:
---
name: api-review
description: 在 review 接口代码时使用,重点检查入参校验、错误处理和返回结构。
---
# API Review
## 什么时候用
- 用户让 Agent review 后端接口代码
- 用户要求检查接口设计是否合理
## 要做什么
1. 先看接口的输入参数和校验逻辑
2. 再看错误处理和状态码是否一致
3. 最后看返回结构是否稳定,字段命名是否清楚
## 约束
- 优先指出真实 bug 和风险,不要泛泛而谈
- 如果没有明显问题,也要说明剩余风险
- 输出里要带文件路径和行号如果你想继续找现成的 skill,可以先看这两个仓库:
写到这里,其实可以看到,skill 不是什么很重的东西。它更像是把一类重复任务收拢起来,让 Agent 下次别再从头猜一遍。