一个好 Skill 应解决重复工作，并写清触发条件、输入、步骤、验证和边界。项目级技能适合随仓库维护，个人技能适合本机通用习惯。
开始前先准备什么
先选择一个每周重复且结果可验收的流程，例如只读代码审查；不要把整个团队手册复制进去。
把流程拆成“何时触发、需要什么输入、按什么顺序做、输出什么、何时停止”五部分。若每次任务的输入和完成条件都不同，它可能更适合普通提示词；若规则需要长期随项目生效，也要先判断是否应该写项目规则。Skill 最适合有稳定步骤、可复用资料或脚本的专门任务。
先决定范围：随仓库协作的内容放项目级目录，个人通用习惯放用户级目录。项目子目录内的 Skill 会自动按所在目录限定范围；还可以用 frontmatter 的 paths 进一步限制匹配文件。
实际操作步骤
- 建立目录：在 .cursor/skills/review-change/ 下创建 SKILL.md；个人技能可放 ~/.cursor/skills/。文件名必须是
SKILL.md，一个技能放一个独立文件夹。 - 写 frontmatter：在 YAML frontmatter 中写准确 name 和 description；需要限定文件时使用 paths。name 使用小写字母、数字和连字符，并与父目录名一致。description 应同时说明做什么和何时使用。
- 写可执行正文：正文写输入、顺序步骤、允许工具、失败处理和输出格式，把长资料移到 references。需要脚本时放入 Skill 的
scripts/，并用相对 Skill 根目录的路径引用。 - 检查发现：打开 Customize → Skills 确认被发现；未出现时先核对目录、文件名和 YAML 格式，不要立即复制到多个目录。
- 做正反测试：分别运行一个应触发和一个不应触发的任务，检查 steps、文件范围和验证命令。自动生成的 Skill 也必须走这一步。
可复制的最小 SKILL.md
---
name: review-change
description: 审查前端改动的正确性与回归风险。用户要求审查 React 或 TypeScript 变更时使用。
paths:
- "**/*.tsx"
- "**/*.ts"
---
# Review Change
1. 读取当前 diff 和相关测试，不修改文件。
2. 按正确性、兼容性、可访问性检查具体问题。
3. 每个问题给出文件和行号；证据不足时写“无法确认”。
4. 运行仓库已有的只读检查命令；命令不存在时停止并说明。
5. 输出问题清单、已运行命令和未覆盖范围。这个示例把自动触发限制在 TypeScript/React 文件，并把“不要修改”和“证据不足如何处理”写进流程。实际项目应把测试命令、严重程度定义和允许范围改成自己的约定。不要在 SKILL.md 中写密码、访问令牌或生产地址。
怎样验证结果
通过标准是技能在目标文件范围可见、步骤被按序执行、验证命令真实运行，非目标任务不误触发。
正例可选一个只含 .tsx 改动的分支，要求只读审查；反例可选纯文档修改并发出一般编辑请求。检查 Customize 中的可见性、Agent 是否引用该 Skill、Git 状态是否保持不变，以及输出是否包含命令和未覆盖范围。若 description 太宽导致普通任务也触发，应先收紧描述或 paths，再重复两组测试。
常见错误
- description 过宽会导致误触发。
- 只写原则没有验证步骤，无法签收。
- 路径模式要在真实目录结构中测试。
适用边界
Skill 里的脚本会在用户环境执行；必须审查参数、权限和外部写入，不能保存密钥。
paths 控制 Skill 何时被展示给 Agent，不是操作系统级权限隔离。真正涉及文件、网络或命令的限制仍由运行环境、审批与沙箱负责。发布到团队前还应检查引用文件是否都被打包；官方插件文档说明，发布个人 Skill 时不会自动把它引用的其他 Skill 一并打包。
相关问答
可以用 /create-skill 自动生成吗？
可以作为起点，但生成后仍要人工核对触发范围、脚本和验收条件。
SKILL.md 应多长？
以完成流程所需信息为准；大段参考资料应拆出，减少无关上下文。
资料与适用范围
本文根据 2026 年 10 月 1 日核验的 官方资料 1、官方资料 2 整理。示例流程未在你的设备、账号或仓库中实测，界面、方案、权限和项目命令应以当前环境为准。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32610.html
