方法论
创作方法论
如何写出一份高质量、AI 能稳定执行的 Skill。
核心原则：具体，不是聪明
Skill 不需要华丽的词汇或技术术语。好的 Skill 只有一个标准：AI 读完就能准确地执行，不猜、不发挥、不跑偏。
推荐写法
「检查每个 API 端点是否包含参数校验，缺失的列出文件路径和行号」
不推荐写法
「帮我检查代码质量」——太模糊，AI 不知道你到底要什么
先想清楚：你的 Skill 是哪种
参考知识类
注入项目规范、编码标准、团队约定。AI 在工作时自动引用，确保输出符合团队标准。
例：API 命名规范、数据库设计约定、文案风格指南、部署流程
任务流程类
定义从输入到输出的完整执行步骤。手动调用 /name，AI 严格按流程走。
例：PR 审查、部署检查、提交信息生成、测试用例编写
三个关键部分
description — 让 AI 知道什么时候用它
AI 根据 description 判断当前场景是否该加载这个 Skill。写清楚触发条件，别写成产品简介。好的：「当用户请求审查 PR 或检查代码变更时使用」。差的：「这是一个好用的 PR 审查工具」。
指令内容 — 告诉 AI 具体怎么做
步骤要具体、可执行。每一条 AI 读完都应该知道下一步该干什么。用「检查」「列出」「输出」「对比」这种动作性强的词，避免「注意」「应该」「可以考虑」这种模糊词。
输出格式 — 明确产出的样子
如果对输出有格式要求，直接写出来或给一个示例。比如「以 Markdown 表格输出，列名：文件路径 | 问题类型 | 建议」。AI 模仿示例的能力远比理解抽象描述强。
常见误区
描述太模糊
例：「帮助提高代码质量」
写清楚具体检查什么：「检查代码中缺少错误处理的地方，列出文件和行号」
包含太多不相关内容
例：「审查 PR + 写文档 + 部署 + 写测试」
一个 Skill 只做一件事。多个任务拆成多个 Skill，各自独立调用
描述写成营销文案
例：description 写成「强大的代码审查工具，提升团队效率」
description 写触发条件：「当用户请求 PR 审查或检查代码变更时使用」
没有明确的输出要求
例：「检查完毕后给出建议」
指定输出格式：「以表格形式列出：问题类型 | 严重程度 | 所在位置 | 修改建议」