Cursor subagents and skills for engineering teams

Cursor 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, Anysphere's AI code editor, 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.

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 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.

Common questions

• What are Cursor subagents?

  Cursor subagents are bounded agent runs, usually scoped to one path or task. The useful boundary is written before the run starts, not inferred after the diff lands. Rules set repo constraints, skills describe task behavior, and the subagent executes inside that named scope.

• How do Cursor subagents and skills work together?

  Skills are repeatable playbooks, and subagents are the bounded runs that execute work under those playbooks. Repo rules sit underneath both as the floor. A scope ledger should name the relevant rule, skill, allowed paths, forbidden paths, proof command, and merge owner before any parallel run starts.

• What takes precedence between Cursor rules, skills, and subagent prompts?

  Human safety decisions come first, then repo rules, then skill instructions, then the subagent task prompt. If a skill contradicts a repo rule, the rule wins. If a reviewer sees risk, the reviewer wins. Without this order, teams waste review time guessing which instruction controlled the run.

• What is a scope ledger for parallel subagent runs?

  A scope ledger is a short pull request artifact written before subagents start. It records the parent intent, each subagent's allowed paths, forbidden paths, applicable rules and skills, a proof command, and a merge owner. It turns parallel agent work into something a reviewer can audit.

• How should a team train on Cursor subagents and skills?

  Start with one low-risk branch and one repeated workflow. Write a repo rule, write a skill, launch one path-limited subagent, and paste the scope ledger into the pull request. If a reviewer who missed the chat can explain the diff, the team can expand the pattern safely.

Further reading

• Cursor Rules
• Cursor Skills
• Cursor Agent overview
• Cursor MCP
• Cursor changelog
• Model Context Protocol specification

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.