Create a Cursor Plugin You Can Install

Rajkumar Samra’s How to Create a Cursor Plugin: Context Engineering You Can Install is a developer post about packaging working context for Cursor, Anysphere’s AI code editor. It deals with a familiar problem: rules, skills, agents, MCP servers, and hooks often start as helpful snippets, then drift apart. The takeaway is that a plugin can make context installable, reviewable, and easier to keep lean. A Cursor plugin is a bundle that can ship cursor rules, skills, agent definitions, hooks, and cursor mcp configuration as one reusable unit.

Start with the bundle, not the prompt

The interesting part of Samra’s post is not that Cursor has another customization surface. It is the shape of the package.

The post, which surfaced on Hacker News on August 17, 2026, describes plugins as a way to ship several pieces of agent behavior together: rules, skills, agents, MCP, and hooks. That is a more honest unit than a prompt pasted into chat.

A prompt is easy to copy and hard to maintain. A plugin can carry the rule that says when something applies, the skill that explains how to do the task, the hook that checks the boundary, and the MCP connection that fetches outside context.

The trap is treating a plugin as a bigger prompt. If every rule is always-on and every skill reads like a handbook, the agent gets slower and less precise. The better move is to install only the context that has a job.

That same pressure is showing up across code-agent ecosystems. When a project like Continue changes shape, as covered in Continue Is Archived: What Replaces It, the durable lesson is not vendor trivia. It is that context needs a portable home.

Make activation narrow enough to trust

A good plugin does not dump every convention into the agent’s window. It gives Cursor small handles it can activate at the right time.

For a real repo, that usually means three layers. Keep durable repository boundaries in AGENTS.md or scoped Cursor rules. Put repeatable workflows in Cursor skills. Use cursor subagents only when a job needs a separate role, such as release-note writing, migration review, or API-contract checking.

Here is a useful boundary for a payments service:

---
description: Keep edits inside the payments service unless the user asks for a wider change
globs:
  - "services/payments/**"
alwaysApply: false
---

When working in services/payments, prefer local adapters over shared-core edits.
Do not change billing schemas without calling out the migration impact.
If a change touches services/ledger, stop and ask whether the task is cross-service.

That rule is short on purpose. It gives Cursor a boundary, not a lecture.

The trap is writing rules that sound wise but do not change behavior. “Write clean code” is not context. “Do not change billing schemas without calling out migration impact” is context.

For more examples in this lane, see the related training topic.

Put external context behind one clean door

MCP matters when the agent needs information that is not already in the repo. That might be GitHub issues, design files, internal docs, a schema registry, or a private knowledge base.

The plugin lesson is that MCP should not float around as a separate setup note. If the agent needs a docs server to perform a skill, the plugin should carry both the MCP configuration pattern and the rule that says when to use it.

A safe first server is read-only. For example, a docs lookup server can answer questions about internal API contracts without giving the agent write access to tickets, databases, or production systems.

The trap is connecting a powerful server before the workflow is clear. A broad cursor mcp setup can make the agent look more capable while making review harder. Start with one read-only source, one skill that uses it, and one review step that shows what external context influenced the output.

Try the smallest installable shape today

You do not need a grand plugin to learn the pattern. Make a tiny bundle for one workflow you already repeat.

A good candidate is pull request review. It has clear inputs, clear output, and a natural human checkpoint. The plugin can include a repo boundary rule, a review skill, a custom reviewer note, and an optional read-only MCP server for docs.

A local experiment might look like this:

mkdir -p cursor-plugin-pr-review/{rules,skills/review-pr,agents,mcp,hooks}

touch cursor-plugin-pr-review/rules/repo-boundary.mdc
touch cursor-plugin-pr-review/skills/review-pr/SKILL.md
touch cursor-plugin-pr-review/agents/reviewer.md
touch cursor-plugin-pr-review/mcp/docs-readonly.example.json
touch cursor-plugin-pr-review/hooks/pre-review.md

This is not a claim about every plugin manifest field. Treat it as a working folder shape for designing the bundle before you wire it into the current Cursor plugin format.

The trap is starting with packaging before the workflow is sharp. If the review skill is vague, installing it only spreads the vagueness faster.

Copy this safe starter artifact

Use this as a small “try it safely” package. It gives the agent one boundary, one skill, and one review receipt.

---
description: Review API pull requests for boundary, migration, and test risk
globs:
  - "services/api/**"
alwaysApply: false
---

Before suggesting edits, identify the files that define the API boundary.
Call out any database migration, public contract, or auth behavior change.
Prefer comments and small patches over large rewrites.
End with a review receipt: changed files, risks found, tests to run.

# SKILL.md
---
name: api-pr-review
description: Review API pull requests for contract risk, migration risk, and missing tests.
---

## Steps

1. Summarize the user’s requested review scope.
2. Inspect changed API routes, schemas, and tests.
3. Flag contract or migration risk before style issues.
4. Suggest the smallest safe patch when the fix is obvious.
5. Produce a review receipt with files checked, risks, and test commands.

## Output shape

- Summary
- High-risk findings
- Small suggested patches
- Tests to run
- Open questions

{
  "mcpServers": {
    "docs-readonly": {
      "command": "node",
      "args": ["./mcp/docs-readonly.js"],
      "env": {
        "MCP_MODE": "readonly"
      }
    }
  }
}

Before using a config like this, compare it with the current Cursor MCP docs and replace the example command with your real server. Keep the first pass read-only unless the workflow truly needs writes.

Common questions

• Is a Cursor plugin the same thing as a Cursor skill?

  No. A Cursor skill is one reusable capability, usually described in a SKILL.md file, while a plugin can package several capabilities together. The useful distinction is scope: put the repeatable workflow in the skill, then let the plugin carry the surrounding rules, agents, MCP settings, and hooks.

• What is cursor mcp doing inside a plugin?

  cursor mcp is the integration layer inside the bundle, not the whole bundle. It gives Cursor access to outside systems through MCP servers, while rules and skills explain when that access is relevant. The safest first version is one read-only server tied to one narrow workflow.

• When should I use a cursor subagent instead of a rule?

  Use a cursor subagent when the work has a distinct role, output contract, or review mode. Use a rule when you only need to constrain normal agent behavior. For example, “stay inside services/payments” is a rule; “act as a migration reviewer and produce a risk receipt” can be a subagent.

• How small should the first plugin be?

  The first plugin should cover one workflow that already has a human review checkpoint. Pull request review, release notes, dependency updates, and schema migration checks are good candidates. If the plugin needs more than one page to explain, split it before installing it.

• What is the main limitation of this pattern?

  Plugins do not magically make bad context good. They make context easier to install and maintain, which also means vague rules can spread quickly. Keep descriptions precise, keep MCP access narrow, and review the agent’s output before turning a local experiment into a shared default.

Best ways to use this research

• Best for: Cursor users who already have scattered rules, skills, hooks, or MCP notes and want one installable shape.
• Best first artifact: A single review plugin with one .mdc boundary, one SKILL.md, and one receipt format.
• Best comparison angle: Prompt snippets are fast to create; plugins are better when the workflow needs versioning, installation, and review.
• Best safety habit: Make the first MCP server read-only and tie it to one skill, not to the whole agent environment.

Further reading

• Cursor — MCP
• Cursor — Agent
• Model Context Protocol — specification

Try one narrow plugin

Pick one repeated workflow and package only the context it needs. If the plugin makes the agent’s next action easier to review, you are on the right path.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.