Agent Skills 测评手册：选型、写法与省 Token

文件放哪，门牌怎么写

1
skills/<skill-name>/SKILL.md

一技能一文件夹；文件夹名英文小写 + 连字符；主文件名写死 SKILL.md。

YAML 只管两样：

1
---
2
name: checking-code
3
description: Use when the user asks to review code or identify bugs
4
---

description 是门牌，不是操作手册。流程写正文。

正文七根柱子

照抄版把正文钉成七块；万能模板里常多一节「输入要求」：

1. 目标
2. 什么时候用
3. 什么时候别用
4. 执行步骤（编号、可执行）
5. 禁止事项（漏了最容易翻车）
6. 输出格式
7. 完成标准

写薄：作者建议 SKILL.md <500 英文词；细则、大例子、脚本拆到同目录的 references/ / examples/ / scripts/，别全塞进主文件。

checking-code 那例记住三条禁令就够：别评论不存在的代码；别顺手改无关代码；没验证别说「修好了」。

调用：目标 + 技能名 + 输入 + 输出

公式就四段拼起来。三种叫法都行——直接点名、说场景让它对上 Skill、顺带钉死输出格式。

四步不跳：说清任务 → 指定 Skill → 补齐输入 → 说明输出。缺材料就先让模型指出缺什么，别空跑。

万能调用（可粘贴）：

1
请使用 [skill-name]，帮我完成 [任务]。
2
背景信息：[...]
3
输入材料：[...]
4
输出要求：[...]
5
若关键信息缺失，请先指出。

装得起，正文拿不出

和 CLAUDE.md / MCP / 提示词怎么分：

分界线就一句：事实留常驻，流程抽 Skill。
CLAUDE.md 某段从「一条事实」长成「一套流程」——抽出去。MCP 和 Skills 不在一层，那是另一篇的事；这里只盯 Skills 自己怎么吃上下文。

三级披露：什么时候进窗口

运行时像翻盘：不读的文件不进上下文。省的是「没摸到的那块」，不是把正文写胖还能白嫖。

四条压力线（数字标出处）

下列数字均为作者转述官方口径，未在本轮核对原文。

装得起——常驻 ≈ N × 100。装得多不等于「随便装几百个都没事」；列表还有 1% 天花板。

拿不出——L2 一旦进窗口，整会话常驻；后续不重读、无淘汰。例外：allowed-tools 下一条消息清空。

会被砍——技能列表预算 = 上下文窗口 1%。超了从最少用的砍 description。单技能 description + when_to_use ≤ 1536 字符；关键用例写前面。被砍掉的关键词，可能就是匹配触发词——砍完等于这技能死了。

会被丢——会话压缩后重挂：每技能最近调用前 5000 token，全体技能共享 25000。老的整条丢；再调可回流恢复。

两边都爱踩的坑

安全另记一句：Skill 带着脚本和工具授权进来。只信可信源，用前逐文件审。外拉内容可能夹指令；授权别给得比任务宽。

认清撞上哪一层就行

写的时候盯七根柱子和「门牌别塞流程」。跑的时候先问：是门牌被砍了，还是正文写太厚，还是压缩把老技能整条踢了。

装得多不怕。怕的是触发后的常驻、列表 1% 被砍、压缩后 25000 共享丢光。

先钉四条规矩

五条改法：胖稿怎么削

原文给了「高 Token → 低 Token」对照。节省比例是经验估计，当方向看，别当精确账本。

1. 精简描述（估省 30%+）
   长自我介绍、背景铺垫 → 一句角色 + 任务。

2. 结构化表达（估省 20%+）
   「请详细分析…再给方案…注意全面…」→ 固定回答骨架：分析 / 方案 / 收尾判断 + 短要求。

3. 精简指令（估省 15%+）
   「仔细阅读并理解…多角度…最佳答案」→ 「理解问题，分析，给出最佳答案。」

4. 复用公共内容（估省 10%+）
   每个 Skill 复制同一 JSON schema → 父 / 全局定义 {code, message, data}，子 Skill 引用。

5. 控制示例数量（估省 10%+）
   四个超长示例 → 两个短而有代表性的。

改 Skill 时顺手扫一眼

• 合并重复指令
• 缩写不影响理解再用
• 写明输出长度 / 范围
• 非必要说明懒加载（真用到再给）
• 复杂任务拆多步 / 多 Skill，别做一个巨型 Prompt
• 改完前后对比效果，再迭代

和本仓写法怎么对上

落到个人博客或小型工具链也一样：主说明只写常用路径，细则另开附录；公共校验抽成一份复用，别每个技能各抄一遍；发文、校验、索引更新拆成独立能力，用到再串。这就是「聚焦单一能力 + 按需调用」的落地版。

写新 Skill 前先问三句：这段每次都会注入吗？能上提到父规则吗？这个示例删了模型还懂吗？

别踩的坑

• 「信息越全效果越好」在 Skill 里常常变成「上下文越胖、越贵、越好偏」。
• 拆 Skill 不是拆成碎片：边界要清，公共契约（输出格式、红线）要共享。
• 原文百分比未给测量条件；落地时用自己的前后 token 对比验收。

路径

坑：~/.claude/skills/md-polish/md-polish/SKILL.md 多套一层 → 发现不了。正确是 .../md-polish/SKILL.md。

同 Skill 兼 Claude / Codex 时，触发方式要分开写清（/ vs $SkillName 等）。

安装三条路

1. 手动拷完整 Skill 目录（最稳）
2. skills.sh / skillsmp：如 npx skills add https://github.com/anthropics/skills --skill frontend-design
3. Plugin marketplace（整包）

1
/plugin marketplace add anthropic-agent-skills
2
/plugin install document-skills@anthropic-agent-skills
3
/plugin search frontend anthropic-agent-skills
4
/plugin uninstall document-skills

SKILL.md 字段（常用）

挑别人 Skill 时看啥

最近是否维护、文档是否写清客户端、触发边界是否清楚。装完没反应：先查路径与文件名大小写，再查 description 是否跟你的话对得上。

相关阅读

• Cursor Skills：路径放错等于没装
• MCP、Skills、Plugin 不是三选一

素材来源：CSDN 原文

人墙比文档墙更贵

车间里常见戏码：厚 SOP 长蛛网；真正救人的是老师傅听异响、闻金属味、扫一眼报错码。
Skill 干的事，不是再写一本更厚的手册，而是把「老李会、别人不会」的口令，收成可调用的小步骤罐。

人墙不拆，Agent 再强也只会在门口排队。

模型像电，Skill 像电器

通用模型是插座里的电；公司偏好（编码习惯、排查口令、工单结构）是变压器；Skill 才是能稳定出活的电器。

没有偏好层，电再强也只是乱闪。护城河不在电表读数，在你家电器柜里有没有别人抄不走的偏好。

两类 Skill，别囤错货

「会用某模型的新功能」一年后可能作废；「我们遇到 E07 + 金属味先停机」不会跟风过期。

示例骨架：设备异常初判

把感官信号压成可执行卡，而不是散文 SOP：

• 输入：异响 + 金属味 + E07
• 动作：观察 → 预警 → 停机
• 升级：一周内同类三次 → 拉高一级处理

骨架够短，老师傅才愿意改；改完才能进罐。

作者甩出的几组数（先降温）

当「方向感」看可以；当 KPI 抄进自家 OKR 之前，先找原出处。

五招撬老师傅（心理战大于文档战）

1. 改不写：别逼从零写；他改比他写便宜一百倍
2. 被封神：口令抬成标准，不是「被掏空」
3. 挑顺风口人：先找愿意被看见的，别一上来硬刚最难搞的那位
4. 一把手保底：对外口径固定：augment ≠ replace
5. 只要 80% 可重复：剩下 20% 判断留在人手里

本周三件实事

1. 列出「离了某人就转不动」的事（人墙清单）
2. 先捞 → 草拟 → 他来改（真实过程进网，再出草稿）
3. 每条 Skill 配 1–3 组真实 I/O（输入信号 / 输出动作），空口令不要

跟旁边几篇怎么并排

同周库里已有「怎么写 Skill」「上下文预算」「团队十大 Skill」——那是写法 / 工程预算 / 清单选型。本篇是组织侧：隐性经验怎么进罐。旁链互指即可，不要合并成一篇大杂烩。

职业叙事向的 FDE 陪跑，另见 被裁了别开馆子。

文末「回复 Skill」领模板：私链不进库；留言区多是领福利，别当成验证证据。

三张榜各自吃哪口痛

先认能力与类别，再决定去哪找实现。名字好看不等于能 npx skills add。

17 件套：痛哪类拿哪类

一次装满没意义。痛哪类就从那类拿 1～2 个，跑通再加。

设计类里，Taste 偏从零 / 重做观感，Impeccable 偏命令面 + 页内点选改——别两个一起上来搅浑。审美深潜另有专帖，这里只记它在 17 件里站「审美入口」位。

效率类真正可复用的，往往不是再塞三个 skill，而是 Ponytail 那套写前五问：真需要写吗？库里有没有？标准库够不够？平台原生有没有？已有依赖能否一行解决？gh + Skill Creator 我认作地基：issue / PR / release 能在终端闭环，你自己还能造轮子。

数据类按需开抽屉。常爬网页再上 Firecrawl CLI；常要外部热点再上 Last 30 Days。GWS / Stripe / Supabase 按你是否真的碰 Workspace、收款、后端再决定。说不出「它替我省掉哪一步」，就卸。

Playwright 选型口诀：Agent 长会话里偶发点网页，MCP 可能更省事；批跑、脚本化、控成本，优先 CLI。

两张 Top10：能力备忘，不是安装清单

协作榜堵的是对齐乱、PR 说不清、老人带不动新人。按痛点裁：

自动化榜堵的是重复劳动。按段拆开看：

两张榜名单几乎不重叠。别当成同一表的续集，也别跟 17 件套逐条合并——切面不同。

差分一眼看完

撞名不等于可装。生态里能搜到能力相近的 Playwright / changelog / CI 修复类 skill，那是别的仓库、别的名字，不能偷换成「就是榜上这十个」。

我会怎么装

如果是我自己的机器，顺序大概是：

1. gh + Skill Creator（地基）
2. 痛 UI 再上 Taste 或 Impeccable 其中一个
3. 常爬网页再上 Firecrawl CLI；常要外部热点再上 Last 30 Days
4. Ponytail 当习惯补丁，数字当参考，五问当纪律
5. 团队侧先对照协作榜写清「我们缺哪段能力」，再去找可审仓库或自己写同名能力包
6. 自动化侧同理：先标重复劳动段落，再找可核实现

其余当工具抽屉。开了就要能说出替我省掉哪一步。

六件对照，对上你卡的那段

作者点名 Remotion「貌似目前最好用」——更准确的说法是：固定版式、要批量、能接受代码管时间轴时它强；口播去废话优先 video-use / videocut；纯文生视频提示词走 seedance2；要从 HTML 直接渲片走 HyperFrames。

能力落点，别混成一条河

1
想法 / 文案
2
  → seedance2（拆镜头提示词）或 Generative Media（直生媒）
3
成片素材（口播原片）
4
  → video-use / videocut-skills（粗剪）
5
栏目化、可复现版式
6
  → Remotion Skills（React 批产）
7
文章/推文 → 动效 MP4
8
  → HyperFrames

和本机栈怎么并排放

仓内 / 本机已有 video-use、firefly-minimax-media、story-to-handdrawn-video 等——这张清单是外部选型地图，不是替代安装说明。真要上某仓库，仍以其 README 的 skills 安装命令与密钥要求为准；Generative Media 类还要单独看付费后端。

白板手绘整条生产线（分镜·旁白·对角扫描渲染）另见 create-whiteboard-video。

别踩这些坑

• 信息图右下角卡片链接曾写错：seedance ≠ videocut。
• 「最好用」取决于任务：口播剪辑和数据周报不是同一条管线。
• 装了 Skill ≠ 免费无限生视频；生图/生片额度、ffmpeg、Remotion 工程环境都要自己备齐。

Taste：把「别出那张脸」写成可执行规则

Taste Skill（Leonxlnx，官网 tasteskill.dev，MIT）不是 UI 库、不是 CSS 框架、没有运行时。本质是一堆 SKILL.md：读 brief → 调旋钮 → 硬禁常见模板 → 起飞前自检。

默认安装名 design-taste-frontend，当前是 v2 experimental（要钉死旧行为就装 design-taste-frontend-v1）。骨架可以记成四段：

§0 Brief Inference——碰代码之前先读房间：页面种类、vibe 词、参考 URL/截图、受众、品牌资产、安静约束。输出一行 Design Read 再开干。brief 真含糊时只问一个澄清问题，不连环审问。

三旋钮（1～10）：

Baseline 8 / 6 / 4。覆盖靠对话，不靠让用户去改 skill 文件。

Hard Bans（节选）：默认紫蓝渐变 / Lila glow（品牌明确要紫另说）、100vh 居中 Hero 当万能开场、三等分等宽 Feature 墙、滥用 Inter、em-dash 当装饰、半截交付和假数据文案。

Pre-Flight：交付前大约 60 项自检。过不了就返工，不当「差不多」。体积提醒：单份 SKILL 大约 87KB / ~2 万 token——装了就会占上下文，不是免费午餐。

仓库里还有 image-to-code、redesign、图像 comps、brutalist 等十来个安装名。不必一次全装；默认一个 design-taste-frontend 往往就够起步。

落地页 / 作品集 / 营销站是主场。仪表盘、数据表、多步产品后台，官方自己划了「不是它的菜」。

四技网页线：先锚点，再旋钮，再审查

瑭宋元那篇「设计美化专题」把四技并排推。装机量、星数先当宣传数字看（作者称，本轮未核）。宿主兼容按作者口径：WorkBuddy / Codex / QoderWork / Trae。

网页线（推荐）：image-to-code → design-taste-frontend → web-design-guidelines。
先有视觉锚点，再拧品味，最后用 Vercel 规则钉到具体行。

漫画线：baoyu-comic 单独跑。它解决的是「知识怎么变成可翻页漫画」，跟落地页审美不是一条流水线。

安装命令（作者文内，本机未实测）：

1
curl -fsSL vercel.com/design/guidelines/install | bash
2
npx skills add Leonxlnx/taste-skill --skill design-taste-frontend
3
npx skills add jimliu/baoyu-skills --skill baoyu-comic

image-to-code 原文图卡没给独立一行安装命令；串进网页线时按你宿主里实际包名再补。

ui-styles：别只会喊「好看一点」

Ant Design 看腻了，跟 Agent 又只会喊「好看一点」——等于没给审美词条。ui-styles-skill 干的事很窄：把开源 UI 风格 Prompt 装进 Claude Code Skill，写前端时能点名风格（离线读本地 catalog）。

2026-08-11 核对：README 写 79 design styles × bilingual prompts；GitHub 显示 ★10；上游 Prompt 致谢 TonnyWong1052/UI-Prompt。封面图写 79、公众号正文常见 70+——以仓库 79 family 为准；其中 9 个只有 style.md（理解用），没有可直接生成代码的 custom.md。

能带走的用法：按场景筛候选；点名风格（如 claymorphism）再出页；两个风格名直接对比各自 style.md。作者例：出入库项目用 Shadcn/ui + Tailwind 做黏土风——风格词有了，组件库才是落地层，不是互斥。

三层怎么叠，别搅成一锅

推荐串法：先从 ui-styles 点风格名（或从参考图走 image-to-code），再用 Taste 收口，最后 guidelines 钉行号。漫画需求单独开 baoyu-comic，别跟网页三连搅。

适合谁，别硬套谁

适合：落地页、作品集、营销站、活动页；已经一眼模板的改版；想把审美判断沉淀成可复用 Agent 约束的人。

不太适合：后台表格、高密度仪表盘、多步产品工作台；brief 糊却指望旋钮救命；上下文很紧、不想喂进约 2 万 token 规则的会话；把 v2 experimental 当生产契约却拒绝回退到 v1。

作者声明（Taste）：没有官方代币 / 币 / 加密项目；蹭名发币的一律无关。

八个技能，各管一摊

三个最有分量的设计思路

① 重复劳动全部脚本化，还强制留证据。 cover 用 ffmpeg 本地预筛候选帧（清晰度+亮度+内容度硬过滤），模型只做”语义选帧”这一件事；motion 用 motion_budget.py 自动裁决交付格式；每次生成都留 prompt/analysis/manifest 三份 sidecar。把”哪些交给模型、哪些交给程序”划得干干净净：模型只做语义判断，程序只做确定性处理。

② 质量门禁不是口号，是显式步骤。 每个 skill 都有”不可违反清单 + 交付前自查”。ppt 有一长串阻塞项（HTML 结构损坏、文字溢出、远程资源、跨页 CSS 污染）；visual 要求 label 逐字符比对、禁止用独立文字层掩盖错误；html 有最小字号 14px、彩色不超过两色相这些硬指标。

③ 强触发约束，防止误用。 大部分 skill 要求”用户明确点名才启用”。html 甚至写明：你说”帮我做份 HTML”它都不会自动触发，必须点名 oil-html。这跟现在很多 skill 抢着自动触发正好相反。

几条值得抄的具体做法

• 文风当基建：tone 是所有内容 skill 共用的文案层，ppt/html/cover 都引用它。人称规则清晰（「我」讲自己、「我们」面向读者、「你」仅指导操作），还配了 tone_lint.py 自动查 AI 腔。
• 先生图后视频：motion 用”先生成首尾关键帧，再用 AI 视频补中间”，色键背景是硬门槛，插帧 48FPS，清晰度优先、体积其次。
• 先删后建：frontend 和 draw-ui 都强调”先删除无效内容再实现”，改前端前先明确真正出错的位置。
• 剪裁而非降级：ppt 拆页压缩只删冗余，不删事实、原因、影响、步骤。
• 透明素材分级：draw-ui 把小 logo 白底转 alpha，大插画走绿幕，不混装一张素材板。

这套体系的共同基因

读完 8 个 SKILL.md，能总结出五条贯穿始终的原则：

1. 忠于内容，不编造事实、不虚构来源
2. 产物只写最终态，不写 changelog
3. 一个含义只保留一个权威来源
4. 强触发约束防误用
5. 重复性工作脚本化 + sidecar 证据留痕

这套体系最大的价值不是某个 skill 多好用，而是它们共享同一套设计哲学——把「确定性」和「创造性」分层：程序守住边界，模型在边界内发挥。这正是我后续做个性化改造时要保持的骨架。