Skill 写不好？是因为缺了这套结构化方法论

你有没有这种感觉——给 AI 写提示词像在掷骰子，同一个需求这次效果好、下次就翻车？

问题的根源不在提示词本身，而在于缺一套结构。

skill-authoring 这个 Skill，做的就是这件事：教你从零搭一个真正能复用的 Agent Skill。

它解决什么问题

市面上的 AI 教程，十篇有九篇在讲「怎么问」，但很少有人讲「怎么把好方法固化成 Skill」。

skill-authoring 来自 pproenca/dot-skills 这个仓库，里面有 190 多个细粒度 Skill，覆盖 Vite、React、Pulumi、CLI 设计几乎所有主流技术栈。skill-authoring 是它们的元技能——专门教你怎么写 Skill 本身。

核心内容是什么

这个 Skill 给了你一整套写 Skill 的方法论，归纳成几条关键原则：

前置指令优先。 Claude 有时会截断长内容，非核心规则放后面会被直接忽略。所以要把最关键的约束放在前 100 行。

渐进式加载。 不要把所有东西都塞进 SKILL.md，详情放 references/，需要时才调入。2000 行的 Skill 每次激活都烧 Token，浪费。

测试触发，而不是测试执行。 一个 Skill 再完美，激活条件写得不对就永远不会被调用。真正有用的是用真实用户的说法去测试同义词和边界情况。

一个 Skill 只攻一个领域。 边界重叠会引发激活冲突，分清楚再用。

实际怎么用

安装只需要一行命令：

npx skills add https://github.com/pproenca/dot-skills --skill skill-authoring

装完跟 AI 说「帮我写一个做 Code Review 的 Skill」，它就会按 skill-authoring 的框架输出：SKILL.md、触发词定义、allowed-tools 配置，一套完整的结构。

谁适合用

想搭建内部 Skill 库的团队——把专家经验固化成可复用的 Skill，比写文档更直接，比口口相传更稳定。

工具类开发者——如果你做的 CLI 或框架想被 AI Agent 调用，skill-authoring 里有 45 条「Agent 友好 CLI 设计规则」，照着改就行。

AI 工具重度用户——与其每次重新描述需求，不如花一次时间写一个专属 Skill，之后同类任务一键激活。

GitHub 地址收好：https://github.com/pproenca/dot-skills

仓库本身 197 Star，skill-authoring 这个 Skill 在 skill.sh 上有 282 次安装，最近更新 2026 年 8 月 15 日，还是热乎的。写 Skill 这件事终于有章可循了。

GitHub: https://github.com/pproenca/dot-skills