Train Your Team on Cursor 3.9

Cursor 3.9 gives teams one place to manage the pieces that shape how Cursor behaves: plugins, skills, MCPs, subagents, rules, commands, and hooks. For training, that means you can teach one operating model instead of handing people a folder of scattered snippets.

Cursor, Anysphere’s AI code editor, now has a Customize page that supports user, team, and workspace-level setup as of June 22, 2026. A good cursor workshop should leave your team with a working repo policy, one useful skill, one scoped subagent, and a review habit they can repeat.

Start with the Customize page, not a prompt library

Use Cursor 3.9’s Customize page as the front door for your team setup. Put shared behavior at the team or workspace level, then let individuals keep personal preferences at the user level.

Cursor skills are reusable, on-demand instructions and resources that help the agent perform a specific workflow. Cursor subagents are scoped agent definitions that let a team steer a task toward a role, boundary, or review style.

That distinction matters in cursor ai training. A skill teaches Cursor how to do a repeatable job, like writing an API migration note. A subagent shapes who should do the job, like a database migration reviewer that cares about locks, indexes, and rollback paths.

The trap is treating everything as a prompt. Prompts are easy to copy and hard to govern. Rules, skills, subagents, MCPs, hooks, and commands are easier to review because they live as named objects with a purpose.

For a Rails repo, for example, you might keep a workspace rule for service-object conventions, a skill for adding an audited admin action, and a subagent for reviewing ActiveRecord query risk. The developer asks for a feature; the team setup quietly supplies the habits.

Teach the team what belongs where

A useful Cursor training session starts with sorting. Give the team five examples and ask where each one belongs: rule, AGENTS.md note, skill, subagent, MCP, command, or hook.

Use rules for durable repo behavior. Use AGENTS.md for repository boundaries and conventions that should travel with the codebase. Use skills for repeatable workflows. Use MCP when Cursor needs access to an external system, such as issues, docs, design context, or internal data.

The trap is putting architecture decisions inside a skill because it feels convenient. A skill should not be the only place that says payments code cannot call the legacy billing client directly. That belongs in a durable repo convention, usually in AGENTS.md or a scoped Cursor rule.

Here is a small boundary that works well in a real repo:

# AGENTS.md

## payments/

Cursor may edit files in payments/ for billing workflow changes.

Before changing billing adapters:
- Read payments/README.md.
- Preserve idempotency keys.
- Do not call LegacyBillingClient from new code.
- Add or update contract tests in payments/test/contracts/.

When uncertain, stop and ask for the migration path instead of inventing one.

That file is not glamorous. Good. The best agent context often looks like a careful teammate left a note before vacation.

Practice one skill and one subagent in a real workflow

Pick one workflow that happens every week. Do not start with a giant agent redesign. Start with a boring workflow that already has a checklist: add a feature flag, update a public API endpoint, write a data migration, or triage a flaky test.

A small Cursor skill might teach the agent how your team writes feature-flagged changes. It can include the rollout order, test expectations, and the format of the release note. The description should be specific enough that Cursor can decide when to use it.

A matching cursor subagent can own the review angle. For example, create a release-safety subagent that checks whether the feature flag has a default, whether rollback is possible, and whether the change has an observable metric.

The trap is making cursor custom agents too broad. “Senior engineer” is not a useful role. “Release-safety reviewer for feature-flagged backend changes” is much better because it has a job, a boundary, and a checklist.

For teams going deeper on integrations, pair this training with a checklist like Cursor MCP Integration Checklist. It helps keep MCP setup tied to real development workflows instead of turning into a connector shopping trip.

Add governance where work enters and leaves

Training should cover the start and end of agent work. At the start, Cursor needs the right context. At the end, humans need a reviewable diff and a clear claim about what changed.

Use hooks and commands sparingly. They are powerful because they can make the right path easy, but they can also hide too much automation from the developer. A pre-review command that runs tests and generates a short change summary is usually safer than a hook that mutates files unexpectedly.

A simple .mdc rule can keep review behavior consistent:

---
description: Reviewable changes for backend work
globs:
  - "api/**/*.ts"
  - "services/**/*.ts"
---

Before finishing backend work:
- Run the closest relevant test command, or explain why it could not run.
- Summarize changed files by responsibility, not by file name only.
- Call out database, auth, queue, and public API behavior changes.
- Do not mark the task complete if generated code has unreviewed TODOs.

The trap is using governance as a wall of warnings. Rules that read like legal terms get ignored. Keep them short, local, and tied to checks a reviewer can verify.

Size the training so people actually change habits

A solid cursor training rollout fits in half a day for 6 to 12 engineers. Ninety minutes is enough for a focused cursor workshop, but not enough for team-level governance unless the artifacts already exist.

Good learning outcomes are concrete:

• Engineers can explain when to use cursor rules, AGENTS.md, cursor skills, cursor subagents, and cursor mcp.
• Each squad ships one workspace rule or AGENTS.md boundary.
• Each squad creates one useful skill and one scoped cursor custom subagent.
• The team agrees on a review checklist for agent-written changes.
• A lead can inspect the setup from the Customize page and the repo.

The session flow should be hands-on. Start with the changelog-level model of Cursor 3.9. Audit one real repo. Write or edit one rule. Add one skill. Draft one subagent. Run one task. Review the diff as a group.

The measurable after-state is simple: one merged repo artifact, one configured team artifact, and one reviewed agent-assisted pull request. If those do not exist, the workshop was a tour, not training.

For more examples in this area, keep the team’s shared learning path close to the related training topic.

Copy this team rollout plan

Paste this into your team planning doc. Keep it small enough that a tech lead can finish it with the team in one or two sessions.

# Cursor 3.9 team rollout plan

## Goal
Make Cursor useful and reviewable for this repo by standardizing rules, skills, subagents, MCP access, and review habits.

## Team size and timing
- Best fit: 6–12 engineers working in the same repo or service area
- Minimum session: 90 minutes for one workflow
- Better rollout: 3–4 hours with artifact review and a follow-up PR

## Learning outcomes
By the end, engineers can:
- Explain what belongs in Cursor rules, AGENTS.md, skills, subagents, MCPs, commands, and hooks
- Use the Customize page to find or manage team/workspace setup
- Run one agent-assisted workflow with a reviewable diff
- Name the human approval point before code merges

## Session flow
1. Pick one real workflow
   Example: add a feature-flagged backend endpoint.

2. Audit existing guidance
   Check AGENTS.md, .cursor/rules, README files, test docs, and release notes.

3. Add or tighten one repo boundary
   Artifact: AGENTS.md section or scoped .mdc rule.

4. Create one skill
   Artifact: a skill for the repeatable workflow, with a clear name and activation description.

5. Create one subagent
   Artifact: a scoped reviewer or implementer, such as release-safety reviewer or api-contract reviewer.

6. Decide MCP access
   Artifact: list of approved MCP servers, what each can access, and who owns it.

7. Run the workflow
   Developer uses Cursor to make a small change while the team watches context, tool use, and assumptions.

8. Review the diff
   Use the checklist below before merging.

## Review checklist for agent-assisted changes
- The diff is small enough to review normally.
- Cursor followed the local rule or AGENTS.md boundary.
- Tests were run, or the reason is written down.
- External context from MCP was relevant and allowed.
- The PR summary names behavior changes, risks, and rollback notes.
- A human approved security, data, auth, and public API changes.

## Lead check after one week
- One repo artifact is merged.
- One skill is used by at least two engineers.
- One subagent produces a useful review comment or checklist.
- No MCP server is connected without an owner and purpose.
- The team removed or rewrote at least one confusing rule.

Common questions

• What should a Cursor training session actually cover?

  A useful session should cover rules, AGENTS.md, skills, subagents, MCP access, and review habits in one real repo workflow. For most teams, 90 minutes is enough for a narrow workflow, while 3–4 hours is better when you want durable team artifacts and a reviewed pull request afterward.

• Should we create cursor skills or cursor subagents first?

  Create the skill first when the workflow is unclear, then add a subagent once the review role is obvious. A skill captures the repeatable steps; a subagent captures the point of view, such as release safety, API compatibility, or database risk. This order avoids inventing vague agents nobody trusts.

• Where should AGENTS.md fit with Cursor rules?

  Use AGENTS.md for repo conventions and boundaries that should live with the code, and use Cursor rules for behavior Cursor should apply in specific scopes. The practical test is ownership: if reviewers expect it in the repository, put it in AGENTS.md or a tracked rule, not a private user setting.

• How much MCP should we include in a first rollout?

  Include only the MCP connections needed for the chosen workflow. One approved docs or issue-tracker connection is plenty for a first rollout. The caveat is ownership: every MCP server should have a named purpose, an access boundary, and a person responsible for removing it if it stops being useful.

• How do we know the team is using Cursor safely?

  Look for reviewable evidence, not good vibes. A safe rollout has small diffs, local rules that were followed, tests or written test gaps, clear MCP usage, and human approval for risky areas. The easiest metric is one merged agent-assisted PR that another engineer can review without a live explanation.

Further reading

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

Start with one workflow

Pick one weekly engineering workflow and build the smallest Cursor 3.9 setup around it. If the team can repeat it, review it, and improve it next week, the training worked.

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.