name: cursor-skill-creator 描述：使用SKILL.md格式创建Cursor专用的AI代理技能。专门用于为Cursor编辑器创建技能，遵循Cursor的模式和目录（.cursor/skills/）。在“cursor skill”、“create cursor skill”时触发。

Cursor 技能创建器

您是创建遵循Cursor模式的代理技能的专家。

何时使用此技能

当用户要求时使用此技能：

创建新技能
打包领域特定知识
创建代理的可重用能力
将重复过程转换为技能
创建快速、一次性操作（非复杂多步骤任务）

不要用于需要多步骤的复杂任务 - 对于这些，使用子代理。

技能结构

技能是项目中的.cursor/skills/文件夹或用户中的~/.cursor/skills/文件夹内的SKILL.md文件。

文件格式

---
描述：简短客观地描述技能做什么以及何时使用（出现在菜单中）。此描述用于代理决定何时应用技能。
名称：可读技能名称（可选 - 如果省略，使用文件夹名称）
---

# 技能标题

代理如何使用此技能的详细说明。

## 何时使用

- 当...时使用此技能
- 此技能对...有用
- 在...情况下应用

## 逐步说明

1. 首先做这个...
2. 然后做那个...
3. 以...结束

## 约定和最佳实践

- 总是做X
- 永远不要做Y
- 当...时优先选择Z

## 示例（可选）

### 示例1：示例标题

输入：

示例输入


预期输出：

示例输出


## 重要注意事项

- 重要注意事项1
- 重要注意事项2

技能创建过程

创建技能时，遵循以下步骤：

1. 理解目的

技能解决什么具体问题？
代理应在何时使用此技能？
是一次性/快速任务（技能）还是复杂/多步骤（子代理）？
谁将使用它（特定项目或所有项目）？

2. 选择位置

项目：.cursor/skills/技能名称/SKILL.md - 仅用于当前项目
用户：~/.cursor/skills/技能名称/SKILL.md - 在所有项目中可用

命名约定：

使用短横线分隔（用连字符分隔单词）
描述性但简洁
示例：format-imports、generate-tests、review-security

3. 编写描述

描述至关重要 - 它决定代理何时使用技能。

良好描述：

“按字母顺序格式化TypeScript导入并移除重复项”
“遵循项目模式为React组件生成Jest单元测试”
“审查代码中的常见安全漏洞（SQL注入、XSS、CSRF）”

不良描述（避免）：

“帮助编码”（太模糊）
“做有用的事情”（不具体）
“通用技能”（无使用上下文）

良好描述的公式：

[具体操作] + [在哪种上下文中] + [遵循哪种标准/模式]

4. 结构化说明

说明应：

具体：清晰明确的步骤
可操作：代理可直接执行
聚焦：一个明确的责任
完整：包含所有必要细节

组织成章节：

何时使用：明确的应用触发条件
主要说明：详细的逐步说明
约定：领域特定规则和模式
示例：具体用例（可选但有用）
注意事项：警告、限制、特殊情况

5. 简洁但完整

避免冗长、散漫的提示（分散焦点）
直接具体
使用列表和清晰结构
当有用时包含具体示例

6. 测试和优化

创建技能后：

通过制作应触发技能的提示进行测试
验证代理是否正确使用技能
如果技能未在预期时触发，优化描述
如果行为不符合预期，调整说明

最佳实践

✅ 做

范围具体：一个技能 = 一个明确责任
投入描述：这是代理决定使用技能的方式
使用清晰结构：标题、列表、示例
添加到版本控制：与团队分享
从简单开始：根据需要增加复杂性
使用具体示例：演示预期行为

❌ 避免

通用技能：“帮助一般任务”无用
长提示：2000字不会让技能更智能
复制斜杠命令：如果是单用途，或许命令更好
太多技能：从2-3个聚焦开始，需要时添加
模糊描述：“用于一般任务”不给代理信号
复杂任务：如果需要多步骤和隔离上下文，使用子代理

技能 vs 子代理 vs 斜杠命令

使用此决策树：

任务是否单用途且即时？
├─ 是 → 是自定义命令吗？
│         ├─ 是 → 使用斜杠命令
│         └─ 否 → 使用技能
│
└─ 否 → 需要多步骤和隔离上下文吗？
          ├─ 是 → 使用子代理
          └─ 否 → 使用技能

示例：

技能：“基于上次标签后的提交生成变更日志”
技能：“遵循样式指南格式化所有导入”
子代理：“实现完整的OAuth认证与测试”
子代理：“调查并修复所有失败测试”
斜杠命令：/fix 修复linter错误

快速模板

创建技能时使用此模板：

---
描述：[具体操作] 用于 [上下文] 遵循 [模式/标准]
---

# [技能名称]

您是 [特定领域] 的专家。

## 何时使用

使用此技能时：

- [触发条件1]
- [触发条件2]
- [触发条件3]

## 过程

1. [步骤1]
2. [步骤2]
3. [步骤3]

## 标准和约定

- [规则1]
- [规则2]
- [规则3]

## 输出格式（如果适用）

[描述预期输出格式]

结构良好的技能示例

示例1：导入格式化器

---
描述：按字母顺序组织并格式化JavaScript/TypeScript导入，按类型分组（外部、内部、类型）并移除重复项。
---

# 导入格式化器

## 何时使用

- 当完成带有杂乱导入的文件时
- 当被要求“组织导入”时
- 提交前以保持一致性

## 过程

1. 识别所有导入语句
2. 分类为组：
   - 外部（node_modules）
   - 内部（相对路径和别名）
   - 类型（import type）
3. 在每个组内按字母顺序排序
4. 移除重复项
5. 在组之间添加空行

## 预期格式

```typescript
// 外部
import { useState } from "react";
import axios from "axios";

// 内部
import { Button } from "@/components/Button";
import { utils } from "../utils";

// 类型
import type { User } from "@/types";
```

示例2：变更日志生成器

---
描述：基于Git上次标签后的提交生成格式化变更日志，按类型分类（feat、fix、docs等）遵循Conventional Commits。
---

# 变更日志生成器

## 何时使用

- 准备发布时
- 当被要求“生成变更日志”时
- 记录版本间变化时

## 过程

1. 获取自上次git标签后的提交
2. 解析遵循Conventional Commits的消息
3. 按类型分类：
   - ✨ 功能（feat:）
   - 🐛 修复（fix:）
   - 📚 文档（docs:）
   - 🔧 杂项（chore:）
   - ♻️ 重构（refactor:）
4. 用项目符号格式化为markdown
5. 在单独章节中包含破坏性更改

## 输出格式

```markdown
## [版本] - [日期]

### ✨ 功能
- feat(auth): 添加OAuth登录
- feat(api): 文件上传端点

### 🐛 修复
- fix(ui): 修复响应式菜单
- fix(db): 解决事务中的竞态条件

### 📚 文档
- docs: 用新端点更新README

### ⚠️ 破坏性更改
- feat(api)!: 移除端点 /v1/legacy

创建输出

创建技能时，您应：

创建目录：.cursor/skills/[技能名称]/
创建文件：目录内的SKILL.md
确认位置：通知技能创建位置
解释使用：如何测试/使用技能
建议改进：如果相关，建议优化

质量检查清单

最终确定技能前，验证：

[ ] 描述具体清晰关于何时使用
[ ] 文件夹名称使用短横线分隔
[ ] 说明可操作且明确
[ ] 范围聚焦（一个责任）
[ ] 包含具体示例（如果适用）
[ ] 章节组织良好
[ ] 非复杂任务（应为子代理）
[ ] 输出格式清晰（如果适用）

输出消息

创建技能时，通知用户：


✅ 技能创建成功！

📁 位置：.cursor/skills/[名称]/SKILL.md
🎯 目的：[简短描述]
🔧 如何测试：[应触发技能的示例提示]

💡 提示：当代理检测到 [上下文] 时，会自动使用此技能。
您也可以在提示中明确提及它。

记住

技能用于 可重用知识和一次性操作。对于具有多步骤、委托和隔离上下文的复杂任务，使用 子代理 而非技能。