Cursor Composer – Komplettanleitung: Multi-Datei-Bearbeitung und Praxisbeispiele

Drei Monate Cursor – und ich habe die Hälfte der Zeit „verschwendet“.

Früher brauchte ich für eine Funktion fünf Dateien: Komponente, API, Typdefinitionen, Tests, Konfiguration. Im Chat fragte ich Datei für Datei, kopierte und fügte Code ein. Die Maus sprang zwischen Tabs, die Finger zwischen Cmd+C und Cmd+V. Erschöpfend.

Eines Tages schaute ein Kollege auf meinen Bildschirm und sagte nach drei Sekunden: „Warum nutzt du nicht Composer?“

„Hä?“

„Cmd+I – das schwebende Fenster. Eine Anweisung, die KI erkennt alle betroffenen Dateien und ändert alles auf einmal.“

Ich war sprachlos.

Er zeigte es mir: Composer öffnen, ein paar Dateien mit @ referenzieren, eingeben: „Login-Logik um E-Mail-Verifizierung erweitern“, Enter. Die KI dachte ein paar Sekunden nach und änderte Komponente, API und Typdefinitionen in einem Durchgang. Fertig in 10 Minuten.

Ich hatte dafür eine Stunde gebraucht.

In dem Moment wurde mir klar: Drei Monate lang hatte ich nur etwa 20 % von Cursor genutzt. Wie einen Ferrari nur im ersten Gang fahren.

Was ist Composer – und warum Sie es brauchen

Composer vs. Chat – der Kernunterschied

Zuerst eine Analogie.

Chat ist ein KI-Berater an Ihrer Seite. Sie fragen: „Wie optimiere ich diesen Code?“ – Sie bekommen Ratschläge und setzen selbst um.

Composer ist eine KI-Baukolonne. Sie sagen: „Alle Fenster im Gebäude zu bodentiefen Fenstern umbauen“ – sie legt los, ist fertig und sagt: „Bitte abnehmen.“

Der Kern: Berater vs. Baukolonne.

Der direkte Vergleich:

„Dialoghistorie nicht gespeichert“ – mein größter Fallstrick bisher. Später mehr dazu.

Die drei Kernfähigkeiten von Composer

Fähigkeit 1: Dateiübergreifendes Verständnis

Chat sieht nur die aktuell geöffnete Datei. Composer sieht das gesamte Projekt.

Beispiel: Sie sagen „Benutzer-Login hinzufügen“. Chat fragt: „Welche Datei genau?“ Composer antwortet: „Ich muss diese 5 Dateien ändern: Login.tsx, auth.ts, user.types.ts, api/auth.ts, App.tsx.“

Es weiß, wo Komponente, Typen, API und Routing liegen – und ändert alles zusammen.

Fähigkeit 2: Projektweite Änderungen

Bei Chat kopieren Sie Code manuell. Composer wendet Änderungen direkt an – Sie klicken nur Accept oder Reject.

Analogie: Chat liefert einen Renovierungsplan, Composer liefert die fertige Renovierung zur Abnahme.

Fähigkeit 3: Intelligentes Reasoning (Agent-Modus)

Mit Agent-Modus kann Composer:

• Shell-Befehle ausführen (z. B. npm install, git status)
• Die gesamte Codebase durchsuchen (alle Stellen mit einer Funktion finden)
• Abhängigkeiten selbst analysieren
• Dateien anlegen oder löschen

Agent-Modus ist wie ein Polier für die Baukolonne – mehr Autonomie, aber auch mehr „Überrenovierung“. Später: wie man das kontrolliert.

3 Szenarien, in denen Composer Pflicht ist

Szenario 1: Neues Feature (mehrere Dateien)

Aufgabe: Kommentarfunktion hinzufügen.

Mit Chat:

1. Fragen, welche Dateien betroffen sind
2. Liste mit 5 Dateien erhalten
3. Datei für Datei öffnen
4. „Schreib mir die Comments-Komponente“
5. Code kopieren und einfügen
6. „Schreib die Kommentar-API“
7. Kopieren, einfügen
8. Fünfmal wiederholen

Erschöpfend.

Mit Composer:

1. Composer öffnen (Cmd+I)
2. Eingeben: „Kommentarfunktion: erstellen, löschen, anzeigen“
3. Enter
4. KI erkennt betroffene Dateien und ändert alles
5. Diff prüfen, Accept

10 Minuten.

Szenario 2: Code-Refactoring

Aufgabe: State Management von Redux auf Zustand migrieren.

Mit Chat: praktisch unmöglich – 20+ Dateien, leicht etwas übersehen oder falsch ändern.

Mit Composer:

@src/store
@src/components

Redux Store auf Zustand migrieren:
1. Bestehende State-Struktur beibehalten
2. API unverändert lassen
3. Redux-Dependency entfernen

Agent-Modus an – KI analysiert Abhängigkeiten, ändert Dateien, prüft ob es läuft. 20 Minuten.

Szenario 3: Batch-Änderungen

Aufgabe: Einheitliche Fehlerbehandlung – try-catch für alle API-Aufrufe.

Mit Chat: Datei für Datei, leicht etwas vergessen.

Mit Composer:

@src/api

Einheitliche Fehlerbehandlung für alle API-Aufrufe:
- try-catch umschließen
- Einheitliches Fehlerformat
- Fehler loggen

15 Dateien in einem Durchgang.

Composer vs. Chat: Die 5-Sekunden-Entscheidungsregel

Sie kennen den Unterschied – trotzdem zögern Sie: Cmd+L oder Cmd+I?

Drei Schritte, fünf Sekunden.

Entscheidungsablauf

Schritt 1: Wie viele Dateien?

• 1 Datei → weiter
• 2+ Dateien → Composer

Dateiübergreifend = Composer.

Schritt 2: Frage stellen oder Code ändern?

• Frage (Lernen, Verstehen, Debug) → Chat
• Code ändern (Generieren, Anpassen, Refactoring) → Composer

Berater vs. Baukolonne.

Schritt 3: Wie groß die Änderung?

• Klein (wenige Zeilen) → Chat + Cmd+K
• Groß (ganzes Modul) → Composer

Variable umbenennen oder Kommentar hinzufügen – Cmd+K reicht.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

4 Szenarien für Chat

Szenario 1: Schnelle Frage

Sie: „Hat dieser Code einen Bug?“
Chat: „Ja, Zeile 12 – Array out of bounds“

Sofortige Antwort, kein Code-Change nötig.

Szenario 2: Verstehen und Lernen

Sie: „Erkläre mir diesen Algorithmus“
Chat: „Das ist Quicksort, Kernidee ist …“

Chat erklärt geduldig mit Beispielen.

Szenario 3: Single-File-Debug

Sie: „Optimiere diese Funktion“
Chat: „Memoization für Ergebnis-Cache …“

Sie setzen selbst um – kein Composer nötig.

Szenario 4: Code-Review

Sie: „Welche Risiken sehen Sie hier?“
Chat: „Zeile 15: null nicht behandelt, Zeile 28: Memory-Leak-Risiko …“

Chat findet viele Probleme.

4 Szenarien für Composer

Szenario 1: Neues Feature

Dateiübergreifende Implementierung – siehe oben.

Szenario 2: Refactoring

Große strukturelle Anpassungen:

• Große Dateien aufteilen
• Kleine Dateien zusammenführen
• Ordnerstruktur neu organisieren
• Namenskonventionen vereinheitlichen

Chat schafft das nicht.

Szenario 3: Dependency-Migration

Bibliothek oder Framework ersetzen:

• axios → fetch
• moment.js → dayjs
• styled-components → Tailwind CSS
• Redux → Zustand

Dutzende Dateien – Composers Terrain.

Szenario 4: Batch-Änderungen

Viele ähnliche Stellen:

• console.log → logger
• var → const
• Klassenkomponenten → Funktionskomponenten

3 Vergleichsbeispiele

Beispiel 1: API-Aufrufe ändern

Aufgabe: axios → fetch, 15 Dateien.

Chat: Datei für Datei, leicht etwas vergessen.

Composer: @src/api Alle axios-Aufrufe zu fetch – Batch-Änderung, Sie prüfen den Diff.

Fazit: Composer

Beispiel 2: Eine Funktion debuggen

Aufgabe: Bug in Preisberechnung, 1 Datei.

Chat: Code einfügen, sofort: „Zeile 12, Steuersatz sollte total * 0.1 sein.“

Composer: Overkill – warten, analysieren, anwenden.

Fazit: Chat

Beispiel 3: Benutzerberechtigungssystem

Aufgabe: RBAC, 10+ Dateien (Komponenten, Middleware, DB, API).

Chat: praktisch unmöglich – inkonsistente Logik wahrscheinlich.

Composer (Agent): „Rollenbasiertes Berechtigungssystem – Admin CRUD, normale User nur Lesen“ – KI erstellt Middleware, passt API und Komponenten an.

Fazit: Composer (Agent)

Composer richtig einrichten

Ersteinrichtung (3 Schritte)

Nach der Cursor-Installation: kurz einrichten, dann Composer nutzen.

Schritt 1: Modell wählen

Empfehlung: Claude 3.7 Sonnet.

Warum?

• Starke Reasoning-Fähigkeit für komplexe Multi-Datei-Beziehungen
• Niedrige Fehlerrate
• Gutes Verständnis, welche Dateien zusammengehören

o1 und o1-mini unterstützen Composer nicht – Cursor wechselt automatisch, Ergebnis oft schlechter.

Schritt 2: Agent-Modus (optional)

Cursor Settings → Beta → Agent.

Dann kann Composer:

• Shell-Befehle ausführen (npm install, git status)
• Codebase durchsuchen (Cmd+Enter)
• Dateien anlegen/löschen
• Projektstruktur analysieren

Wie ein Werkzeugkasten – aber auch mehr „Überbau“. Später: Kontrolle.

Schritt 3: Preismodell

• Free: Composer eingeschränkt, wenige Anfragen/Tag
• Pro: 500 Premium-Anfragen/Monat – für die meisten ausreichend
• Business: unbegrenzt

Als Power-User: Pro. Persönlich ca. 300–400 Anfragen/Monat.

Oberfläche im Überblick

┌─────────────────────────────────┐
│  Composer  [Normal] [Agent]     │  ← Moduswechsel
├─────────────────────────────────┤
│  📝 Eingabe (Anforderung)       │
│  @ Datei/Ordner/Code referenzieren│
├─────────────────────────────────┤
│  💬 Dialoghistorie              │
│  📄 Datei-Diff-Vorschau         │
│  ✅ Accept  ❌ Reject            │
└─────────────────────────────────┘

Oben rechts: Normal vs. Agent.

Diff-Vorschau unten zeigt jede Änderung. Nicht Accept All – dazu gleich mehr.

@-Referenzen – der Kern

@ ist Composers zentrales Feature.

@Files: bestimmte Datei

@src/components/Header.tsx
Komponente responsiv gestalten

Nur diese eine Datei – nichts anderes.

@Folders: ganzer Ordner

@src/utils
Tool-Bibliothek refactoren, nach Funktion aufteilen

Alle Dateien im Ordner – Struktur verstehen, dann refactoren.

@Code: Codeblock

Code markieren, Cmd+I – automatische Referenz:

@[markierte Funktion]
Performance dieser Funktion optimieren

Ideal für lokale Optimierung.

@Web: Webseiteninhalt

@https://docs.react.dev/reference/react/useEffect
Effect nach React-Dokumentation Best Practices refactoren

KI liest die Seite und folgt den offiziellen Empfehlungen.

@Docs: Projektdokumentation

@README.md
Feature laut Dokumentation implementieren

Bei Team-Standards: @Docs, KI hält sich daran.

@Codebase: gesamte Codebase

Cmd+Enter:

Alle localStorage-Nutzungen finden und auf IndexedDB umstellen

Im Agent-Modus: Suche im ganzen Projekt, alles zusammen ändern.

Normal vs. Agent

Normal-Modus:

• Klare, abgegrenzte Aufgaben
• Nur von Ihnen referenzierte Dateien
• Kontrollierbar, weniger Überraschungen
• Schneller
• Weniger Token

Agent-Modus:

• Komplexe, reasoning-intensive Aufgaben
• Selbstständige Suche, Befehle, Dateien anlegen
• Intelligenter, Scope kann wachsen
• Langsamer
• Mehr Token

Empfehlung:

Einfach → Normal („Stil dieser Komponente ändern“, „Fehlerbehandlung hinzufügen“).

Komplexes Refactoring → Agent („Redux → Zustand“, „Berechtigungssystem“).

Unsicher → zuerst Normal, dann Agent.

Persönlich: 80 % Normal, 20 % Agent.

5 Goldene Regeln für Multi-Datei-Edits

Viele Fallstricke – 5 Regeln, die 90 % der Probleme vermeiden.

Regel 1: Aufgaben aufteilen

❌ Falsch:

„Gesamtes Projekt refactoren: TypeScript, Performance, Tests“

Composer weiß nicht, wo anfangen – Ergebnis chaotisch, 2 Stunden Rollback.

✅ Richtig – 4 Dialoge:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

1: „Alle Dateien in src/utils auf TypeScript umstellen“
2: „Unit-Tests für utils hinzufügen“
3: „Header-Komponente performance-optimieren“
4: „API-Aufrufe vereinheitlichen, Fehlerbehandlung“

Kleines Ziel pro Durchlauf, git commit – klar, kontrollierbar, rollback-fähig.

Warum aufteilen?

• Weniger Missverständnis (zu viel auf einmal)
• Kleinere Diffs, leichter zu prüfen
• Fehler nur einen Schritt betreffen
• Weniger Token

Erfahrung: maximal 10 Dateien pro Composer-Dialog. Darüber: aufteilen.

Regel 2: Scope klar definieren

Mit @-Referenzen den Bereich festlegen.

Beispiel User-Feature:

@src/components/User
@src/types/user.ts
@src/api/user.ts

User-API von RESTful auf GraphQL umstellen

Nur diese 3 Stellen – sonst nichts.

Ohne Scope: KI ändert Drittanbieter-APIs mit – Projekt bricht.

Vorteile:

• Keine versehentlichen Dateien
• Kontrollierbare Änderungen
• Weniger Überraschungen

Gewohnheit: Erster Schritt immer @-Referenzen.

Regel 3: Diff einzeln prüfen

Nach Composer: nicht Accept All.

Verlockend – 20 Dateien, ein Klick, fertig.

Aber …

Echtes Beispiel:

Anweisung: „Alle console.log durch eigenen Logger ersetzen.“

30 Dateien geändert. Accept All ohne Prüfung.

Ergebnis:

• console.log in node_modules gelöscht
• Debug-Code weg
• Projekt startet nicht

1 Stunde Rollback und manuelle Reparatur.

Richtiger Ablauf:

1. Diff-Vorschau jeder Datei
2. Zeile für Zeile prüfen
3. Einzeln Accept
4. Bei Problemen Reject, neu formulieren

Langsam – aber 90 % weniger Vorfälle.

Gewohnheit: Composer fertig → Kaffee → Diff in Ruhe prüfen.

Regel 4: Rechtzeitig committen

Nach jedem kleinen Schritt git commit.

# Nach einem Composer-Durchlauf
git add .
git commit -m "feat: migrate user API to GraphQL"

Warum wichtig?

Composer-Dialog geht bei Refresh verloren.

10 Dateien geändert, kein Commit, Tab abgestürzt – Sie wissen nicht mehr, was wo stand.

Mit Commit pro Schritt:

• Rollback: git reset --hard HEAD
• Nachvollziehbar: git log
• Dialog weg, Code bleibt

Rhythmus: Composer → Diff → Accept → git commit. Zur Gewohnheit werden lassen.

Regel 5: Kontext sichern

Problem:

Composer speichert Dialoghistorie nicht. Nach Refresh:

Sie: „Refactoring fortsetzen“ – KI: „Welches Refactoring?“

Lösungen:

Lösung 1: Screenshots

Vor komplexen Aufgaben Composer-Anweisung screenshotten. Bei Netzwerkausfall nachvollziehbar.

Lösung 2: Plan im Chat, Ausführung in Composer

Chat speichert Historie:

Chat:
Sie: „axios zu fetch migrieren – worauf achten?“
KI: „Fehlerbehandlung, Interceptors, Typen …“
Sie: „Migrationsplan bitte“
KI: „Schritt 1 … Schritt 2 …“

Plan bleibt – Schritt für Schritt in Composer umsetzen.

Lösung 3: README-Protokoll

## Refactoring-Protokoll 2026-01-10
- Aufgabe: axios → fetch
- Composer: „Alle axios-Aufrufe zu native fetch, gleiche Fehlerbehandlung“
- Dateien: src/api/*.ts
- Ergebnis: 15 Dateien migriert

Später nachvollziehbar, warum geändert wurde.

7 typische Fallstricke und Gegenmaßnahmen

Alles, was ich selbst erlebt habe – zum Vermeiden.

Fallstrick 1: Dialoghistorie nicht gespeichert

Problem:

Refresh – Dialog weg. Tab zu, Cursor abgestürzt – alles verloren.

Gegenmaßnahmen:

✅ Wichtige Anweisungen screenshotten
✅ Plan im Chat festhalten
✅ Commit-Message dokumentiert Absicht
✅ Komplexe Aufgaben in kleine Dialoge (max. 10 Dateien)

Fallstrick 2: Datei-Update unterbrochen

Problem:

Composer hängt – Netzwerk, Dienst, …

Teilweise geändert, teilweise nicht – halbfertiger Zustand.

Gegenmaßnahmen:

✅ Vorher git commit
✅ Stabiles Netzwerk (instabiles VPN vermeiden)
✅ Kleine Aufgaben, weniger Dateien
✅ git diff – was wirklich geändert wurde

2 Unterbrechungen erlebt: ohne Commit 2 Stunden Reparatur; mit Commit git reset in einer Sekunde.

Fallstrick 3: Automatischer Modellwechsel

Problem:

o1 unterstützt Composer nicht – Cursor wechselt still auf anderes Modell. Sie denken o1, es läuft GPT-4o.

Gegenmaßnahmen:

✅ Claude 3.7 Sonnet als Standard
✅ Modellname oben rechts prüfen
✅ Default in Cursor Settings setzen

Persönlich nur Claude 3.7 Sonnet – stabil, wenig Fehler.

Fallstrick 4: Kontextverlust

Problem:

1: „User-API auf GraphQL“
2: „Weiter, Comments-API auch“

KI: „Welche User-API?“

Gegenmaßnahmen:

✅ Jeden Dialog neu @-referenzieren
✅ „Auf Basis der letzten Änderung …“ explizit sagen
✅ Bei Bedarf neuer Dialog mit vollem Kontext

Gewohnheit: Jeden Dialog wie den ersten – Hintergrund klar beschreiben.

Fallstrick 5: Dateisuche fehlgeschlagen

Problem:

Cmd+Enter, „@Codebase alle axios-Stellen“ – KI: „Nicht gefunden.“

Sie haben 15 Dateien mit axios.

Gegenmaßnahmen:

✅ @Files statt Suche
✅ .cursorrules und .gitignore prüfen
✅ Große Projekte modular aufteilen

@Codebase in großen Repos unzuverlässig – ich nutze @Files.

Fallstrick 6: Agent-Modus zu aggressiv

Problem:

Agent erstellt unnötige Dateien, löscht wichtigen Code, Scope explodiert.

„User-Modul refactoren“ – ganzer src/user gelöscht und neu gebaut.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Gegenmaßnahmen:

✅ Komplexes zuerst im Normal-Modus
✅ Agent nur bei klaren Migrationen
✅ Diff einzeln, Unsinn Reject

Agent nur bei eindeutigen Aufgaben (Dependency-Migration).

Fallstrick 7: Zu wenig Speicherplatz

Problem:

Composer legt temporäre Dateien an. Bei voller Platte bricht Update ab – halbfertige Änderungen, kryptische Fehlermeldung.

Gegenmaßnahmen:

✅ node_modules, dist regelmäßig aufräumen
✅ Mindestens 5 GB frei
✅ df -h prüfen

Einmal passiert – lange gesucht, bis klar war: Festplatte voll.

Praxisbeispiel: axios → fetch API

Theorie reicht nicht – Schritt für Schritt.

Hintergrund:

• Projekt: Next.js-Blog
• Aufgabe: axios → native fetch
• 15 API-Dateien
• Manuell ~2 Stunden, mit Composer ~20 Minuten

Schritt 1: Plan im Chat

Nicht sofort Composer – zuerst im Chat:

Sie: axios komplett durch fetch ersetzen – worauf achten?

Chat:
1. fetch behandelt Fehler anders als axios – response.ok prüfen
2. fetch rejected bei 4xx/5xx nicht automatisch
3. Content-Type manuell setzen
4. Interceptors als Wrapper-Funktion

Empfehlung: zuerst fetchWrapper anlegen.

Plan: Wrapper, dann Batch-Ersetzung.

Schritt 2: fetchWrapper anlegen

Cmd+I:

@src/utils

fetchWrapper.ts anlegen – axios-ähnliche API:
- JSON automatisch
- Einheitliche Fehlerbehandlung
- Interceptors
- Kompatibel mit bestehenden axios-Aufrufen

Composer erstellt fetchWrapper.ts.

Prüfung:

• ✅ Typen vollständig
• ✅ Fehlerbehandlung korrekt
• ✅ API-Design sinnvoll

Accept.

git commit -m "feat: add fetchWrapper utility"

Schritt 3: Modul für Modul

Nicht 15 Dateien auf einmal – aufteilen.

Zuerst posts und comments:

@src/api/posts.ts
@src/api/comments.ts
@src/utils/fetchWrapper.ts

API-Aufrufe in posts und comments von axios auf fetchWrapper, gleiche Signaturen und Fehlerbehandlung.

3 Dateien geändert.

Schritt 4: Diff prüfen

Kritischster Schritt.

posts.ts:

• import axios → import { fetchWrapper } ✅
• axios.get() → fetchWrapper.get() ✅
• Fehlerbehandlung unverändert ✅
• Signaturen gleich ✅

Accept.

comments.ts: analog ✅ – Accept.

fetchWrapper.ts: Referenzen korrekt ✅

Schritt 5: Testen

npm run dev

Browser: Artikelliste, Detail, Kommentar erstellen/löschen – alles OK.

git commit -m "feat: migrate posts and comments API to fetch"

Schritt 6: Weitere Module

Schritte 3–5 wiederholen:

• users
• auth
• settings

Pro Modul: prüfen, testen, committen.

25 Minuten für alle 15 Dateien.

Eigene Fallstricke

Fallstrick 1: axios in node_modules mitgeändert

Ohne @Files – node_modules betroffen.

Lösung: „Nur src/, node_modules nicht anfassen.“

Fallstrick 2: Fehlerbehandlung verloren

fetch ≠ axios bei Fehlern.

Lösung: In Anweisung „gleiche Fehlerbehandlung, response.ok prüfen“.

Fallstrick 3: Typen unvollständig

TypeScript-Fehler an fetchWrapper.

Lösung: Typen im Chat generieren, mit Cmd+K in fetchWrapper.ts einfügen.

Ergebnis

✅ 15 Dateien migriert
✅ Alle APIs funktionieren
✅ ~25 Minuten inkl. Debug
✅ Code Review ohne Beanstandung
✅ Bundle kleiner: axios ~30 KB, fetch nativ

Manuell ~2 Stunden – Composer ~25 Minuten. Faktor 5.

Zusammenfassung

1. Komplexes zuerst im Chat planen
2. Schrittweise, git commit pro Schritt
3. Scope mit @ festlegen
4. Diff einzeln, kein Accept All
5. Testen, dann weiter

Gilt für alle Composer-Aufgaben.

Fazit

Mit Composer ist meine Effizienz mindestens verdreifacht.

Früher: Tabs wechseln, kopieren, Fehler, Vergessen. Erschöpfend.

Jetzt: eine Anweisung, KI findet alle Dateien, ich prüfe Diff und Accept. 10 Minuten.

5 Kernprinzipien:

1. Mehrere Dateien → Composer
   Dateiübergreifend nicht mit Chat Zeit verschwenden.

2. Klein halten → nicht alles auf einmal
   Max. 10 Dateien pro Dialog.

3. Diff einzeln → kein Accept All
   Langsam ist besser als ein Vorfall.

4. Rechtzeitig committen
   Dialog geht verloren, Code bleibt in Git.

5. Kontext sichern
   Screenshot, Chat-Plan, README – kombiniert.

Zwei Shortcuts:

• Cmd/Ctrl + L → Chat (Fragen)
• Cmd/Ctrl + I → Composer (Code ändern)

5-Sekunden-Regel:

Wie viele Dateien?
 → 1 → Frage oder Code?
    → Frage → Chat
    → Code → Wie groß?
       → Klein → Chat + Cmd+K
       → Groß → Composer
 → 2+ → Composer

Composer wirkt anfangs „zu autonom“ – mit den Regeln oben ist es kontrollierbar und sehr produktiv.

Jetzt ausprobieren:

1. Cursor öffnen, Cmd+I
2. Kleine Übung („Variablen umbenennen“, „Stil vereinheitlichen“)
3. Diese 5 Regeln und 7 Fallstricke griffbereit halten
4. Bei Multi-Datei-Änderungen zuerst an Composer denken

Nicht nur Chat.

Composer ist Cursors Kernstärke.

Probieren Sie es aus.