总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/fullstack-agent-skills/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

这两个月我装了四十几个 Agent Skill，删掉三十几个，剩下的十几个是真在用的。删的理由不复杂，要么它定的规矩我不同意，要么装完之后 Agent 反而更糊涂。

先把这东西说清楚。它不是什么插件，也不是 MCP server，就是一个叫 SKILL.md 的 Markdown 文件，放在项目目录或者全局配置里。Agent 读到它，碰到对应场景就照它写的规矩干活。这套东西有了统一规范，Claude Code、Codex CLI、Cursor、Gemini CLI 这些主流工具都认。

下面这 12 个是我筛完留下的，前端四个、后端四个、运维四个，每个都给仓库地址和能直接抄的命令。

它不是一个软件，是一份写给 Agent 的规矩

注册站的官方 CLI 文档页

装 skill 的入口是官方的命令行工具，本身不用安装，一行 npx 就能跑。

npx skills add vercel-labs/agent-skills

装到哪里有讲究。项目级的目录是 .claude/skills/，只对当前仓库生效；全局的 ~/.claude/skills/ 对所有项目生效。个人习惯放全局，某个项目的业务规矩放项目里，两边别混。

这套东西现在有三块公共设施。命令行工具负责装，注册站 skills.sh 负责陈列，每个 skill 挂着累计安装量，官方 Tab 里还能按发布方筛；规范站 agentskills.io 负责定标准，里面有一页专门讲怎么写 skill。

再加一句实话，skill 的门槛低到你随手写一个也能装上。所以下面这 12 个我会标出发布方是谁，这一点比 Star 数有用得多。

前端这四条，前两条是框架方自己写的

next-best-practices

注册站的仓库页，能看到 skill 清单与各自安装量

Claude Code 裸写 Next.js 有几个反复出现的坑。把 Server Component 当 Client Component 用，'use client' 到处乱加，路由缓存策略搞混。

这份规范来自 Vercel 官方的 vercel-labs/next-skills，它把 Next.js 文档里最容易翻车的地方抽成了条目，App Router 的数据获取该用哪种模式、Server Actions 怎么处理 loading、Image 组件为什么必须给 sizes。

刚把项目迁到 App Router 的团队装上，能省下大量 code review 的时间。

npx skills add vercel-labs/next-skills --skill next-best-practices

vercel-react-best-practices

同一个仓库家族的 vercel-labs/agent-skills，里面有 16 个 skill，累计装了 250 万次。这一份是里面装得最多的，74 万次。

没装它的时候，Agent 写出来的组件十个里八个是 prop 地狱，isLarge、isDisabled、hasIcon 排一整排。装完它开始用组合式写法，拆得干净。

官方仓库的说明里写着这份规范现在有 70 条规则、分成 8 类，按影响大小排序，每条都配例子。

npx skills add vercel-labs/agent-skills --skill react-best-practices

frontend-design

这个 skill 想解决的界面千篇一律问题

Anthropic 自己发的，安装量已经过了九十万。它只干一件事，把你从 AI 生成的那种灰蓝渐变、Inter 字体、谁都一样的版式里拽出来。

你让它做个落地页，它会先问你要粗野主义、杂志感还是极繁，而不是直接丢一个跟十万个人撞脸的页面给你。设计上的事它没法替你拍板，但它至少会提醒你这里有板要拍。

npx skills add https://github.com/anthropics/skills --skill frontend-design

shadcn/ui

不装这个 skill 的时候，Agent 会徒手撸 dialog、form、table，根本不走 npx shadcn add。

这份是 shadcn/ui 官方仓库自带的，比第三方打包的版本靠谱。除了把组件导入流程钉死，它还能参照你项目里已有的 variant 和 size 来写新组件，风格不会跑偏。

顺带说一句，这个仓库本身有十二万多 Star，但它在注册站上作为一个 skill 的安装量是 27 万，两个数字不是一回事，别被 Star 数糊弄。

npx skills add shadcn/ui

后端这四条，从脚手架到迁移都有

dr-jskill

Dr JSkill 项目封面

作者 Julien Dubois 搞 Java 的都认识，JHipster 就是他写的。这个 skill 按他自己那套最佳实践生成 Spring Boot 项目骨架，Java 25、PostgreSQL、Docker 一次配好，前端可以在 Vue.js、React、Angular 里挑。

三百多 Star 不算多，但作者背书够硬，这种项目看发布方比看热度准。兼容 Claude Code、GitHub Copilot CLI、Windsurf。

npx skills add jdubois/dr-jskill

spring-boot-skills

这个仓库的思路我很认同，它自己写的原话是，AI 擅长 Python，但在 Spring Boot 上会幻觉。它的解法落到实处，每个 skill 下面都配了能直接复制的代码模板。

仓库里一共 66 个 skill，Spring Boot 3 和 4 各 33 个，覆盖 REST 接口规范、测试策略、数据库迁移、MCP 服务端这些。每个例子都是 good 与 bad 成对给的，Agent 抄哪边一目了然。

它没有走命令行安装那套，克隆下来把需要的目录复制进去就行。

git clone https://github.com/rrezartprebreza/spring-boot-skills
cp -r spring-boot-skills/skills/spring-boot-4/rest-api-conventions .claude/skills/

postgres-best-practices / sql-optimization-patterns / api-design-principles

这个合集的官方横幅

这三个来自同一个仓库，装的时候一条命令全下来，所以放在一起说。

这个仓库原来叫 antigravity-awesome-skills，现在 GitHub 上的名字是 sickn33/agentic-awesome-skills，四万六千多 Star，里面塞了两千四百多个 skill。npm 包名没跟着改，命令还是老样子。

postgres-best-practices 是 Supabase 团队写的那份，管 PostgreSQL 的类型选择、索引策略、约束设计、性能模式和行级安全策略。它跟你用 Spring Boot 还是 Node.js 没关系，SQL 是通用的。这份在注册表里也能单独找到，装在 supabase/agent-skills 那个仓库下，41 万次安装。

sql-optimization-patterns 治的是另一件事。裸写 JPA 或者 Prisma 的时候，Agent 生成的查询经常不跑执行计划，索引乱建。装上它之后，改 schema 时它会主动提醒，这个字段你后面可能要按它排序，建议建个复合索引。

api-design-principles 管接口约定，状态码怎么用、分页格式怎么统一、错误响应结构怎么设计。自己一个人写前后端的时候看不出问题，一旦跟别人协作，接口定义不一致立刻炸。

npx antigravity-awesome-skills --claude

migration-architect

来自 alirezarezvani/claude-skills，那个仓库现在有两万六千多 Star，描述里写着一共有 380 多个 skill。它管数据库迁移的整个生命周期，规划迁移顺序、检查向后兼容、生成回滚脚本。

有个教训值得说。有人改生产库，Agent 写的迁移脚本没加 CONCURRENTLY，上线锁表三分钟。装了它之后，它会先判断这次迁移能不能在线做，不能的话告诉你该用什么策略分批跑。

git clone https://github.com/alirezarezvani/claude-skills
cd claude-skills && ./scripts/install.sh --tool claude --target .

运维这四条，其中两条我建议只让它出方案

env-secrets-manager

它管 .env 和密钥的生命周期。扫你的代码库，找出哪些变量被硬编码了、哪些密钥已经进了 Git 历史、哪些 API key 该轮换还没轮换。

有人把一个 Stripe 的测试密钥写进了代码，commit 之前被它拦下来，直接给了文件名和行号。比事后跑去后台吊销密钥省心太多。

git clone https://github.com/alirezarezvani/claude-skills
cd claude-skills && ./scripts/install.sh --tool claude --target .

gh-fix-ci

CI 红了不用自己点进去翻日志。它自动读失败那一步的输出，定位到哪一行炸的，直接提一个修复的 PR。

有个项目 CI 连着挂了三次，每次都是同一个 ESLint 配置问题。到第三次，它顺手把 .eslintrc 里那条有毛病的 extends 规则也改了。

来自 openai/skills，那个目录下 curated 里的 skill 都挺克制。

npx skills add https://github.com/openai/skills --skill gh-fix-ci

ci-cd-pipeline-builder

它先分析你的技术栈，再生成一份 GitHub Actions 或者 GitLab CI 的配置。你告诉它项目用什么语言、什么框架、跑哪些测试，它输出的文件基本能直接用，镜像构建、多环境部署、缓存策略都按通行的做法来。

以前开新项目是从老项目拷配置文件过来改，十个项目八套格式。交给它生成之后，至少格式是统一的。它跟上面两个后端 skill 来自同一个仓库，安装方式一样。

这类工具有一条边界要自己守住，生成和执行要分开。让它出配置、自己审完手动应用，比让它直接动线上环境稳妥得多。

git clone https://github.com/alirezarezvani/claude-skills
cd claude-skills && ./scripts/install.sh --tool claude --target .

KubeShark

上 K8s 之前先让它过一遍，做的是失效模式分析，Service 的 selector 配错没有、HPA 设了没有、resource limits 写了没有。它对云厂商的差别也清楚，EKS 和 GKE 的负载均衡配置不一样，不会混着写。

仓库自己的说明写得很直白，大模型在 K8s 上幻觉特别多，这个 skill 就是来治这个的。装完之后最明显的改变是它会拦你，你写错了它当场指出来。

npx skills add LukasNiessen/kubernetes-skill

自己写，一条命令加一个文件

官方给 skill 作者的写作规范

别人的规范不一定是你的。有些 skill 强制某种查询写法，但小项目根本不在乎这个。

自己写比想象中简单，建个目录，再写一个 SKILL.md。

mkdir -p .claude/skills/my-api-patterns

文件长这样，frontmatter 里写清什么时候该加载，下面是具体规矩。

---
name: my-api-patterns
description: 我的 API 规范。写 Controller、Service、DTO 的时候加载。
---

# API 开发规范

## 触发条件

- 创建新的 REST 接口
- 修改已有 Controller

## 规则

1. API 响应统一用 ApiResponse<T> 包装
2. Controller 只做参数校验和路由，业务逻辑全在 Service
3. 分页参数统一用 { page, pageSize }，别用 offset
4. 错误处理用 @ControllerAdvice 全局拦截，别在 Controller 里 try-catch
5. 日志用 SLF4J，禁止 System.out.println

## 禁止

- 禁止在 Controller 里直接写数据库查询
- 禁止把 Entity 暴露到 API 返回里

我项目里现在挂着三个自己写的，API 规范、Git commit 格式、代码 review 清单，每个都不超过 200 行，比那些大而全的社区 skill 好使。

一个技巧是 SKILL.md 控制在 500 token 以内，详细资料扔到 references 子目录，Agent 按需加载，不用在开头就把所有东西吞进上下文。

装之前看一眼，装之后定期删一遍

SKILL.md 里是可以写 shell 命令的。这意味着一个来路不明的 skill 能在你不知情的情况下读 .env、改 ~/.ssh/，甚至往仓库里塞后门。

这不是假设。2026 年 1 月的 ClawHavoc 事件里，攻击者往 OpenClaw 的 ClawHub 技能市场塞了三百多个恶意 skill，后来统计到的数量超过一千个。

伪装方式很朴素，在 SKILL.md 里放一段 Base64 编码的命令，让你以为那是在装依赖。载荷偷的是加密货币钱包、~/.aws/credentials、SSH 私钥和 .env 文件，受影响的安装超过九千个。

官方命令行在安装时会做一次安全审计，但那只针对能确认公开的仓库。这道检查挡得住明显的恶意包，挡不住写得含糊的边界情况，替代不了你自己看一遍。我的做法有三步，装之前打开仓库看 SKILL.md，正经 skill 就是两三百行规范描述，看到一堆 curl、wget、eval 直接关掉；来路不明的先放项目级目录，影响范围可控；每个月清一次全局目录，不认识的删掉。

还有一个更隐蔽的坑是质量。同一个名字的 skill，安装量能差出五万倍。有的是框架团队发的，规则条条有出处；有的是谁周末花两小时写完顺手传的，里面还留着 class component 的写法。

Star 数能参考，但不绝对。

我判断的办法是看 SKILL.md 开头有没有触发条件。好的第一句就写，当你要创建 React 组件的时候激活；烂的只甩一句提高 React 代码质量。前者说明作者理解这套机制怎么工作，后者就是把自己的提示词贴了进去。

最后是装太多的副作用。每个 skill 的 description 都要在对话启动时进上下文，装得越多，Agent 匹配激活的准确率越低。我现在控制在 15 个以内，非核心的手动激活。

七千多个 skill 的生态，和它的底色

命令行工具的仓库页，Star 计数可见

管安装的那个命令行工具本身有三万两千多 Star，最近一次发版是一周前，MIT 协议。

注册站上现在挂着七千多个 skill，官方 Tab 里能按发布方筛，从 Anthropic、Vercel、Google 到 Stripe 都有官方维护的条目。每个条目都摆着累计安装量，这个数字比 Star 数更贴近实际使用，挑的时候可以拿去横向比。

所以一个 skill 值不值钱，看的是写这条规则的人有没有在一线用过这套东西，跟他列了多少条没关系。

我现在写代码跟两年前不一样了。以前是想清楚再手敲，现在是想清楚之后让 Claude Code 或者 Codex CLI 出第一版，我来 review，一起改。skill 就是我跟它的约定。

三年前说全栈，意思是你能写前端也能写后端。现在说全栈，意思是你能管着一个 Agent 把前后端都干了，同时还得判断它干得对不对。更累了，但确实更快。

建议你也试试，把日常开发里最烦人的规矩写成 SKILL.md。写三个你就知道，以后不用每次跟 AI 重复同一句话了。

文章目录
  1. 1. 它不是一个软件，是一份写给 Agent 的规矩
  2. 2. 前端这四条，前两条是框架方自己写的
    1. 2.1. next-best-practices
    2. 2.2. vercel-react-best-practices
    3. 2.3. frontend-design
    4. 2.4. shadcn/ui
  3. 3. 后端这四条，从脚手架到迁移都有
    1. 3.1. dr-jskill
    2. 3.2. spring-boot-skills
    3. 3.3. postgres-best-practices / sql-optimization-patterns / api-design-principles
    4. 3.4. migration-architect
  4. 4. 运维这四条，其中两条我建议只让它出方案
    1. 4.1. env-secrets-manager
    2. 4.2. gh-fix-ci
    3. 4.3. ci-cd-pipeline-builder
    4. 4.4. KubeShark
  5. 5. 自己写，一条命令加一个文件
  6. 6. 装之前看一眼，装之后定期删一遍
  7. 7. 七千多个 skill 的生态，和它的底色