Skill 创建方法论（通用型）

要解决什么问题

在 Agent 场景里，Skill 往往靠「写一段很长的 system prompt」或零散笔记凑出来：边界不清、触发条件含糊、和工具/MCP 的职责重叠，后续一改就牵一大片。更麻烦的是，不同项目里的 SKILL.md 结构各写各的，评审和复用都成本高。

「Skill 创建方法论（通用型）」针对的是如何把「做一个 Skill」当成可重复的工程活动，而不是一次性的文案任务。它不绑定某个业务域，适合你在新建或重构技能时，先对齐「写什么、不写什么」。

技能如何工作

从定位上看，这是一套面向 Skill authoring 的通用框架，核心是把创建过程拆成可检查的决策点，而不是直接替你生成业务内容。典型会覆盖这些层面：

• 目标与触发：什么用户意图应该加载这份技能；与默认模型行为、其它技能的边界怎么划。
• 文档结构：SKILL.md 里哪些章节是「契约」（必须稳定），哪些是示例；如何用列表、小标题和 行内代码 让执行端一致解析。
• 约束与反模式：哪些能力应交给工具、哪些必须写在技能里；如何避免把安装说明、营销话术混进执行指令。
• 迭代方式：小步修改时如何保持「单一职责」，避免一个技能变成万能手册。

把它当作方法论型技能使用时，模型会按其中的步骤与检查清单引导你澄清需求、落稿、再收窄范围，而不是跳过设计直接堆字数。

适用边界与注意点

• 通用 ≠ 万能：它解决的是「怎么写技能」，不会替代领域专家知识；垂直场景仍需你自己补业务规则与样例。
• 与平台规范对齐：不同分发渠道（如 SkillHub、各 IDE 插件）对 frontmatter、命名可能有额外要求，方法论层的内容需要和你目标平台的安装/引用方式一起核对。
• 适合作为元技能：更适合放在「新建技能」「评审 SKILL.md」「拆分过大技能」这类对话里加载；日常单次问答不必常驻。

若你已经在团队里有一套固定的 Skill 模板，可以把本技能当作对齐评审语言的参考，再合并进自己的规范。