Cursor中使用Skills

0 确认Cursor版本

Cursor 2.4版本以上

1 选择 Skills 放置位置

项目级

• 跟仓库走，便于版本控制
• /.cursor/skills//SKILL.md

全局

• Linux：~/.cursor/skills/<skill-name>/SKILL.md

文件夹名建议只用 小写字母 / 数字 / 连字符，并且 frontmatter 的 name 必须与文件夹名一致。

2 Skill#1 阅读代码并输出技术总结报告

2.1 创建目录

仓库：/.cursor/skills/tech-summary-report/SKILL.md

2.2 SKILL.md

---
name: tech-summary-report
description: 阅读项目代码并生成技术总结报告（架构/模块/数据流/依赖/构建测试/风险点）。当用户提出“总结项目/梳理架构/技术报告/代码讲解/项目概览”时使用。
disable-model-invocation: true
---

# 技术总结报告（Tech Summary Report）

## 目标
对当前仓库做代码阅读与结构化总结，产出一份可复用的技术报告（Markdown），面向工程协作与后续开发。

## 输出要求（必须）
- 报告文件：优先写入 `docs/TECH_SUMMARY.md`（若无 docs/ 则写 `TECH_SUMMARY.md`）
- 报告结构固定如下（不要省略章节）：
  1) 项目一句话概览（做什么、核心价值）
  2) 运行方式（如何 build / run / test，关键命令与入口）
  3) 架构总览（分层/组件图的文字版）
  4) 关键模块与职责（按目录/包划分）
  5) 核心数据结构与数据流（从输入到输出的链路）
  6) 关键依赖与外部集成（DB、消息、第三方服务、模型等）
  7) 可扩展点与常见修改入口（新增功能通常改哪里）
  8) 风险与技术债（耦合点、隐患、性能/安全/测试缺口）
  9) 建议的后续工作（短期/中期）

## 阅读策略（必须按顺序执行）
1. 先读“项目导航类”文件：README、docs/、package/build 配置、启动入口、CI 配置。
2. 找到**主入口**（例如 main、app、server、训练/推理入口等），画出调用链。
3. 自上而下梳理目录：每个一级目录一句话职责；识别边界（API 层/业务层/数据层/基础设施层）。
4. 对关键链路做“抽样深读”：只深读最关键的 20% 文件，避免无差别展开导致上下文爆炸。
5. 结尾输出报告并在 Chat 中给出：
   - 报告位置
   - 你读过的关键文件清单（10~30 个）
   - 你认为最关键的 3 个结论

## 交互规则
- 若仓库很大或需求含糊，允许使用“ask question tool”提出**最多 3 个**澄清问题（例如：希望总结偏工程、偏算法、偏部署？）。
- 未经用户明确要求，不要做大规模重构；本 skill 只负责阅读与总结。

说明：这里加了 disable-model-invocation: true，这样更像“手动触发的 slash 命令”，避免 agent 自动乱套用。该字段与“手动调用更适合”在 Cursor 社区用法里被提到。

3 Skill#2 按指定需求完成代码修改

3.1 创建项目目录

仓库：/.cursor/skills/implement-requirement/SKILL.md

3.2 SKILL.md

---
name: implement-requirement
description: 按用户给定需求做代码修改：先定位相关模块与影响面，给出改动计划，再实现最小改动并运行测试，最后总结变更与风险。用户提出“实现需求/修bug/加功能/重构一小块/改接口”时使用。
disable-model-invocation: true
---

# 实现指定需求（Implement Requirement）

## 总体原则（必须遵守）
- 先计划后改代码：先输出计划（影响文件、数据流、接口、测试点），再开始编辑。
- 最小改动：优先局部修改，避免“顺手重构”。
- 可验证：必须给出如何验证（单测/集成测试/手动步骤）。
- 变更可追踪：最后列出修改过的文件与关键 diff 点。

## 执行流程（固定步骤）
1) 需求结构化
- 将用户输入整理成：
  - 背景/问题
  - 目标行为（期望）
  - 非目标（不做什么）
  - 约束（性能/兼容/风格/依赖）
  - 验收标准（可执行、可检查）

2) 定位与影响面分析
- 查找相关入口与关键调用链
- 明确会影响哪些模块/接口/配置
- 如果存在多方案，给出 2~3 个方案对比（复杂度/风险/工期）

3) 实施计划（必须在改代码前发出）
- 文件级改动清单
- 每一步要改什么、为什么
- 对应的验证方式（跑哪些命令/看哪些日志）

4) 实现
- 分步骤编辑
- 每一步后用简短文字说明“改了什么、保证了什么不变”

5) 验证
- 运行项目已有测试/脚本（优先使用仓库现有命令）
- 若无法运行（缺环境/依赖），给出替代的最小验证与后续建议

6) 交付总结（必须）
- 变更点摘要（按文件）
- 风险点与回滚方式
- 未覆盖的边界情况（如果有）

## 交互规则
- 若验收标准缺失或需求歧义，允许使用“ask question tool”提出**最多 3 个**澄清问题再继续。:contentReference[oaicite:6]{index=6}

4 Cursor识别Skills

• File -> Preferences -> Cursor Settings
• Rules, Skills, Subagents
• Skills 下会出现在两个刚加上的skills

5 调用Skills

5.1 Skill#1

• 在agent chat中输入：/tech-summary-report
• 补充你希望报告偏重的点
• 可以加入文件范围或让其重点解释训练/推理部分

5.2 Skill#2

• 在agent chat中输入：/implement-requirement

• 加入需求：

• 期望的行为

• 约束

• 验收的方式

• 改进的代码部分

6 加入Rules

• 全局基础规则（Always Apply）
• 总结报告规则（Apply Intelligently 或 Manual）
• 改代码工作流规则（Apply Intelligently 或 Manual）
• /.cursor/rules/