Cursor customization checklist: plugins, skills, MCPs, and automations

Do not treat Cursor's Customize page as a one-click team rollout surface. Plugins, skills, MCPs, subagents, rules, commands, hooks, and automations now sit close together, so the team needs a review map before anything becomes a default.

Choose The Scope First

Decide whether a customization belongs at user, workspace, or team level. Personal helpers can stay local; project rules belong with the workspace; team defaults need an owner, update path, and rollback plan.

Inspect The Package

A Cursor plugin can include a manifest, skills, rules, MCP server definitions, README, changelog, and license. Review the package contents before relying on a marketplace title or leaderboard position.

• Check the `.cursor-plugin/plugin.json` manifest.
• Review included `skills/`, `rules/`, hooks, and `mcp.json`.
• Prefer narrow packages with documentation, a maintainer, and a rollback path.

Separate MCP And Hooks

MCP servers change tool and data reach. Hooks observe or control the agent loop. Approve them separately, start read-only for new MCP tools, and require hooks to document trigger point, inputs, failures, and owner.

Review Automations Like Scheduled Agents

Cursor Automations can use `/automate`, Slack and GitHub triggers, PR-opening defaults, MCP auth, and computer use for cloud-agent demos. Before enabling one, name the trigger, output, tools, auth path, reviewer, and rollback switch.

Use Popularity As A Lead

Marketplace and leaderboard signals help prioritize review, but they are not proof that a package fits your workflow. Promote only when the customization solves a repeated job and has inspectable source or documentation.