装不上是因为你用了文件夹名：taste-skill 十三个 skill 的 install name 对照
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
你在 GitHub 上看到 skills/soft-skill/，于是写下 --skill "soft-skill"——这条命令里的名字是错的。README 明确说过，--skill 后面要填的是 SKILL.md frontmatter 里的 name: 字段，也就是 install name；soft-skill 是文件夹名，它对应的 install name 是 high-end-visual-design。这个仓库里十三个 skill，有十个两者对不上。
一、先把两个名字分开
taste-skill 的安装入口只有一条命令，README 给的是：
npx skills add https://github.com/Leonxlnx/taste-skill
不带任何参数时，这条命令会扫描仓库的 skills/ 目录，把下面的 skill 都发现出来——README 的 FAQ 里专门解释过，图像生成类 skill 之所以也能用同一条命令装，就是因为它们和代码类 skill 同在 skills/ 下。这条路径上你根本用不到名字，所以也踩不到坑。
坑在于「只装其中一个」。README 给的写法是：
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
注意 design-taste-frontend 这个字符串。它对应的文件夹叫 taste-skill。也就是说，连仓库里最默认、最主推的那一个 skill，都不是照着目录名填的。
README 把 install name 定义得很清楚：它是 SKILL.md frontmatter 里的 name: 字段。文件夹名只是仓库作者组织文件的方式，CLI 认的是 frontmatter。这两件事在很多仓库里恰好重合，所以人容易默认它们总是一样的；在这个仓库里它们大面积不重合。
二、十三行里有十行对不上
我们把 skills/ 下十三个 skill 的文件夹名和 install name 并排列出来，只做名字对照，不谈各自适合什么场景——挑哪个用是另一件事，我们另有一篇专门讲：
| 文件夹名（你在 GitHub 上看到的） | install name（--skill 要填的） | 是否一致 |
|---|---|---|
taste-skill | design-taste-frontend | 否 |
taste-skill-v1 | design-taste-frontend-v1 | 否 |
gpt-tasteskill | gpt-taste | 否 |
image-to-code-skill | image-to-code | 否 |
redesign-skill | redesign-existing-projects | 否 |
soft-skill | high-end-visual-design | 否 |
output-skill | full-output-enforcement | 否 |
minimalist-skill | minimalist-ui | 否 |
brutalist-skill | industrial-brutalist-ui | 否 |
stitch-skill | stitch-design-taste | 否 |
imagegen-frontend-web | imagegen-frontend-web | 是 |
imagegen-frontend-mobile | imagegen-frontend-mobile | 是 |
brandkit | brandkit | 是 |
十行不一致，三行一致。而且一致的那三行全部落在图像生成类 skill 上，代码实现类的十个里没有一个同名。这个分布意味着一件事：你越是奔着写代码去装，越容易填错。
三、为什么不能靠「去掉 -skill 后缀」猜
看到十个文件夹里大多带 -skill 后缀，很多人第一反应是「那把后缀去掉不就是 install name 吗」。这个规律在这张表上只成立一次。
十处不一致里，只有 image-to-code-skill → image-to-code 是单纯去掉 -skill 后缀就能得到的。其余九处都改了词：
minimalist-skill→minimalist-ui、brutalist-skill→industrial-brutalist-ui：后缀换成了-ui，后者还加了industrial-前缀soft-skill→high-end-visual-design、output-skill→full-output-enforcement、redesign-skill→redesign-existing-projects：install name 完全是另一组词，和文件夹名没有共同词根taste-skill→design-taste-frontend、taste-skill-v1→design-taste-frontend-v1、stitch-skill→stitch-design-taste：词序和词都变了，taste这个词根还在，但位置和前后搭配全换了gpt-tasteskill→gpt-taste：文件夹名里tasteskill是连写的，没有连字符可去
所以这里没有可依赖的规律。**任何「按规律推」的做法在这个仓库都会有九次翻车机会。**唯一可靠的做法是回去查 frontmatter，或者查对照表。
顺带提醒一个高频场景：想把默认 skill 钉死在旧版本时，README 给的是 --skill "design-taste-frontend-v1"，而不是文件夹名 taste-skill-v1。这一条容易被写进升级/回滚脚本里长期躺着，所以填错的成本比一次性手敲命令高。v1 与 v2 之间怎么升、怎么退，我们另有一篇专门讲。
四、怀疑填错了，按这三步自查
第一步，确认你手上的字符串是从哪儿抄来的。 如果它来自 GitHub 仓库页面的目录列表、或者来自你自己对文件路径的记忆，那它就是文件夹名，先默认它是错的。
第二步，打开 skills/<那个文件夹名>/SKILL.md，看 frontmatter 的 name: 字段。 这是 README 给出的定义本身，不需要任何推断：name: 后面写的是什么，--skill 就填什么。逐字复制，不要顺手改写大小写或连字符。
第三步，比对。 把 frontmatter 里的值和你命令里 --skill 后面的字符串放在一起逐字看。这一步能覆盖上面那张表里的全部十行。
关于「装完怎么验证」，这里要说句实在话：README 没有写 npx skills add 会把内容落到哪个目录，也没有给列出已装 skill 的命令，我们也没有跑过这条命令，所以我们给不出一个有仓库依据的验证动作——网上别处给的安装目录路径，我们没法替它背书，别照抄。
真正有仓库依据的替代路径有两条，README 都写了：一是直接把某份 SKILL.md 复制进你自己的项目，二是把它整个粘进 ChatGPT / Codex 的对话里。这两条路完全绕开了 CLI 和 install name 这一环。如果你只是想先看看某个 skill 到底约束了什么，走复制这条路反而更快，也不会卡在名字上。
五、什么情况说明问题不出在名字上
这一节比前面几节更重要，因为把不相干的故障归到名字上，会让你一直改一个本来就没错的字符串。
你填的是那三个同名的 skill。 brandkit、imagegen-frontend-web、imagegen-frontend-mobile 这三个的文件夹名和 install name 本来就一样，填哪个都一样。这时候还失败，原因一定在别处。
你根本没带 --skill。 不带这个参数时命令扫的是整个 skills/ 目录，压根不解析名字。
报错来自 CLI 或 npx 本身。 npx skills add 这个 CLI 不是 taste-skill 仓库的代码，它指向的是 https://github.com/vercel-labs/agent-skills。taste-skill 的 README 没有收录它的错误码和排错说明，所以命令本身跑不起来（而不是「找不到这个 skill」）的时候，该去看的是那个 CLI 的文档，不是这张对照表。
大小写这一项，我们不下结论。 README 示例里的 install name 全是小写，但匹配是否大小写敏感，README 没写、我们也没跑过，不推断。可以说的是：这个仓库里大小写本来就不统一——.claude-plugin/plugin.json 的 homepage 和 repository 都写成 https://github.com/leonxlnx/taste-skill（小写 l），与仓库实际路径 Leonxlnx 不一致。两处写法不同，以仓库当前状态为准。既然仓库里已经存在这种差异，逐字复制 frontmatter 里的值总比自己改写安全。
六、还有第三种名字，别把它当 install name
翻 .claude-plugin/ 的时候你会看到第三种叫法：plugin.json 里 name 是 taste-skill，version 是 1.0.0，license 是 MIT，keywords 是 ["skills","frontend","design","taste","ui"]；marketplace.json 把自己描述成 “Taste skill library for Claude Code”，plugins 数组只有一项，source 是 "./"，version 同样 1.0.0。
这里的 taste-skill 指的是整个插件包，不是那个默认 skill。默认 skill 的 install name 是 design-taste-frontend，而它所在的文件夹恰好也叫 taste-skill——同一个字符串在这个仓库里同时是插件包名和一个文件夹名，唯独不是任何一个 install name。你如果拿它去填 --skill，填的就是文件夹名那条错路。
七、名字填对了，别指望它自动生效
最后交代一句这些 skill 的性质，因为它决定了你装对之后该抱什么期待。
这个仓库里没有 src/、没有构建产物、没有运行时，核心资产就是 skills/ 下的十三份 SKILL.md——纯 Markdown。所以 install name 填对、skill 装进去之后，被改变的是模型读到的提示词上下文，不是你项目里的任何一道校验。SKILL.md 里写的每一条都是给模型看的指令，不是 lint 规则，不是 CI 检查。「禁止某个写法」是一条要求，不等于「装了之后就不会出现那个写法」。
判断依据也就清楚了：如果你要的是确定性保障，该在自己的构建链里加检查，skill 只是前置的倾向调节；如果你的痛点是模型每次生成的界面都是一个模子，那这类规则文档是直接冲着这个问题去的。项目方自己也留了余地——默认 skill 自标 v2 (experimental)，README 原文说 “It is still iterating”。
八、一句话收尾
--skill 后面填的是 frontmatter 的 name:，不是目录名；十三个里十个对不上，其中九个连规律都没有。记不住就存一份对照表，或者干脆不带 --skill 装整个仓库。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。
许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。