Cursor Composer: Multi-File-Edits ohne Copilot-Schmerzen
Wie der Composer-Modus in Cursor funktioniert, was er von einfacher Autocomplete unterscheidet, und konkrete Tasks, die er gut macht.
Cursors Composer-Modus kann mehrere Dateien gleichzeitig editieren — Refactoring, Migrationen, Feature-Erweiterungen. Hier sind die Tasks, bei denen es wirklich Zeit spart.
Was Composer von Autocomplete unterscheidet
Cursors normaler Tab-Autocomplete (in der Inline-Edit) ist gut, aber begrenzt: er sieht die aktuelle Datei + ein paar geöffnete Tabs. Composer hingegen:
- Versteht den gesamten Projekt-Kontext (über @-Erwähnungen)
- Kann mehrere Dateien in einer Operation ändern
- Zeigt einen Diff-View vor dem Anwenden
- Hat eigenen Chat-Thread pro Aufgabe
Aktivieren
Cmd+I (Mac) oder Ctrl+I (Windows). Es öffnet sich ein Side-Panel.
Task 1: Komponenten-Rename quer durchs Projekt
Klassische Aufgabe: Komponente UserCard heißt jetzt ProfileCard. Suchen-und-Ersetzen reicht nicht, weil:
- Import-Pfade müssen mit umbenannt werden
- Tests und Stories ebenfalls
- CSS-Module mit dem Namen müssen mit
Prompt:
Rename @UserCard.tsx and all its imports across the project to ProfileCard. Also rename @UserCard.module.css → ProfileCard.module.css, @UserCard.test.tsx → ProfileCard.test.tsx, and any Storybook story files. Update all import paths.
Composer schlägt eine Liste an Änderungen vor — du klickst durch und akzeptierst Datei für Datei.
Task 2: API-Endpoint-Migration
Frontend nutzt überall /api/v1/users/.... Backend zieht auf /api/v2/profiles/... um. Die Pfad-Struktur ändert sich, einige Parameter werden umbenannt.
Prompt:
Update all API calls in @src/services/api/ from /api/v1/users to /api/v2/profiles. The new endpoints use camelCase parameters instead of snake_case (e.g. user_id → userId, created_at → createdAt). Update response type definitions in @src/types/api.ts accordingly.
Composer findet alle Aufrufe, ändert URLs, passt Parameter an, korrigiert Types.
Task 3: Test-Coverage für bestehende Komponenten
Du hast 5 Komponenten ohne Tests. Composer schreibt sie:
For each component in @src/components/forms/ that doesn't have a corresponding .test.tsx, generate a Jest + RTL test file. Cover: rendering, prop validation, basic user interaction (click, change), and error states where applicable. Match the testing pattern used in @src/components/buttons/Button.test.tsx.
Wichtig: Verweis auf ein Beispiel (Button.test.tsx) — Composer adaptiert den dortigen Stil.
Task 4: Feature-Toggle einbauen
Add a feature flag system using @src/lib/featureFlags.ts. Replace all hardcoded if (process.env.NEXT_PUBLIC_ENABLE_X === 'true') checks with isFeatureEnabled('x'). Update the FeatureFlags interface to include all flags currently in use.
Wenn Composer scheitert
Composer hat seine Grenzen:
- Mehr als ~30 Dateien gleichzeitig: bricht oft mit Halluzinationen
- Unklare Anforderungen: er produziert dann generischen Code statt projekt-spezifischem
- Architektur-Entscheidungen: er entscheidet, aber nicht immer gut. Lieber selbst entscheiden und dann Composer ausführen lassen.
Best Practices
- Immer mit @-Mentions arbeiten: Konkret sagen, welche Datei oder welcher Ordner. Sonst rät Composer.
- Test-Driven mit Composer: Erst Tests schreiben lassen, dann Implementation. Verhindert Halluzinationen.
- Diff vor Apply prüfen: Composer zeigt Änderungen, bevor du committest. Niemals blind alle akzeptieren.
- Branch isolieren: Immer in einem separaten Git-Branch arbeiten. Erlaubt schnelles Reset, wenn Composer Mist baut.