Cursor-Beratung für Teams mit einer gemeinsamen Arbeitsweise

Wenn nichts schriftlich festgehalten ist, arbeitet der Agent mit dem, was ein Engineer an diesem Tag in den Chat getippt hat. Reviewer sprechen dann in einem Pull Request nach dem anderen dieselben Konventionen an. Regeln, die im Repository eingecheckt sind, lösen das, solange sie kurz bleiben und jemand für sie verantwortlich ist. Je länger eine Regeldatei wird, desto weniger Gewicht hat jede einzelne Zeile. Eine Regel, die bei jeder Anfrage greift, belegt außerdem jedes Mal Kontext.

Wir entwerfen die Regeln gemeinsam mit Ihren Reviewern und testen jede einzelne an echten Aufgaben. Eine Regel, die der Agent ignoriert oder missversteht, streichen wir wieder.

• Die tatsächlichen Befehle für Build, Test und Lint, damit der Agent seine eigenen Änderungen prüfen kann
• Konventionen, auf die Ihre Reviewer achten, einmal aufgeschrieben und auf die Pfade beschränkt, für die sie gelten
• Für jede Regel eine klare Entscheidung, ob sie immer aktiv ist, über Pfade angehängt oder bei Bedarf geladen wird
• Eine Person, die für die Regeln verantwortlich ist, und ein Review für jede Änderung daran

Wenn Agenten in stetigem Tempo Diffs liefern, staut sich die Arbeit im Review. Mit Ihren Engineers üben wir, Arbeit so lange aufzuteilen, bis jede Aufgabe einen einzigen Diff ergibt, den ein Mensch reviewen kann. Betrifft eine Änderung mehr als ein Modul, wird es zur Gewohnheit, den Agenten erst einen Plan schreiben zu lassen, bevor er Code anfasst. Ein Plan, der weiter reicht, als die Aufgabe verlangt, wird abgelehnt.

Wenn sich eine Session vom Auftrag entfernt, veralteten Kontext mitschleppt oder mit einem Diff endet, der zu groß für ein Review ist, geht ein Neustart mit einem engeren Auftrag schneller, als sie zurückzusteuern. Den Testlauf startet ein Mensch und sieht sich die Ausgabe selbst an, statt sich auf die Zusammenfassung des Agenten zu verlassen.

• Aufgaben, die so klein sind, dass ein Reviewer den ganzen Diff am Stück lesen kann
• Bei modulübergreifender Arbeit ein schriftlicher Plan, der wie eine Design-Notiz reviewt wird
• Testergebnisse, die ein Engineer liest, egal ob die Tests lokal oder in der CI liefen
• Ein vorab vereinbarter Punkt, an dem ein Engineer die Session verwirft, neu beginnt oder die Änderung von Hand fertigstellt

Welche MCP-Server Sie anbinden und wie Auto-Run eingestellt ist, bestimmt, worauf der Agent zugreifen kann und was er tut, ohne vorher zu fragen. Ist jeder Laptop anders konfiguriert, lassen sich die Ergebnisse verschiedener Engineers schwer vergleichen. Nach einem Vorfall ist außerdem mühsam nachzuvollziehen, was passiert ist. Mit Ihnen einigen wir uns auf eine Allowlist der Server. Sie vermerkt, welche Server Zugangsdaten halten und was die jeweiligen Zugangsdaten dürfen. Die gemeinsame Konfiguration liegt dann im Repository oder in den Admin-Einstellungen, sofern Ihr Plan sie vorsieht.

Ein Cloud-Agent nimmt eine Aufgabe mit in eine entfernte Umgebung, arbeitet auf einem eigenen Branch und liefert einen Pull Request zurück. Bevor Ihre Teams sich auf Cloud-Agenten stützen, klären wir, ob die entfernte Umgebung das Repository bauen und seine Tests ausführen kann. Wir listen außerdem die Secrets auf, die die Umgebung bräuchte. Dann vergleichen wir, wie Ihr Plan diese Läufe abrechnet, mit der Abrechnung der Arbeit im Editor. Aufgaben, deren Anforderungen sich noch verschieben oder bei denen ein falscher Schritt viel kostet, gehören in den Editor.

Ihr Cursor-Plan entscheidet, welche Funktionen und Admin-Kontrollen verfügbar sind, deshalb beginnen wir dort. Danach ermitteln wir, was bei Ihren aktuellen Einstellungen für Privacy Mode und Indexierung wohin gesendet wird. Das gleichen wir mit den Bedingungen von Cursor ab, denn Zusagen zum Datenschutz kommen von Cursor.

Pro Einheit schulen wir ein Team, mit dessen eigenen Repositories und Einträgen aus seinem Backlog. Die Zeit fließt in die Gewohnheiten, die sich ändern müssen. Die Funktionen beschreibt die Dokumentation von Cursor, deshalb führen wir sie nicht einzeln vor.

Teams, die neu mit Cursor arbeiten, beginnen mit den Grundlagen: Regeln, Aufgabenzuschnitt und Review. Teams, die Cursor bereits täglich nutzen, klären stattdessen Meinungsverschiedenheiten: wie viel Arbeit man abgibt, welches Modell der Standard ist und was ein Reviewer bei den Diffs des Agenten voraussetzen darf.

Wir reisen zu Ihren Teams in Deutschland und Polen oder halten die Einheiten per Video ab. Die Sprache wählen Sie: Deutsch, Englisch oder Polnisch. Teams werden in einer Einheit nie gemischt, und jedes arbeitet in seinen eigenen Repositories. Offene Kurse, einzeln buchbare Plätze und Zertifikate gehören nicht zu unserem Angebot.

pstack stammt von Lauren Tan und ist ein Cursor-Plugin, das unter der MIT-Lizenz im Repository cursor/plugins veröffentlicht ist. Es enthält Skills und Playbooks für Engineering-Arbeit, die immer wieder anfällt. Dazu kommen eine Regel, die festlegt, welches Modell welche Rolle übernimmt, und Workflows, mit denen Arbeit und Review parallel laufen.

Das Plugin bildet ab, wie Lauren Tan arbeitet, deshalb geht es vor allem darum herauszufinden, welche Teile davon zu Ihrem Team passen. Wir lesen genau die Revision, die Sie installieren wollen. Wir listen auf, worauf sie angewiesen ist: das separate Plugin cursor-team-kit, MCP-Server, Modelle und in Cursor eingebaute Funktionen. Dann gehen Ihre Reviewer die Playbooks mit uns durch. Ein Playbook sagt dem Agenten, was er tun soll, kann aber nichts erzwingen. Wie viel Autonomie ein Playbook bekommt, hängt deshalb von den Kontrollen ab, die Ihr Setup außerhalb des Plugins durchsetzt. Das sind erforderliche Freigaben, Branch Protection und CI. Auch die Berechtigungen und Zugangsdaten, die Sie dem Agenten geben, zählen dazu. Erwartet ein Playbook mehr Spielraum, als diese Kontrollen zulassen, passen wir es an, schränken seinen Umfang ein oder lassen es weg.

• Eine festgelegte Revision des Plugins in einem Fork unter Ihrer Kontrolle, mit Ihren lokalen Änderungen in der Versionskontrolle und einem benannten Owner
• Playbooks, die die Build-, Test- und CI-Befehle ausführen, die Sie schon nutzen, und überall dort anhalten, wo Sie eine Freigabe verlangen
• Ein Modell pro Rolle und eine Obergrenze für parallele Arbeit, beides auf Grundlage von Ergebnissen und Kosten, gemessen an einer festgelegten Auswahl Ihrer Aufgaben
• Vor dem Wechsel auf eine neue Revision ein Check, der dieselben Aufgaben erneut durchspielt und neben den Playbooks auch die Rollenregel abdeckt

Eine pstack-Variante gegen Ihr aktuelles Setup testen · Wie wir die Kosten von Multi-Agent-Workflows erfassen · Code und README von pstack in cursor/plugins · Unser Leitfaden zu den pstack-Workflows

• Jedes Repository hat einen Satz Regeln, den alle nutzen, statt eines privaten Satzes auf jedem Laptop
• Mit Cursor erstellte Änderungen brauchen weniger Review-Runden
• Kosten pro akzeptierter Änderung, gemessen über die Teams hinweg, die Cursor nutzen