Cursor subagents and skills for teams

The hard part of running Cursor subagents and skills on a team is not the tooling, it is making the work explainable after the person who set it up walks away. Cursor, Anysphere's AI code editor, gives you a delegation pair: subagents bound where an agent may edit, and skills that script how it behaves once inside. A skill is a markdown file that tells the agent how to do one kind of task. Get four small contracts written down and a teammate can pick up any delegation cold, without a hallway conversation that only one person can give.

I learned this the week a handoff was set for Friday and on Wednesday we found a rules file that contradicted the skill the agent had just activated. Nothing was broken. Nothing was explainable either, and the one person who knew why was about to be on leave. The fix was not more tool access. It was four artifacts that live in the repo.

Give risky prompts an owner and a retire-by date

Demo prompts and migration hacks are the ones that fossilize. They ship fast, become the default, and a few quarters later nobody remembers which shortcuts were supposed to expire.

Tag them the moment they ship. Put an owner and a retire-by date in the rule comment, so housekeeping is scheduled instead of heroic. Scheduled housekeeping is the only kind that actually happens.

The rule is simple: anything labeled temporary gets a name attached and a date attached. When the date passes, someone owns the decision to keep it or kill it.

Open every skill with its precedence preamble

Once you adopt Cursor Skills, you will eventually watch a skill contradict an always-on rule. Two sources of truth, no ritual for deciding which wins.

Head off the fight in the file itself. Open every SKILL.md by naming which .mdc files override it, per Cursor Rules. Now the activation trace is written down instead of living in one person's head.

A reviewer reading the PR can answer "which rule governed this behavior" by reading the skill, not by asking around.

Stop parallel edits from colliding with mutex paths

Isolated agent windows each inherit a partial map of the repo. Run two subagents on the same module and they will edit it differently, and you find out when you are pulling duplicate edits out of one file.

List the contested directories in AGENTS.md as mutex paths: places where only one subagent may run per PR. An honest git conflict then replaces silent duplication, and a loud failure is the one you want.

Here is a starter boundary rule you can drop in and adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

Connector behavior sits under Cursor MCP with the Model Context Protocol specification underneath. The Cursor Agent docs cover the runtime, and the changelog covers what moved.

Write a review receipt in every PR body

Cursor Blame exists, and reviewers still skip attribution when the PR body is empty. A blame UI cannot replace a written account of why the work happened.

So write one. The receipt is a PR description a stranger can audit: parent intent, each child scope, and the verification transcript. Blame links then answer "why here" instead of just pointing at a line.

Run these gates before you merge. They are team property, not personal habit:

A merge checklist you can paste straight into your template:

• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent plus child responsibilities.
• Red-folder paths received explicit human acknowledgement.

If your repo cannot state its boundaries plainly, agents will guess, and guessing scales poorly. The surrounding patterns live in the subagents and skills topic hub, and where this fits in our process is written up in our methodology.

Common questions

• How do Cursor subagents and skills for teams stay explainable?

  Four artifacts carry the load. Mutex paths in AGENTS.md keep parallel runs from colliding silently, a preamble in every SKILL.md names which rules override it, expiry tags retire risky prompts on schedule, and a review receipt in every PR body lists intent, scopes, and the verification transcript. Together they let a teammate replay any delegation cold.

• What are mutex paths?

  Mutex paths are directories listed in AGENTS.md where only one subagent may run per PR. Each isolated agent window inherits a partial map of the repo, so without the list two runs can edit the same module differently and overwrite each other quietly. With the list, an honest git conflict surfaces the collision instead.

• What is a review receipt?

  A review receipt is a PR description written so a stranger can audit the work: parent intent, each child scope, and the verification transcript. It is what makes blame links answer "why here" rather than just point at a line. When the original operator is unavailable, the receipt is what the handoff actually depends on.

• When should a prompt get an expiry tag?

  The moment it ships as a shortcut. Demo prompts, migration hacks, anything you labeled temporary. The tag is an owner plus a retire-by date inside the rule comment. Temporary defaults are exactly how a team drifts into accepting shortcuts as permanent, and a scheduled review is the only kind that reliably happens.

Start with one repo this sprint

Add the skill preamble and the mutex paths to a single repo this sprint, then watch what the next handoff no longer needs to ask. If you want a guided run at it, our training walks teams through these contracts on their own code.