Plan- vs. Act-Dual-Mode-Agent-Workflow in Cursor

Eine der größten Herausforderungen bei KI-Coding-Agenten ist es, sie davon abzuhalten, unbefugte Änderungen vorzunehmen. Der Plan- vs. Act-Dual-Mode-Workflow löst dies, indem der Agent Änderungen im "Plan-Modus" vorschlagen muss, bevor er sie im "Act-Modus" ausführt. Diese Anleitung zeigt Ihnen, wie Sie dieses leistungsstarke Sicherheitsmuster in Cursor implementieren.

Was ist Plan vs Act?

Plan-Modus (Schreibgeschützt)

Im Plan-Modus kann der Agent:

• Code lesen und analysieren
• Änderungen in einem strukturierten Format vorschlagen
• Keine Dateien modifizieren
• Einen detaillierten Plan zur Benutzerprüfung präsentieren

Act-Modus (Lesen-Schreiben)

Im Act-Modus kann der Agent:

• Nur genehmigte Änderungen ausführen
• Vollen Lese-Schreib-Zugriff haben
• Dem bereitgestellten genauen Plan folgen
• Berichten, was getan wurde

Warum dieses Muster verwenden?

Ohne Plan/Act	Mit Plan/Act
KI ändert Dateien unerwartet	Alle Änderungen erfordern eine Genehmigung
Schwierig zu überprüfen, was sich geändert hat	Zuerst wird ein klarer Plan präsentiert
Rollbacks sind schwierig	Änderungen sind nachvollziehbar und reversibel
Kontextdrift über lange Sitzungen	Fokussierte Ausführung pro Aufgabe

Implementierungsmethode 1: Cursor-Regeln

.cursor/rules/plan-act-workflow.mdc erstellen:

---
description: 'Plan- vs. Act-Dual-Mode-Workflow'
globs: ['**/*']
alwaysApply: true
---

# Plan- vs. Act-Workflow

## KRITISCHE REGEL
Sie DÜRFEN KEINE Dateien ohne ausdrückliche Benutzergenehmigung ändern.

## Plan-Modus (Standard)
Wenn eine Aufgabe gegeben wird:
1. RELEVANTE Dateien LESEN und analysieren
2. EINEN detaillierten Plan mit spezifischen Änderungen ERSTELLEN
3. DEN Plan in diesem Format PRÄSENTIEREN:

### Plan: [Aufgabenname]

#### Zu ändernde Dateien
- `file/path/one.ts` - Was zu ändern ist
- `file/path/two.ts` - Was zu ändern ist

#### Änderungszusammenfassung
1. Änderung 1 Beschreibung
2. Änderung 2 Beschreibung

#### Neue Dateien (falls vorhanden)
- `new/file/path.ts` - Zweck

#### Testplan
- Wie zu überprüfen, dass Änderungen funktionieren

4. WARTEN, bis der Benutzer "PROCEED" oder "ACT" eingibt

## Act-Modus (nach Genehmigung)
Nur nachdem der Benutzer "PROCEED" gesagt hat:
1. Änderungen aus dem Plan implementieren
2. NUR die genehmigten Änderungen vornehmen
3. Fertigstellung mit Dateiliste berichten
4. Testschritte vorschlagen

## NIEMALS
- Die Planungsphase überspringen
- Ungeplante Änderungen hinzufügen
- Dateien im Plan-Modus ändern
- Mehr als einmal pro Plan um Genehmigung bitten

Implementierungsmethode 2: Benutzerdefinierter Modus

Einen benutzerdefinierten Modus in den Cursor-Einstellungen erstellen:

1. Cursor-Einstellungen öffnen (Cmd/Ctrl + ,)
2. Zu "Modes" oder "AI Features" navigieren
3. Auf "Add Custom Mode" klicken
4. Konfigurieren:

{
  "name": "Planner",
  "description": "Planungsmodus - schreibgeschützte Analyse",
  "systemPrompt": "Sie befinden sich im PLANUNGSMODUS. Sie können Dateien LESEN, aber NIE ändern. Analysieren Sie die Codebasis, verstehen Sie die Anforderungen, und präsentieren Sie einen detaillierten Plan. Warten Sie auf Benutzergenehmigung, bevor Sie Änderungen vornehmen.",
  "tools": ["read", "grep", "search"],
  "fileWrite": false
}

{
  "name": "Executor",
  "description": "Ausführungsmodus - genehmigte Änderungen implementieren",
  "systemPrompt": "Sie befinden sich im AUSFÜHRUNGSMODUS. Implementieren Sie NUR die Änderungen, die im Plan genehmigt wurden. Weichen Sie nicht vom genehmigten Umfang ab. Berichten Sie jede Änderung, während Sie sie vornehmen.",
  "tools": ["read", "write", "edit"],
  "fileWrite": true
}

Implementierungsmethode 3: Chat-basierter Workflow

Schritt 1: Im Plan-Modus starten

[PLAN MODE] Ich muss dieser App eine Benutzerauthentifizierung hinzufügen.
Bitte analysieren Sie die Codebasis und erstellen Sie einen Plan.
Nehmen Sie NOCH KEINE Änderungen vor.

Schritt 2: Agent präsentiert Plan

## Plan: Benutzerauthentifizierung hinzufügen

### Zu ändernde Dateien
1. `src/app.ts` - Auth-Middleware hinzufügen
2. `src/routes/users.ts` - Login/Register-Endpunkte hinzufügen
3. `src/models/user.ts` - Passwort-Hashing hinzufügen

### Neue Dateien
1. `src/middleware/auth.ts` - JWT-Verifizierung
2. `src/services/auth.ts` - Auth-Logik
3. `tests/auth.test.ts` - Unit-Tests

### Implementierungsdetails
- bcrypt für Passwort-Hashing verwenden
- JWT-Tokens mit 15min Ablauf
- Refresh-Token-Rotation

### Tests
- Login mit gültigen/ungültigen Anmeldedaten testen
- Token-Refresh testen
- Geschützte Routen testen

Schritt 3: Überprüfen und genehmigen

Sie überprüfen den Plan und entweder:

• PROCEED eingeben, um zu genehmigen
• Modifikationen anfordern
• Ablehnen und von vorne beginnen

Schritt 4: Ausführen

[ACT MODE] PROCEED mit dem Authentifizierungsplan.
Implementieren Sie genau das, was genehmigt wurde.

Schritt 5: Überprüfung

Nach der Ausführung:

Überprüfen Sie, dass alle Änderungen korrekt vorgenommen wurden:
1. Prüfen, ob Auth-Middleware angewendet ist
2. Login-Endpunkt testen
3. Auth-Tests ausführen

Erweitert: Automatisierte Plan-Parsung

Für komplexe Projekte ein strukturiertes Planformat verwenden:

## Plan ID: AUTH-001
## Status: AUSSTEHENDE_GENEHMIGUNG
## Priorität: HOCH
## Geschätzte Zeit: 30 Minuten

### Umfang
- JWT-basierte Authentifizierung hinzufügen
- Login/Logout/Register implementieren
- Passwort-Reset-Flow hinzufügen

### Änderungen

#### Datei: src/middleware/auth.ts (NEU)
```typescript
import jwt from 'jsonwebtoken';

export const verifyToken = (req, res, next) => {
  // Implementierung
};

Datei: src/routes/auth.ts (NEU)

// Login-, Register-, Logout-Endpunkte

Datei: src/app.ts (ÄNDERN)

• Zeile 15: app.use('/auth', authRoutes) hinzufügen

Rollback

• Löschen: src/middleware/auth.ts
• Löschen: src/routes/auth.ts
• Zurücksetzen: src/app.ts Zeile 15

Tests

• Login mit gültigen Anmeldedaten
• Login mit ungültigen Anmeldedaten
• Geschützte Route ohne Token aufrufen
• Geschützte Route mit gültigem Token aufrufen

## Integration mit Versionskontrolle

### Pre-Execution-Checkpoint

Bevor ein Plan ausgeführt wird:

```bash
# Checkpoint-Branch erstellen
git checkout -b plan/auth-implementation

# Aktuellen Stand committen
git add -A && git commit -m "checkpoint: vor Auth-Implementierung"

Post-Execution-Verifizierung

# Änderungen überprüfen
git diff

# Falls etwas nicht stimmt, zurücksetzen
git checkout -- .

# Oder zum Checkpoint zurückkehren
git reset --hard HEAD~1

Team-Workflow

Für Code-Reviews

1. Entwickler erstellt Plan in Cursor
2. Entwickler fügt Plan in die PR-Beschreibung ein
3. Reviewer genehmigt Plan vor Ausführung
4. Entwickler führt mit Plan-vs-Act-Workflow aus
5. Reviewer verifiziert, dass Ausführung dem Plan entspricht

PR-Template

## Plan
[Hier den KI-generierten Plan einfügen]

## Ausführung
- [ ] Alle geplanten Änderungen implementiert
- [ ] Keine ungeplanten Modifikationen
- [ ] Tests bestehen
- [ ] Plan entspricht Ausführung

## Verifizierung
[Beschreibung der durchgeführten Tests]

Häufige Fallstricke

Fallstrick	Lösung
Agent überspringt Planung	Mit Regeln und Mode-Beschränkungen durchsetzen
Pläne sind zu vage	Spezifische Dateipfade und Zeilennummern verlangen
Benutzergenehmigungs-Ermüdung	Verwandte Änderungen in einzelne Pläne gruppieren
Ausführung weicht vom Plan ab	Diff nach Ausführung mit Plan vergleichen
Zu viel Hin und Her	Kleine Abweichungen erlauben, große markieren

Schnellstart-Checkliste

• .cursor/rules/plan-act-workflow.mdc erstellen
• Mit einer kleinen, sicheren Aufgabe testen
• Verifizieren, dass der Agent den Schreibschutz-Modus respektiert
• Genehmigen und Ablehnen von Plänen üben
• Git-Checkpoints vor Ausführung einrichten
• Den Workflow für Ihr Team dokumentieren

Verwandte Ressourcen

• Cursor Agent Mode Masterclass
• Cursor-Regeln effektiv nutzen
• Cursor Self-Review Hooks Guide