Cursor Directory
开发者工具 / 开源项目
把分散在代码仓库中的 Cursor 社区插件整理成可搜索、可比较的发现入口。
产品和问题
Cursor Directory 的官方公开仓库把产品定义为 Cursor 社区插件目录，而不是一个泛化的 AI 工具榜单。插件可以包含规则、MCP、技能、代理、hooks 或语言服务等组成部分，目录把这些结构与对应代码仓库放到同一发现入口。
供给侧同样是产品的一部分。贡献者登录后提交 GitHub 仓库，站点自动识别仓库中可发布的组件，再把通过处理的插件呈现给使用者。目录因此连接的是“插件作者如何被发现”与“Cursor 用户如何减少筛选成本”两项任务。
实际工作流程
- 01使用者先从目录中的插件记录缩小候选范围，并进入对应详情或代码仓库核对组成。
- 02进入插件页核对它包含的规则、MCP、技能、代理、hooks 或语言服务，以及对应代码仓库。
- 03根据自己的 Cursor 工作流选择并安装合适组件，实际使用前仍需审查代码、权限与维护状态。
- 04贡献者则通过 GitHub 或 Google 登录，粘贴公开仓库地址，让站点检测可发布组件并提交到目录。
为什么这条路径可能成立
插件能力散落在不同仓库时，用户需要先知道准确项目名才能找到它。统一元数据、搜索与排序把发现入口前移，使用户可以从任务出发比较候选项。
提交流程直接读取仓库结构，降低作者重复填写多套目录字段的成本。目录能否持续有价值，仍取决于插件供给、审核质量和搜索结果是否跟得上 Cursor 生态变化。
CASE-SPECIFIC TAKEAWAYS
Vibe Coder 可以从这个案例学什么
01
目录价值来自缩短选择，不来自条目数量
Cursor Directory 把插件组成和代码仓库放到同一入口，让用户从任务出发比较候选。做目录产品时，应先设计用户如何排除不合适选项，而不是把收录数量当作唯一进度。
02
让供给方提交已有资产
贡献者提交 GitHub 仓库，站点再检测可发布组件。双边产品的早期供给流程可以复用作者已经维护的数据源，减少重复填写和冷启动成本。
03
收录和安全背书必须分开
目录能帮助发现，却不能自动证明插件安全、兼容或持续维护。面向代码与 agent 生态的产品，应让仓库、权限和维护状态可继续核对，并清楚标明审核边界。
限制与不确定性
目录收录不等于本站对插件安全、兼容性或维护质量的背书。使用者仍需审查仓库内容、权限、维护状态和与本地环境的兼容性。
Cursor Directory 主站在本次匿名浏览器复核中触发 Vercel Security Checkpoint，因此本页不再使用主站动态人数、导航、职位、企业收费或历史经营数字，只保留可匿名读取的官方公开仓库所能支持的范围。
基础信息
- 当前产品形态
- Cursor 社区插件的搜索、排序、详情与仓库提交目录
- 目录对象
- 可包含 rules、MCP、skills、agents、hooks 与 LSP 的社区插件
- 供给入口
- 贡献者登录后提交 GitHub 仓库，由站点检测可发布组件
- 结果口径
- 不展示受安全检查页面限制或缺少明确口径的动态人数与经营数字
结论与依据
这里区分公开事实、公开自述、媒体转述与本站分析；只显示已经绑定可点击公开来源的结论。
Cursor Directory 提供 Cursor 社区插件的发现和提交入口。
公开资料直接证实贡献者可以登录、提交 GitHub 仓库并让站点自动检测可发布组件。
公开资料直接证实统一目录可能降低从任务到候选插件的发现成本。
本站编辑分析
公开来源
以下公开页面用于核对本页所列产品事实与历史披露，不表示本站与来源方存在合作关系。少数官网可能要求浏览器完成安全验证。
- Cursor Community Plugins Repository（在新窗口打开）
Cursor Directory · 官方产品页面 · GitHub · 访问 2026-07-26
访问状态：匿名可读，HTTP 200，无登录墙
支持事实：社区插件目录的公开仓库、提交步骤，以及自动检测 rules、MCP、skills、agents、hooks 和 LSP 的说明。