Train Teams on Cursor Subagents

Cursor training should not start with prompt tricks. For an engineering team, the useful path is to turn one repo workflow into Cursor rules, a small skill, a narrow subagent, and an MCP boundary, then review the output like normal code.

A Cursor workshop should leave artifacts in the repo. The team should be able to point at the rule, the skill, the subagent note, and the review checklist after the session. That is the difference between a demo and a workflow the next developer can use.

This fits the Subagents and skills work because Cursor features only become valuable when the team knows when each one should carry context, when it should carry procedure, and when it should stay out of the way.

Start with one repo workflow

Pick one workflow the team already repeats. Do not train on a toy prompt if the real pain is review, migration work, test repair, or issue triage.

A good exercise is a normal issue-to-PR path: take a failing checkout test in a Next.js app, inspect the API handler, update the focused test, and prepare review notes. That gives Cursor enough context to help, and it gives the team a clear standard for judging the result.

By the end of the first session, the team should be able to do four things:

• choose the right Cursor surface for durable rules, reusable procedure, and specialist review
• write one scoped Cursor rule that the agent can follow without rereading chat history
• package one repeated workflow as a Cursor skill
• ask a narrow Cursor subagent to review a change and then verify the answer themselves

Put durable constraints in Cursor rules

Use Cursor rules for constraints that should survive the chat. Coding standards, directory boundaries, test commands, architectural limits, and review expectations belong there before they belong in a prompt.

Keep the rules close to the code they govern. A root rule can state broad repo expectations, but a nested rule near apps/web, packages/db, or services/billing is easier for a team to maintain and harder for the agent to overapply.

If the repo already uses AGENTS.md as a cross-tool convention, keep it short and use it as a boundary note. Put Cursor-specific behavior in Cursor rules so the team can see what Cursor is expected to follow.

Separate skills from subagents

Use Cursor skills for reusable procedure. A good Cursor skill can carry the steps for adding a database migration, running the right test command, or preparing a release note with the team’s format.

Use Cursor subagents for narrow judgement. A migration reviewer, API compatibility reviewer, or test failure investigator should have a focused job, not a vague instruction to “improve the code.”

This is where many teams blur the line. If the artifact says how to perform a repeated task, make it a skill. If it names a specialist reviewer with a scope and expected output, make it a subagent or custom agent note.

I usually tie this to the Review step in our methodology: the agent can produce a first pass, but the developer still owns the decision to merge, reject, or ask for another pass.

Add MCP after the workflow is stable

MCP is useful when Cursor needs controlled access to systems outside the repo, such as issues, docs, design files, or internal knowledge. Start read-only unless the workflow clearly needs writes.

For example, an issue-triage workflow can read a ticket, inspect the relevant code, suggest a patch, and prepare a review summary. It does not need permission to change project status on day one.

If MCP is the main blocker for your rollout, I would handle that separately with Cursor MCP Support for Team Workflows. Mixing permissions, rules, skills, and subagents in the first hour usually hides the real failure mode.

Run the workshop in this order

This is the smallest session flow I would use for Cursor AI training with a working engineering team.

1. Select one repo workflow and define a done state before opening Cursor.
2. Add or refine one scoped Cursor rule that states the repo boundary and the test command.
3. Turn the repeated steps into one Cursor skill with a clear name, trigger description, inputs, and expected output.
4. Add one narrow custom subagent for review, investigation, or migration checking.
5. Run the workflow on a small change and require a human review of the diff, tests, and agent explanation.
6. Write down what failed: missing context, vague rule, oversized subagent, unsafe MCP access, or unclear review standard.

For sizing, keep the first run small: four to eight developers, one lead, one repo, and two to three hours. Larger groups can watch, but they should not all edit the operating model at once.

The measurable after-state is simple. A lead should be able to open the repo and find one useful rule, one usable skill, one narrow subagent definition, and one review checklist tied to a real workflow.

Paste this rollout plan into the repo

# Cursor rollout plan

## Workflow
Name the workflow we are training on:
- Example: fix a failing checkout test and prepare a PR review summary

## Repo boundary
Code area:
- apps/web checkout flow

Human owner:
- ____________________

Cursor rule to add or update:
- .cursor/rules/checkout-flow.mdc

Rule must include:
- directories in scope
- directories out of scope
- test command
- review expectations

## Skill
Skill name:
- checkout-test-repair

Skill should include:
- when to use it
- required inputs
- steps to inspect the failure
- commands to run
- expected final response format

## Subagent
Subagent name:
- checkout-reviewer

Subagent should check:
- API behavior changed only where intended
- tests cover the changed path
- no unrelated formatting or refactor slipped in
- review summary names remaining risk

## MCP boundary
External systems allowed:
- read issues: yes / no
- read docs: yes / no
- write tickets: no for first rollout

## Acceptance check
Before this workflow is considered adopted:
- [ ] one developer other than the author can run it
- [ ] the focused test command is correct
- [ ] the subagent output is useful without chat history
- [ ] the human reviewer can reject the agent's suggestion cleanly
- [ ] the rule or skill was improved after the first real use

Further reading

• Cursor Agent docs
• Cursor rules
• Cursor skills

Make the next session concrete

Bring one repeated repo workflow to a hands-on training session and turn it into a rule, a skill, a narrow subagent, and a review checklist the team can keep using.

Related research

• Cursor AI for Team Workflows
• Cursor Agent for Team Workflows
• Use Figma MCP in Cursor Safely
• Use Cursor Rules in Team Repos