Cursor Training for Subagents and Skills

Start smaller than a feature tour: Cursor training works when a team leaves with one repo workflow that the agent can run, review, and repeat. For engineering teams, I would center the session on Cursor rules, subagents, skills, and MCP only where they remove a real handoff, such as preparing a safer PR or reviewing an API change.

Cursor AI training should produce working repo artifacts, not just better prompts. The useful after-state is plain: the team has one scoped rule, one reusable skill, one custom subagent note if the workflow needs it, and one review habit that a lead can check in the next PR.

Set the learning outcomes before the tool tour

I would write the outcomes before opening Cursor. A good Cursor workshop should leave engineers able to decide what belongs in rules, what belongs in a skill, what belongs in a subagent, and what should stay in ordinary chat.

Keep the sizing honest. Six to twelve engineers works well for a half day, or two 90-minute sessions if the team needs time between practice rounds. For larger groups, split by repo or domain so people are editing files they actually own.

The measurable result should be concrete. By the end, each group should have a reviewed PR or branch that adds one team artifact and proves it on a small change.

Build the rollout in five steps

Use the first session to build one narrow operating model. Do not ask people to remember every surface area at once.

1. Pick one workflow with a real review cost, such as changing an API route, updating a React component, or adding a migration.
2. Add or refine the repo guidance first, using AGENTS.md or Cursor rules for durable conventions.
3. Package a repeated procedure as a Cursor skill when the team needs the same steps more than once.
4. Add a Cursor subagent only when a role needs its own focus, such as migration review, test planning, or release note drafting.
5. Connect Cursor MCP last, starting read-only, after the team knows which external context is actually needed.

This is where I tie the session to Review in our methodology: delegate the work, inspect the diff and reasoning, then decide what the team now owns as repo guidance.

Give each artifact a narrow job

Rules should hold stable project constraints. Put architecture boundaries, naming conventions, test commands, and security rules there, especially when the same instruction applies across many tasks.

Skills should hold repeatable procedures. A Cursor skill is a better fit for a release checklist, a migration playbook, or a support-debugging path because it packages steps the agent can reuse when the task matches.

Subagents should hold a specialist role. A Cursor subagent is worth the extra setup when the main agent benefits from handing off a bounded review, such as “check database changes against migration rules” or “review this PR for public API compatibility.” Too many subagents become a routing problem, so start with one.

MCP should be treated as a permission boundary, not a magic context pipe. For Cursor MCP, I prefer read-only access first for systems like issue trackers, design files, docs, or repo metadata, then write access only after the team can explain the workflow and rollback path.

For deeper work on this part of the stack, I would pair this article with Subagents and skills and, when the team is ready to focus only on the agent role design, Train Teams on Cursor Subagents.

Practice on one repo workflow

Use a real workflow with a small blast radius. A good example is a frontend change where the agent updates a component, adds or adjusts a test, and prepares the PR summary from the diff.

In that workflow, the rule might say which test command to run, the skill might describe the PR-prep sequence, and the subagent might review accessibility or API compatibility. The point is not to make Cursor autonomous. The point is to make the handoff inspectable.

Ask the team to review the agent output without replaying the whole chat. The lead should be able to inspect the changed files, the rule or skill that shaped the work, and the final PR checklist.

Team rollout plan to paste into an issue

## Cursor rollout: subagents and skills

## Goal
Make one repo workflow repeatable in Cursor without hiding review responsibility.

## Scope
- Repo or package:
- Workflow to practice:
- Team size:
- Session length:
- Lead reviewer:

## Learning outcomes
- Engineers can explain what belongs in Cursor rules, skills, and subagents.
- Engineers can update one repo artifact instead of relying on private prompts.
- Engineers can review agent output through the diff, tests, and PR checklist.

## Session flow
1. Choose one existing workflow with review cost.
2. Capture durable repo guidance in `AGENTS.md` or Cursor rules.
3. Turn the repeated procedure into a Cursor skill.
4. Add one custom subagent only if a specialist review role is needed.
5. Run the workflow on a small change.
6. Review the diff, tests, and PR summary as a group.
7. Decide what artifact stays in the repo.

## Guardrails
- Start with read-only MCP access.
- Do not add more than one new subagent in the first session.
- Prefer repo-owned instructions over private prompts.
- Require a human reviewer for generated code.

## Done when
- One rule, skill, or subagent artifact is committed or proposed in a PR.
- The workflow has been run once on a real change.
- The team has a review checklist for the next PR.
- The lead can name the next workflow to train or explicitly stop the rollout.

Further reading

• Cursor Agent docs
• Cursor rules
• Cursor skills

Run the first session

For a facilitated Cursor workshop on subagents, skills, rules, and MCP, use hands-on training.

Related research

• Using Cursor Skills Marketplace Safely
• Use Jira MCP Safely in Cursor
• Cursor Guardrails for Real Teams