Roll Out Cursor Team Training

Good Cursor training teaches a team to give agents the same rules, review habits, and tool access they expect from humans. Start with Cursor rules and AGENTS.md, then add cursor subagents, cursor skills, and MCP only where the workflow needs them.

Cursor AI training is the practice of turning one-off agent prompting into repeatable team behavior inside Cursor, Anysphere's AI code editor. The goal is not fancier prompts. It is a repo where agents can work safely, reviewers can check the work quickly, and teammates do not need to rediscover the same instructions every week.

Start with the team workflow, not the model

Smart model routing is choosing the right model or agent path for a task instead of sending every request through the same lane. It is useful, but it is not the first thing to teach.

The first thing is the workflow. Pick three tasks your team actually repeats: bug fix with tests, small refactor, and review a pull request. Train Cursor around those before you debate model routing, custom subagents, or cost knobs.

A real example: a payments repo might route schema questions to a database-aware agent later. But the useful first step is simpler. Teach the agent that payment state transitions must be tested against fixtures, migrations need rollback notes, and no webhook handler changes ship without idempotency checks.

The trap is starting with a router and hoping it creates discipline. Routing can choose a worker. It cannot tell the worker what your team considers done.

Write rules and AGENTS.md boundaries first

Cursor rules are the team rails the agent should see while it works in the repo. Use them for durable habits: test commands, architecture constraints, naming patterns, review expectations, and unsafe areas.

Use AGENTS.md for boundaries that should travel with the repo and stay readable outside one IDE surface. In practice, many teams keep a short root AGENTS.md for global conventions and add nested files near risky packages, such as apps/billing/AGENTS.md or packages/db/AGENTS.md.

Here is the shape that works well:

# AGENTS.md

This repo is a TypeScript monorepo.

Before editing code:
- Read the nearest AGENTS.md file.
- Prefer existing package patterns over new abstractions.
- Do not change generated files directly.

Before opening a PR:
- Run the package test listed in package.json.
- Include one sentence explaining the behavior change.
- Call out migrations, permissions, or background jobs.

Then add a focused Cursor rule beside it:

---
description: Payment changes require idempotency and fixture coverage
alwaysApply: false
---

When editing apps/payments/**:
- Preserve idempotency for webhook handlers.
- Add or update fixture-based tests for every new payment state.
- Do not change retry timing without a note in the PR summary.

The trap is writing a giant root rule file that tries to cover everything. Local scope beats a wall of text. If a rule only matters in one package, put it near that package or make it a specific rule the agent can apply when relevant.

Add subagents and skills where they earn their keep

Cursor subagents are best for repeatable roles with a clear review surface. A good cursor subagent has a job, inputs, limits, and an output format the team can inspect.

For example, a review subagent for a backend service might check auth boundaries, error handling, migration safety, and test coverage. It should not silently rewrite the whole PR. It should produce a review checklist with file paths and questions for a human.

Cursor skills are better for reusable procedures and reference material. A cursor skill can package a release checklist, a debugging playbook, or a migration recipe. The description matters because it is the activation surface. If the skill says vague things like helps with backend work, the agent will not know when to use it.

A practical split:

• Use rules for always-available repo behavior.
• Use AGENTS.md for human-readable boundaries and local conventions.
• Use cursor skills for reusable procedures.
• Use cursor custom agents or custom subagents for repeatable roles.
• Use Cursor MCP when the agent needs safe access to GitHub, docs, databases, issue trackers, or internal systems.

The trap is turning every checklist into a subagent. If the work is just a short procedure, make it a skill or rule. Save custom agents for jobs that need judgment, repeated context gathering, or a distinct review output.

Run the Cursor workshop as practice, not a lecture

A useful cursor workshop is small enough for everyone to touch the keyboard. Plan for 4 to 8 engineers, 90 minutes, and one repo they already know. If the team is larger, run two sessions rather than turning it into a demo.

By the end, each engineer should be able to do four things:

• Explain which instructions belong in Cursor rules, AGENTS.md, skills, and subagents.
• Add one scoped rule to a real package.
• Use or draft one skill for a repeated workflow.
• Run an agent-assisted change and review the result with a checklist.

A clean session flow is: pick a known task, inspect the current repo instructions, add one missing rule, draft one skill or subagent note, run the agent, then review the diff as a group. Keep the task boring. Boring tasks reveal whether the workflow is real.

The measurable after-state is simple: the repo has one merged rule or AGENTS.md improvement, one candidate skill or subagent spec, and one review checklist the lead would actually accept. For a deeper rules-first companion, read Use Cursor Rules as Team Rails. For the broader curriculum path, keep the related training topic handy.

The trap is teaching prompts as magic phrases. Engineers remember workflows better than incantations. Ask them to explain why the rule exists, where it should live, and how they would review the agent's work.

Paste this team rollout plan

Use this as a starter plan for a two-week rollout. It is intentionally small. You can paste it into an issue, planning doc, or team channel.

# Cursor team rollout plan

Team size: 4-8 engineers per cohort
Session length: 90 minutes
Repo: __________________
Owner: __________________
Date: __________________

Learning outcomes:
- Engineers can choose between Cursor rules, AGENTS.md, skills, subagents, and MCP.
- Engineers can add one scoped rule or AGENTS.md boundary in the right place.
- Engineers can run an agent-assisted change and review it with team standards.
- The team leaves with one reusable workflow artifact, not just notes.

Session flow:
1. Pick one real task from the backlog.
   Example: add validation to an API endpoint and update tests.

2. Map the existing instruction surfaces.
   - Root AGENTS.md: yes / no
   - Nested AGENTS.md near the task: yes / no
   - Cursor rules for the package: yes / no
   - Relevant skill: yes / no
   - Relevant subagent: yes / no
   - MCP access needed: yes / no

3. Add one missing boundary.
   Candidate .cursor/rules/api-validation.mdc:

   ---
   description: API validation changes must update tests and error contracts
   alwaysApply: false
   ---

   When editing apps/api/** validation code:
   - Preserve existing error response shape unless the PR says otherwise.
   - Add tests for valid input, invalid input, and missing required fields.
   - Update API docs or examples when request shape changes.

4. Draft one skill or subagent note.
   Skill candidate:
   - name: api-validation-change
   - use when: changing request validation or error contracts
   - includes: test matrix, docs checklist, PR summary template

   Subagent candidate:
   - role: API contract reviewer
   - input: branch diff and nearest AGENTS.md
   - output: contract risks, missing tests, doc changes, open questions
   - limit: review only, do not rewrite files unless asked

5. Run the agent on the task.
   Ask it to state the applicable rules before editing.

6. Review the diff.
   Checklist:
   - Does the change follow the nearest AGENTS.md?
   - Did the agent use the scoped Cursor rule correctly?
   - Are tests included and runnable?
   - Is the PR summary clear enough for a reviewer?
   - Did the agent touch files outside the task without explaining why?

7. Decide what graduates.
   - Merge the rule now: yes / no
   - Promote the skill: yes / no
   - Build the subagent: yes / no
   - Add MCP access: yes / no

Two-week follow-up:
- Count how many agent PRs used the new rule or checklist.
- Collect two examples where the rule prevented rework.
- Delete or rewrite any instruction nobody used.

Common questions

• What should a Cursor AI training session cover?

  A Cursor AI training session should cover team rules, AGENTS.md boundaries, skills, subagents, MCP access, and review habits in one real repo. Keep the first session to about 90 minutes with 4 to 8 engineers, and require one merged instruction improvement or review checklist as the outcome.

• When should we use cursor subagents instead of cursor skills?

  Use cursor subagents when the work is a repeatable role with judgment, context gathering, and a reviewable output. Use cursor skills when the work is a reusable procedure, template, script, or checklist. A migration reviewer is a good subagent; a migration runbook is a good skill.

• Do we need AGENTS.md if we already have Cursor rules?

  Yes, AGENTS.md is still useful because it is plain repo documentation that humans and agents can read. Cursor rules are stronger for IDE-native behavior and scoped activation. The practical pattern is both: AGENTS.md for boundaries and conventions, Cursor rules for agent-facing instructions tied to files or workflows.

• Should we add Cursor MCP during the first workshop?

  Add Cursor MCP only if the practice task needs an external system, such as GitHub, an issue tracker, docs, or a private knowledge base. Otherwise, defer it. MCP is powerful, but it adds permissions and trust questions that can distract from the first lesson: making repo behavior clear and reviewable.

• How do we know the training worked?

  The training worked if engineers can repeat the workflow without the facilitator. A lead should be able to check three artifacts after two weeks: a scoped rule or AGENTS.md update, one used skill or subagent spec, and at least one agent-assisted PR reviewed with the team checklist.

Further reading

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

Try this next

Pick one package where agents often need correction, then add one scoped rule and one review checklist this week. Do not build a full agent system until that small loop works.

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.