RIPER-5 Erweiterter Agenten-Einschränkungsmodus für Cursor

RIPER-5 ist ein von der Community erstelltes Einschränkungs-Framework, das nachweislich KI-Halluzinationen und unbefugte Code-Änderungen drastisch reduziert. Ursprünglich für Claude 3.7 entwickelt, funktioniert es außergewöhnlich gut mit dem Agent-Modus von Cursor. Dieser Leitfaden erklärt die fünf Phasen und wie man sie implementiert.

Was ist RIPER-5?

RIPER-5 steht für:

Phase	Name	Zweck
R	Research (Recherche)	Informationen sammeln, ohne Änderungen vorzunehmen
I	Identify (Identifizieren)	Das genaue Problem oder die Anforderung lokalisieren
P	Plan (Planen)	Einen detaillierten, genehmigten Plan erstellen
E	Execute (Ausführen)	NUR den genehmigten Plan implementieren
R	Review (Überprüfen)	Die Implementierung verifizieren und testen

Die fünf Phasen im Detail

Phase 1: Recherche (R)

Regel: Schreibgeschützt. Keine Dateiänderungen erlaubt.

Aktionen:

• Relevante Dateien lesen
• Codebasis mit Grep durchsuchen
• Bestehende Muster analysieren
• Abhängigkeiten verstehen

Ausgabe: Forschungszusammenfassung mit Ergebnissen

## Recherchephase abgeschlossen

### Analysierte Dateien
- `src/auth/login.ts` - Aktueller Authentifizierungsablauf
- `src/middleware/auth.ts` - JWT-Verifizierung
- `tests/auth.test.ts` - Bestehende Tests

### Wichtige Erkenntnisse
1. Authentifizierung verwendet JWT mit 15-Minuten-Ablauf
2. Kein Refresh-Token-Mechanismus vorhanden
3. Passwort-Reset nicht implementiert
4. Tests decken Login, aber nicht Randfälle ab

### Abhängigkeiten
- jsonwebtoken: ^9.0.0
- bcrypt: ^5.1.0

Phase 2: Identifizieren (I)

Regel: Definieren Sie die genaue Problemstellung.

Aktionen:

• Das Problem klar formulieren
• Akzeptanzkriterien definieren
• Einschränkungen identifizieren
• Potenzielle Risiken notieren

Ausgabe: Problembeschreibungsdokument

## Problembestimmung

### Problemstellung
Benutzer werden nach 15 Minuten abgemeldet und müssen sich erneut authentifizieren.
Dies schafft eine schlechte UX für langlaufende Sitzungen.

### Ursache
JWT-Tokens laufen nach 15 Minuten ohne Refresh-Mechanismus ab.

### Akzeptanzkriterien
- [ ] Benutzer bleiben 7 Tage angemeldet
- [ ] Refresh-Tokens rotieren bei jeder Verwendung
- [ ] Alte Refresh-Tokens werden ungültig
- [ ] Benutzer können alle Sitzungen widerrufen

### Einschränkungen
- Abwärtskompatibilität muss gewahrt bleiben
- Keine Breaking Changes in bestehender API
- Muss mit bestehender JWT-Middleware funktionieren

### Risiken
- Token-Diebstahl, wenn Refresh-Tokens kompromittiert werden
- Datenbankspeicher für Token-Verfolgung

Phase 3: Planen (P)

Regel: Erstellen Sie einen detaillierten, schrittweisen Plan.

Aktionen:

• Alle zu ändernden Dateien auflisten
• Genaue Änderungen pro Datei angeben
• Teststrategie definieren
• Rollback-Verfahren planen

Ausgabe: Detaillierter Implementierungsplan

## Implementierungsplan

### Zu ändernde Dateien

#### 1. `src/models/refresh-token.ts` (NEU)
```typescript
// Schema für Refresh-Tokens
// Felder: id, userId, token, createdAt, expiresAt, revoked

2. src/services/auth.ts (ÄNDERN)

• Funktion createRefreshToken() hinzufügen
• Funktion rotateRefreshToken() hinzufügen
• Funktion revokeAllUserTokens() hinzufügen

3. src/routes/auth.ts (ÄNDERN)

• POST /refresh-Endpunkt hinzufügen
• POST /revoke-Endpunkt hinzufügen

4. src/middleware/auth.ts (ÄNDERN)

• JWT-Verifizierung aktualisieren, um längere Sitzungen zu unterstützen

Testplan

1. Unit-Tests für Token-Rotation
2. Integrationstests für Refresh-Ablauf
3. Sicherheitstests für Token-Widerruf

Rollback-Plan

1. Refresh-Token-Modell entfernen
2. Auth-Service-Änderungen rückgängig machen
3. Neue Endpunkte entfernen

### Phase 4: Ausführen (E)

**Regel**: Implementieren Sie NUR das, was geplant war.

**Aktionen**:
- Geplante Änderungen vornehmen
- Dem Plan genau folgen
- Fortschritt nach jeder Datei melden
- Stoppen, wenn der Plan überarbeitet werden muss

**Ausgabe**: Implementierung mit Fortschrittsverfolgung

```markdown
## Ausführungsphase

### Fortschritt
- [x] `src/models/refresh-token.ts` erstellt
- [x] `src/services/auth.ts` geändert
- [ ] `src/routes/auth.ts` ändern (in Bearbeitung)
- [ ] `src/middleware/auth.ts` aktualisieren

### Vorgenommene Änderungen
1. RefreshToken-Modell mit Feldern hinzugefügt
2. Token-Rotationslogik implementiert
3. Widerrufsunterstützung hinzugefügt

### Nächste Schritte
- Refresh-Endpunkt hinzufügen
- Middleware aktualisieren

Phase 5: Überprüfen (R)

Regel: Verifizieren Sie, dass alles wie geplant funktioniert.

Aktionen:

• Alle Tests ausführen
• Auf Regressionen prüfen
• Akzeptanzkriterien verifizieren
• Abweichungen dokumentieren

Ausgabe: Überprüfungsbericht

## Überprüfungsphase

### Tests
- [x] Unit-Tests bestanden (15/15)
- [x] Integrationstests bestanden (8/8)
- [x] Sicherheitstests bestanden (5/5)

### Akzeptanzkriterien
- [x] Benutzer bleiben 7 Tage angemeldet
- [x] Refresh-Tokens rotieren bei jeder Verwendung
- [x] Alte Refresh-Tokens werden ungültig
- [x] Benutzer können alle Sitzungen widerrufen

### Regressionen
- Keine festgestellt

### Abweichungen vom Plan
- Token-Cleanup-Cron-Job hinzugefügt (nicht im ursprünglichen Plan)
- Grund: Verhindert Datenbank-Aufblähung durch abgelaufene Tokens

Einrichtung von RIPER-5 in Cursor

Schritt 1: Die Regeldatei erstellen

Erstellen Sie .cursor/rules/riper5-mode.mdc:

---
description: 'RIPER-5 erweiterter Einschränkungsmodus'
globs: ['**/*']
alwaysApply: true
---

# RIPER-5 Modus

Sie MÜSSEN den RIPER-5-Workflow für ALLE Aufgaben befolgen.

## Phasensequenz
1. **Recherche** - Nur lesen und analysieren
2. **Identifizieren** - Problem definieren
3. **Planen** - Detaillierten Plan erstellen
4. **Ausführen** - Nur Plan implementieren
5. **Überprüfen** - Verifizieren und testen

## Phasenregeln

### Recherchephase
- Nur Read-, Grep-, Search-Tools verwenden
- KEINE Dateiänderungen
- KEINE Code-Generierung
- Ergebnisse in strukturiertem Format präsentieren

### Identifikationsphase
- Problem klar formulieren
- Akzeptanzkriterien definieren
- Einschränkungen auflisten
- Risiken identifizieren

### Planungsphase
- ALLE zu ändernden Dateien auflisten
- Genaue Änderungen für jede Datei anzeigen
- Teststrategie einschließen
- Rollback-Plan einschließen
- Auf Benutzerbestätigung WARTEN

### Ausführungsphase
- NUR geplante Änderungen implementieren
- Nach jeder Datei berichten
- Bei Problemen um Klärung bitten
- KEINE ungeplanten Änderungen

### Überprüfungsphase
- Alle Tests ausführen
- Akzeptanzkriterien verifizieren
- Auf Regressionen prüfen
- Abweichungen dokumentieren

## KRITISCH
- Phasen NIEMALS überspringen
- Dateien in der Recherchephase NIEMALS ändern
- In der Ausführungsphase NIEMALS ungeplante Änderungen hinzufügen
- Vor der Ausführungsphase IMMER eine Bestätigung einholen

Schritt 2: Zum System-Prompt hinzufügen

In den Cursor-Einstellungen:

## RIPER-5 Workflow

Für jede Aufgabe MÜSSEN Sie diese 5 Phasen befolgen:

1. **Recherche**: Lesen und analysieren, ohne Änderungen vorzunehmen
2. **Identifizieren**: Das genaue Problem definieren
3. **Planen**: Detaillierten Implementierungsplan erstellen
4. **Ausführen**: NUR den genehmigten Plan implementieren
5. **Überprüfen**: Verifizieren, dass alles funktioniert

Sie können nicht zur nächsten Phase übergehen, ohne die aktuelle abzuschließen.
Sie können während der Recherche- oder Identifikationsphase keine Dateien ändern.
Sie können während der Ausführungsphase keine ungeplanten Änderungen hinzufügen.

Schritt 3: Mit einer einfachen Aufgabe üben

Beginnen Sie mit einer kleinen Aufgabe, um sich vertraut zu machen:

[Aufgabe] Fügen Sie eine Hilfsfunktion zum Formatieren von Daten hinzu.

Befolgen Sie RIPER-5:
1. Bestehende Datumsbehandlung recherchieren
2. Identifizieren, was benötigt wird
3. Die Implementierung planen
4. Nach meiner Bestätigung ausführen
5. Das Ergebnis überprüfen

Erweitert: RIPER-5 mit Checkpoints

Git-Integration

# Vor dem Start (Recherchephase)
git checkout -b feature/riper5-task
git commit -m "checkpoint: before RIPER-5 implementation"

# Nach der Recherchephase
git add research-notes.md
git commit -m "riper5: research complete"

# Nach der Planungsphase (vor Bestätigung)
git add plan.md
git commit -m "riper5: plan created, awaiting approval"

# Nach der Ausführungsphase
git add -A
git commit -m "riper5: implementation complete"

# Nach der Überprüfungsphase
git commit -m "riper5: review passed, tests green"

Effektivität messen

Verfolgen Sie diese Metriken:

Metrik	Vor RIPER-5	Nach RIPER-5
Unbefugte Änderungen	Hoch	Fast Null
Plan-Genehmigungsrate	N/A	>90%
Testbestehensrate nach Änderungen	60%	95%
Rollback-Häufigkeit	Hoch	Niedrig
Benutzerzufriedenheit	Gemischt	Hoch

Häufige Herausforderungen

Herausforderung	Lösung
Agent überspringt Phasen	Mit strengen Regeln durchsetzen
Pläne sind zu breit gefasst	Datei-Level-Spezifität erfordern
Überprüfung ist oberflächlich	Testausführung vorschreiben
Verlangsamt einfache Aufgaben	Abkürzungen für triviale Änderungen erlauben

Kurzreferenz

[RIPER-5 START]

Phase 1/5: Recherche
[Agent liest und analysiert]

Phase 2/5: Identifizieren
[Agent definiert Problem]

Phase 3/5: Planen
[Agent erstellt Plan]
[Benutzer: BESTÄTIGEN oder ÄNDERN]

Phase 4/5: Ausführen
[Agent implementiert]

Phase 5/5: Überprüfen
[Agent verifiziert]

[RIPER-5 ABGESCHLOSSEN]

Verwandte Ressourcen

• Cursor Agent Mode Masterclass
• Plan vs Act Dual-Mode Workflow
• Cursor Self-Review Hooks Guide