Cursor team workflows in a shared repo

The single most important mental shift on a real team: a great prompt is a personal asset, but a great workflow is an organizational one. Cursor adoption fails when it stays at the prompt layer and succeeds when it moves to the repo layer.

In a shared repo, the problem is not "how do I get the model to do something clever." It's "how do I get fifty people, each prompting differently, to produce changes that look like one disciplined engineer wrote them." That is a governance problem, not a convenience problem. The unit of leverage stops being the prompt in your head and becomes the artifact checked into the tree.

The progression every team walksad-hoc → governed

1. 1Personal prompts — each dev has their own habits, lives in their head, dies when they leave. Zero leverage for the team.
2. 2Shared Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. / `AGENTS.md` — the conventions move into the repo. Now the model behaves consistently regardless of who's driving.
3. 3Shared commands — repeatable, named workflows (generate-test, scaffold-endpoint) so the how is encoded, not re-typed.
4. 4Scoped context + ignore controls — you engineer what the agent can see and touch, so it pulls the right files and never the secrets.
5. 5Plan-first, reviewable handoffs — the agent proposes, a human approves, the diff stays small enough to actually read.

Each step trades a little spontaneity for a lot of repeatability. The mature team treats its Cursor configuration the way it treats CI config or lint rules: it's part of the codebase, it goes through review, and it's an ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved, and how systems are run.-adjacent control surface, not a sticky note.

The governing principle is proximity: the closer a rule lives to the code it governs, the more reliably it's applied and the easier it is to review. Cursor gives you a layered set of places to put intent, and a strong field engineer knows which layer each thing belongs in.

Project Rules vs AGENTS.md — when to use which

The interview-grade nuance: rules don't replace judgment, they encode defaults. The model still needs a good prompt — but now it starts from your team's baseline instead of the internet's average. That's the difference between fifty drifting styles and one house style.

In a large repo, getting the right context into the agent is not a prompt-length contest — it's an information-retrieval design problem. Stuffing more text in is the amateur move; engineering what the model can find and reach is the professional one.

Cursor gives you four distinct mechanisms, and they do different jobs. Confusing them is the most common reason teams get mediocre output on big codebases.

The recall-vs-precision pattern

Use search/indexing for recall when you don't yet know where the relevant code lives. Use @-mentions for precision once you do. The skilled workflow is a funnel: let semantic search surface candidates, then pin the exact files with @-mention so the agent works from ground truth instead of a fuzzy memory. MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. brings the intent (the Jira ticket, the acceptance criteria) alongside the code so the agent is solving the actual business problem, not its guess of it.

The most dangerous moment in agentic development is the green checkmark. "The agent finished" only means it stopped — it says nothing about whether the change is correct, scoped, or mergeable. Shaping the change is where senior engineers earn their keep.

The discipline, in four habits

• Small diffs. A reviewable PR is one a human can actually hold in their head. Mega-rewrite PRs aren't a productivity win — they're an un-reviewable liability with a huge blast radiusHow much breaks if a change goes wrong; the scope of potential damage..
• Tests as targets. Point the agent at a failing test or a clear acceptance criterion and let it work toward green. "Make this pass" is a far better instruction than "improve this."
• Plan before implement. Have the agent produce a plan you can review before it touches code. Cheap to redirect a plan; expensive to unwind 600 lines.
• No mega-rewrite PR. Decompose. If the agent wants to touch thirty files, that's a signal to split the work, not to rubber-stamp it.

The ownership rule (memorize this)

This single rule resolves most of the cultural anxiety around AI code. It preserves separation of dutiesNo single person can author, approve, and deploy the same change. The core control AI autonomy has to respect. (the author is still distinct from the reviewer), it keeps accountability with a named human, and it makes the AI-code-tracking and audit-log features meaningful rather than punitive. Provenance is visible; responsibility is clear.

Cursor's agent surface is a ladder of increasing autonomy: inline Tab completions, the in-IDE agent, the CLI agent, cloud agents running in isolated cloud VMs, and the SDK for programmatic automation. The governing law: every step up in autonomy demands a step up in guardrails. Blast radius grows with independence, so control must grow with it.

Match the rung to the risk tier

A typo fix in a docs file and a change to the payments authorization path are not the same risk tier, and they shouldn't get the same autonomy. Low-risk, well-tested surfaces can run further up the ladder with lighter touch. High-risk, regulated paths stay low on the ladder with plan gates, mandatory human review, and tight allowlists. The cloud agents' isolation (separate VMs, no standing production credentials) is precisely what lets you grant autonomy without granting blast radiusHow much breaks if a change goes wrong; the scope of potential damage..

On a team, freeform prompting is noise. Most real work collapses into four repeatable intents, and naming them is how you get juniors to operate like seniors. Teach these four and you've taught the workflow.

The capability × SDLC-phase one-pager

The way to talk to a VP of Engineering is not feature-by-feature — it's a grid of which capability earns its keep in which phase of the SDLC. This is the artifact that turns a demo into a rollout plan.