A Team Rubric for Cursor Skills

Use Cursor skills from a marketplace or shared team setup only after they pass a small acceptance rubric: purpose, scope, inputs, safety, and review behavior. That keeps useful cursor agent skills easy to adopt without turning your repo into a pile of invisible prompts.

In Cursor, Anysphere's AI code editor, a Cursor skill is a reusable capability that gives Agent instructions and supporting context for a specific kind of work. For Cursor training, the move is simple: treat skills like code-adjacent team artifacts, not personal snippets.

Accept skills before they become defaults

Start with an intake rule for every shared cursor skill. The rule should answer five things: what the skill does, when Agent should use it, which files or systems it can touch, how a human reviews the result, and who owns maintenance.

This matters more as teams discover the cursor skills marketplace and one-click team installs. As of June 2026, Cursor's changelog describes a Customize page for managing plugins, skills, MCPs, subagents, rules, commands, and hooks at user, team, or workspace level. That is useful, but it also makes weak conventions spread faster.

A real example: your frontend guild wants a React migration skill that updates legacy class components. Good. The trap is letting the description say something vague like migrate React code. A better activation surface says it handles class-to-function component migrations in apps/web, preserves public props, and must leave a checklist in the PR.

For the broader pattern behind Cursor subagents and skills, keep a lightweight training page close by: the related training topic.

Put repo boundaries where Agent can read them

Use AGENTS.md for repository conventions and Cursor rules for IDE-native behavior. A good setup has a short root file for global expectations, then nested files or scoped rules near the code that needs extra care.

For example, a payments service might keep services/billing/AGENTS.md with rules about idempotency, audit logs, and database migrations. A skill that edits billing code should point Agent back to those boundaries instead of repeating them in full.

The trap is making one huge root instruction file. Flat guidance ages badly. Local scope is easier to review, easier to delete, and much less likely to make Agent apply backend rules to a design-system component.

Give subagents a narrow job

Cursor subagents are most useful when they own a lane, not a whole project. Use a cursor subagent for repeatable work like test failure triage, migration planning, release note drafting, or security-sensitive review.

A practical custom subagent note can be tiny: review only changed files, identify risky data-flow changes, and produce a blocking/non-blocking finding list. Pair that with a skill only when the subagent needs a reusable workflow, template, or reference material.

The trap is creating cursor custom agents with impressive names and fuzzy mandates. If two subagents could both claim the task, Agent has to guess. Write names and descriptions like routing labels, not job titles.

Treat MCP as access, not approval

Cursor MCP connects Agent to external systems through the Model Context Protocol. Use it for access to GitHub, docs, issue trackers, databases, or internal knowledge bases, but do not treat that access as permission to make unchecked changes.

A good workflow is boring in the best way. The skill says when to fetch a design doc, the MCP server provides the document, the subagent summarizes the impact, and the human reviews the edit in Cursor before merge.

The trap is mixing retrieval with authority. A skill can say read the deployment runbook before editing infrastructure code. It should not say deploy when tests look fine unless your team has deliberately built that control path.

Copy this skill acceptance rubric

Paste this convention into your repo as the first version of .cursor/rules/skill-intake.mdc, or keep it in AGENTS.md if your team reviews repo guidance there. The important part is not the file name. It is that every shared skill gets the same review before it becomes a team default.

---
description: Review shared Cursor skills before enabling them for a workspace or team
alwaysApply: false
---

# Cursor skill acceptance rubric

Use this rubric before adopting any shared skill, marketplace skill, plugin-bundled skill, or custom subagent workflow.

## Skill identity
- Skill name:
- Owner:
- Repo or workspace scope:
- Last reviewed:

## Activation quality
- The description says exactly when Agent should use the skill.
- The description says when Agent should not use the skill.
- The skill name is short, specific, and not overloaded with another team workflow.

## Context and boundaries
- The skill links to the relevant AGENTS.md, Cursor rule, or local architecture note.
- The skill names the files, packages, or services it may edit.
- The skill names the systems it may read through MCP, if any.
- The skill avoids duplicating long-lived repo rules that already live elsewhere.

## Safety and review
- The skill tells Agent what evidence to leave in the diff, PR comment, or review note.
- The skill defines what must stay human-approved.
- The skill has a rollback or escape path when confidence is low.
- The skill does not hide destructive commands behind broad language.

## Test path
- The skill names the smallest useful validation command.
- The skill says what to do when tests are unavailable or too slow.
- The skill asks for a human decision before broad rewrites.

## Acceptance decision
- Accept as team default:
- Accept for one workspace only:
- Needs revision:
- Reject:

Reviewer rule: a skill cannot become a team default until one engineer outside the authoring group has used it on a real change and signed off on the review evidence.

Adoption path: one engineer proposes the skill, the owning team reviews the rubric, and the accepted version lives beside the code it affects or in the team's Cursor configuration. For cursor for engineering teams, this is usually a better first habit than a big central prompt library.

Review rule: when a skill changes behavior, rerun the rubric. If the change affects risk, ownership, MCP access, or review evidence, treat it like a workflow change in code review. If you are still building the team habit, this pairs well with Cursor Agents Need Team Conventions.

Common questions

• Is there a Cursor skills marketplace for teams?

  Yes, Cursor has been moving skills, plugins, MCPs, subagents, rules, commands, and hooks into shared customization surfaces. As of June 2026, Cursor's changelog mentions a marketplace leaderboard across a team. Treat marketplace discovery as intake, not approval: run the rubric before making any skill a default.

• How do we use Cursor skills without creating a mess?

  Use Cursor skills for repeatable workflows, not every preference. A good first limit is one accepted skill per recurring task, with an owner, scope, activation description, and review rule. If the guidance is always true for a folder or service, make it a Cursor rule or AGENTS.md entry instead.

• When should this be a Cursor rule instead of a skill?

  Use a Cursor rule when the guidance should shape normal work in a repo or folder. Use a skill when Agent needs an on-demand workflow, checklist, script, or reference pack for a specific task. Rules are the road signs; skills are the reusable playbooks.

• Do Cursor custom subagents need their own skills?

  No, a cursor custom subagent does not always need a skill. Give it a skill when the subagent needs reusable instructions, templates, or external reference material that would clutter the agent definition. Keep the subagent's role narrow, then let the skill carry the detailed workflow.

• Can this fit a Cursor AI coding training session?

  Yes, this rubric is a strong Cursor AI coding training exercise because it turns abstract safety talk into a reviewable artifact. Have each team bring one candidate skill, run the rubric, and decide whether it belongs in a user setup, workspace setup, or repo convention.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills
• Cursor — MCP
• Cursor — Enterprise
• Cursor — Changelog
• Model Context Protocol — specification

Start with one shared skill

Pick one workflow your team repeats every week, write the smallest acceptable skill, and run the rubric before anyone enables it broadly. The goal is not more automation; it is a shared Cursor workflow your team can trust and improve.

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.