Cursor consulting for teams that share one way of working

When nothing is written down, the agent works from whatever an engineer typed into the chat that day. Reviewers then raise the same conventions in one pull request after another. Rules checked into the repository solve this, as long as they stay short and someone owns them. The longer a rule file grows, the less weight each line carries. A rule that applies to every request also takes up context each time.

We draft the rules together with your reviewers and test each one on real tasks. Any rule the agent ignores or misunderstands comes out again.

• The real commands for build, test and lint, so the agent can verify its own changes
• Conventions your reviewers care about, written down once and limited to the paths they cover
• For each rule, a clear decision on whether it is always on, attached by path or loaded on request
• One person responsible for the rules, and a review for every change to them

When agents produce diffs at a steady pace, review is where work starts to queue. With your engineers, we practise splitting work until each task yields one diff that a person can review. When a change spans more than one module, the habit is to have the agent write a plan before it touches any code. Any plan that reaches further than the task requires is turned down.

When a session wanders from the brief, carries stale context or ends with a diff too big to review, starting again with a narrower brief is quicker than steering it back. A person starts the test run and reads the output, instead of trusting the agent's summary of it.

• Tasks small enough that one reviewer can read the whole diff at once
• For cross-module work, a written plan that gets the same review as a design note
• Test results read by an engineer, whether the tests ran locally or in CI
• A point agreed in advance at which an engineer drops the session, starts over or finishes the change by hand

The MCP servers you connect and your auto-run settings determine what the agent has access to and what it does without asking first. If every laptop is configured its own way, results from different engineers are hard to compare. After an incident, it is also difficult to work out what happened. We settle on an allowlist of servers with you. It notes the servers that hold credentials, and what each set of credentials is allowed to do. Shared configuration then lives in the repository, or in the admin settings if your plan includes them.

A cloud agent takes a task into a remote environment, works on its own branch and returns a pull request. Before your teams start depending on cloud agents, we find out whether the remote environment can build the repository and run its tests. We also list the secrets the environment would require. Then we compare how your plan bills these runs with how it bills work in the editor. Tasks whose requirements are still shifting, or where one wrong step costs a lot, belong in the editor.

Your Cursor plan decides which features and admin controls are available, so we start there. Next, we work out what gets sent where under your current privacy mode and indexing settings. We check that against Cursor's own terms, since privacy commitments come from Cursor.

We train one team per session, using its own repositories and items from its backlog. The time goes to the habits that need changing. Cursor's documentation covers the features, so we don't walk through them.

Teams new to Cursor start with the groundwork of rules, task scoping and review. Teams that already use it every day settle disagreements instead: how much work to hand over, which model is the default and what a reviewer may assume about the agent's diffs.

We travel to your teams in Germany and Poland, or run the sessions over video. You pick the language: English, German or Polish. Teams are never mixed in one session, and each works in its own repositories. Public courses, individual places and certificates are not part of what we offer.

Lauren Tan is the author of pstack, a Cursor plugin released under the MIT licence in the cursor/plugins repository. It holds skills and playbooks for engineering work that comes up again and again. It also has a rule that sets which model takes each role, and workflows for running work and review in parallel.

The plugin reflects how its author works, so the main task is to work out which parts of it suit your team. We read the exact revision you plan to install. We list what it relies on: the separate cursor-team-kit plugin, MCP servers, models and features built into Cursor. Then your reviewers go through the playbooks with us. A playbook tells the agent what to do, but it cannot enforce anything. The autonomy a playbook gets therefore depends on the controls your setup enforces outside the plugin. Those controls are required approvals, branch protection and CI. The permissions and credentials you give the agent count too. If a playbook expects more freedom than that, we adjust it, narrow its scope or leave it out.

• One fixed revision of the plugin in a fork you control, with your local changes under version control and a named owner
• Playbooks that run the build, test and CI commands you already use, and pause wherever you require an approval
• A model per role and a cap on parallel work, both based on results and cost measured on a defined set of your tasks
• Before you move to a new revision, a check that runs the same tasks again and covers the role rule along with the playbooks

Testing a pstack variant against your current setup · How we count the cost of multi-agent workflows · pstack's code and README in cursor/plugins · Our guide to pstack workflows

• Each repository has one set of rules that everyone uses, rather than a private set on every laptop
• Changes made with Cursor need fewer rounds of review
• Cost per accepted change, measured across the teams that use Cursor