Cursor 2.4 subagents and skills for engineering teams

By Rogier Muller01.28.26

Cursor 2.4 subagents and skills help only when the delegation is written down before the run starts. Cursor subagents are bounded agent runs, usually one per path or task, and skills are repeatable playbooks that shape how those runs behave. Cursor gives teams the surfaces; the team still has to make the work reviewable.

Write the delegation before the subagent starts

The common failure is not that a subagent writes bad code. It is that nobody can explain why the subagent touched a file after the pull request opens.

Treat each run like delegated engineering work. Name the parent intent, the allowed paths, the forbidden paths, the rule or skill in force, and the command that proves the change.

For example, in a Next.js monorepo, an onboarding analytics change should not be allowed to drift into auth helpers. The path boundary matters more than the model choice.

# Cursor subagent scope ledger

- Parent intent: update onboarding analytics without changing auth behavior.
- Subagent A: UI copy in `apps/site/src/app/onboarding/**`
- Subagent B: analytics tests in `tests/onboarding/**`
- Forbidden paths: `apps/site/src/lib/auth/**`, `.env*`
- Relevant rules: `.cursor/rules/analytics.mdc`
- Relevant skill: `skills/event-review/SKILL.md`
- Proof command: `pnpm test onboarding`
- Merge owner: product engineering lead

Paste the ledger into the pull request before review starts. Five minutes of writing removes the archaeology later.

Decide how rules, skills, and subagents rank

Cursor rules set repo-wide constraints. Cursor skills describe repeatable task behavior. A Cursor subagent executes inside one named scope.

Those layers should not compete. Use this order: human safety decision, repo rules, skill instructions, then the subagent task prompt.

If a skill says to refactor a module and an .mdc rule says the module is frozen, the rule wins. If a reviewer identifies risk, the reviewer wins.

Cursor team skills should live in the repo next to the rules they obey, not in one engineer's private snippets. That keeps the contract visible to reviewers and future runs.

Review artifacts instead of replaying chat

A watched agent run is not the same as a reviewed change. Chat tabs close, memory fades, and the pull request still has to stand on its own.

Review four artifacts: the scope ledger, the rule or skill that applied, the diff, and the verification command with its result. This matches the review habit in our methodology: reconstruct intent from artifacts, not from memory.

A reviewer who did not see the chat should be able to explain the change. If they cannot, the delegation contract was too weak. When the work arrives from Jira, use the Cursor Jira review receipt so the ticket, the rules, and the subagents leave the same trail.

Put connector access inside the same boundary

Connector access follows the same logic as file access. A subagent should reach only the systems needed for the task.

Cursor MCP names what an agent may reach, and the Model Context Protocol defines the contract underneath. As of June 2026, teams should still check the Cursor changelog before changing defaults or assuming connector behavior has stayed the same.

For training patterns across agents, skills, and bounded delegation, use the subagents and skills topic hub. The same four labeled fields show up when docs return Markdown. The same scope ledger can name connectors, forbidden systems, and proof commands.

Practice on one low-risk branch first

Do not make the first subagent workflow a high-stakes migration. Pick a small module where the team already knows the expected behavior.

Write one .mdc rule for that module. Write one skill for a repeated task. Launch one subagent with a path limit, then ask a reviewer who never saw the chat to explain the diff from the pull request artifacts.

If the reviewer cannot explain the work, the system is not ready for higher-risk branches.

Use it on the next branch

Run the one-branch drill on a real low-risk change this week. Keep the ledger, rule, skill, diff, and proof command together in the pull request.