Plan-Modus: Awesome Skill Forge

Plan-Modus

Verwende diese Skill, wenn der Benutzer einen Plan anstelle einer Ausführung wünscht.

Kernverhalten

Für diese Runde planst du nur.

• Implementiere keinen Code.
• Bearbeite keine Projektdateien außer der Plan-Markdown-Datei.
• Führe keine mutierenden Terminalbefehle aus, committe nicht, pushe nicht und führe keine externen Aktionen durch.
• Du darfst das Repository oder andere Kontexte mit schreibgeschützten Befehlen/Werkzeugen bei Bedarf inspizieren.
• Deine Ausgabe ist ein Markdown-Plan, der im aktiven Arbeitsbereich unter .hermes/plans/ gespeichert wird.

Ausgabeanforderungen

Schreibe einen Markdown-Plan, der konkret und umsetzbar ist.

Füge, wenn relevant, Folgendes ein:

• Ziel
• Aktueller Kontext / Annahmen
• Vorgeschlagener Ansatz
• Schritt-für-Schritt-Plan
• Dateien, die sich wahrscheinlich ändern
• Tests / Validierung
• Risiken, Abwägungen und offene Fragen

Wenn die Aufgabe Code betrifft, füge genaue Dateipfade, wahrscheinliche Testziele und Verifikationsschritte ein.

Speicherort

Speichere den Plan mit write_file unter:

• .hermes/plans/JJJJ-MM-TT_HHMMSS-<slug>.md

Behandle dies als relativ zum aktiven Arbeitsverzeichnis / Backend-Arbeitsbereich. Hermes-Dateiwerkzeuge sind backend-bewusst, sodass die Verwendung dieses relativen Pfads den Plan im Arbeitsbereich auf lokalen, Docker-, SSH-, Modal- und Daytona-Backends hält.

Wenn die Laufzeit einen bestimmten Zielpfad vorgibt, verwende diesen genauen Pfad. Wenn nicht, erstelle selbst einen sinnvollen Zeitstempel-Dateinamen unter .hermes/plans/.

Interaktionsstil

• Wenn die Anfrage klar genug ist, schreibe den Plan direkt.
• Wenn keine explizite Anweisung /plan folgt, leite die Aufgabe aus dem aktuellen Gesprächskontext ab.
• Wenn sie wirklich zu unbestimmt ist, stelle eine kurze klärende Frage anstatt zu raten.
• Gib nach dem Speichern des Plans kurz an, was du geplant hast und den gespeicherten Pfad.

---

Den Plan gut schreiben

Der Rest dieser Skill ist die Kunst, einen guten Implementierungsplan zu verfassen – den Inhalt, der in die obige Markdown-Datei kommt.

Übersicht

Schreibe umfassende Implementierungspläne unter der Annahme, dass der Umsetzer null Kontext für die Codebasis und fragwürdigen Geschmack hat. Dokumentiere alles, was sie brauchen: welche Dateien zu bearbeiten sind, vollständigen Code, Testbefehle, zu prüfende Dokumentation, wie zu verifizieren ist. Gib ihnen häppchenweise Aufgaben. DRY. YAGNI. TDD. Häufige Commits.

Gehe davon aus, dass der Umsetzer ein erfahrener Entwickler ist, aber fast nichts über das Werkzeugset oder die Problemdomäne weiß. Gehe davon aus, dass er gutes Testdesign nicht sehr gut kennt.

Kernprinzip: Ein guter Plan macht die Implementierung offensichtlich. Wenn jemand raten muss, ist der Plan unvollständig.

Wann ein vollständiger Implementierungsplan hilft

Immer vorher verwenden:

• Implementierung mehrstufiger Funktionen
• Zerlegung komplexer Anforderungen
• Delegation an Unteragenten mittels subagent-driven-development

Nicht überspringen, wenn:

• Die Funktion scheint einfach (Annahmen verursachen Fehler)
• Du planst, sie selbst zu implementieren (dein zukünftiges Ich braucht Anleitung)
• Du allein arbeitest (Dokumentation ist wichtig)

Häppchenweise Aufgabengranularität

Jede Aufgabe = 2-5 Minuten fokussierte Arbeit.

Jeder Schritt ist eine Aktion:

• „Den fehlschlagenden Test schreiben“ — Schritt
• „Ausführen, um sicherzustellen, dass er fehlschlägt“ — Schritt
• „Den minimalen Code implementieren, um den Test zu bestehen“ — Schritt
• „Die Tests ausführen und sicherstellen, dass sie bestehen“ — Schritt
• „Committen“ — Schritt

Zu groß:

### Aufgabe 1: Authentifizierungssystem bauen
[50 Zeilen Code über 5 Dateien]

Richtige Größe:

### Aufgabe 1: User-Modell mit E-Mail-Feld erstellen
[10 Zeilen, 1 Datei]

### Aufgabe 2: Passwort-Hash-Feld zu User hinzufügen
[8 Zeilen, 1 Datei]

### Aufgabe 3: Passwort-Hash-Dienstprogramm erstellen
[15 Zeilen, 1 Datei]

Plan-Dokumentenstruktur

Kopfbereich (Erforderlich)

Jeder Plan MUSS beginnen mit:

# [Funktionsname] Implementierungsplan

> **Für Hermes:** Verwende die Skill subagent-driven-development, um diesen Plan Aufgabe für Aufgabe zu implementieren.

**Ziel:** [Ein Satz, der beschreibt, was dies baut]

**Architektur:** [2-3 Sätze zum Ansatz]

**Tech-Stack:** [Wichtige Technologien/Bibliotheken]

---

Aufgabenstruktur

Jede Aufgabe folgt diesem Format:

### Aufgabe N: [Beschreibender Name]

**Ziel:** Was diese Aufgabe erreicht (ein Satz)

**Dateien:**
- Erstellen: `exakter/pfad/zu/neuer_datei.py`
- Ändern: `exakter/pfad/zu/existierender.py:45-67` (Zeilennummern, falls bekannt)
- Test: `tests/pfad/zu/test_datei.py`

**Schritt 1: Fehlschlagenden Test schreiben**

```python
def test_spezifisches_verhalten():
    ergebnis = funktion(eingabe)
    assert ergebnis == erwartet
```

**Schritt 2: Test ausführen, um Fehlschlag zu verifizieren**

Ausführen: `pytest tests/pfad/test.py::test_spezifisches_verhalten -v`
Erwartet: FAIL – „function not defined"

**Schritt 3: Minimale Implementierung schreiben**

```python
def funktion(eingabe):
    return erwartet
```

**Schritt 4: Test ausführen, um Bestehen zu verifizieren**

Ausführen: `pytest tests/pfad/test.py::test_spezifisches_verhalten -v`
Erwartet: PASS

**Schritt 5: Committen**

```bash
git add tests/pfad/test.py src/pfad/datei.py
git commit -m "feat: spezifisches Feature hinzufügen"
```

Schreibprozess

Schritt 1: Anforderungen verstehen

Lies und verstehe:

• Funktionsanforderungen
• Design-Dokumente oder Benutzerbeschreibung
• Abnahmekriterien
• Einschränkungen

Schritt 2: Codebasis erkunden

Verwende Hermes-Werkzeuge, um das Projekt zu verstehen:

# Projektstruktur verstehen
search_files("*.py", target="files", path="src/")

# Ähnliche Funktionen suchen
search_files("ähnliches_muster", path="src/", file_glob="*.py")

# Vorhandene Tests prüfen
search_files("*.py", target="files", path="tests/")

# Schlüsseldateien lesen
read_file("src/app.py")

Schritt 3: Ansatz entwerfen

Entscheide:

• Architekturmuster
• Dateiorganisation
• Benötigte Abhängigkeiten
• Teststrategie

Schritt 4: Aufgaben schreiben

Erstelle Aufgaben in dieser Reihenfolge:

1. Setup/Infrastruktur
2. Kernfunktionalität (TDD für jede)
3. Randfälle
4. Integration
5. Aufräumarbeiten/Dokumentation

Schritt 5: Vollständige Details hinzufügen

Füge für jede Aufgabe Folgendes ein:

• Genaue Dateipfade (nicht „die Konfigurationsdatei" sondern src/config/settings.py)
• Vollständige Codebeispiele (nicht „Validierung hinzufügen" sondern den tatsächlichen Code)
• Genaue Befehle mit erwarteter Ausgabe
• Verifikationsschritte, die beweisen, dass die Aufgabe funktioniert

Schritt 6: Plan überprüfen

Prüfe:

• Aufgaben sind sequenziell und logisch
• Jede Aufgabe ist häppchenweise (2-5 Min)
• Dateipfade sind exakt
• Codebeispiele sind vollständig (kopierbar)
• Befehle sind exakt mit erwarteter Ausgabe
• Kein fehlender Kontext
• DRY-, YAGNI-, TDD-Prinzipien angewendet

Prinzipien

DRY (Wiederhole dich nicht)

Schlecht: Validierung an 3 Stellen kopieren Gut: Validierungsfunktion extrahieren, überall verwenden

YAGNI (Du wirst es nicht brauchen)

Schlecht: „Flexibilität" für zukünftige Anforderungen hinzufügen Gut: Nur das implementieren, was jetzt nötig ist

# Schlecht – YAGNI-Verstoß
class Benutzer:
    def __init__(self, name, email):
        self.name = name
        self.email = email
        self.einstellungen = {}  # Noch nicht nötig!
        self.metadaten = {}     # Noch nicht nötig!

# Gut – YAGNI
class Benutzer:
    def __init__(self, name, email):
        self.name = name
        self.email = email

TDD (Testgetriebene Entwicklung)

Jede Aufgabe, die Code produziert, sollte den vollständigen TDD-Zyklus enthalten:

1. Fehlschlagenden Test schreiben
2. Ausführen, um Fehlschlag zu verifizieren
3. Minimalen Code schreiben
4. Ausführen, um Bestehen zu verifizieren

Siehe die Skill test-driven-development für Details.

Häufige Commits

Committe nach jeder Aufgabe:

git add [dateien]
git commit -m "typ: beschreibung"

Häufige Fehler

Vage Aufgaben

Schlecht: „Authentifizierung hinzufügen" Gut: „User-Modell mit E-Mail- und Passwort-Hash-Feldern erstellen"

Unvollständiger Code

Schlecht: „Schritt 1: Validierungsfunktion hinzufügen" Gut: „Schritt 1: Validierungsfunktion hinzufügen" gefolgt vom vollständigen Funktionscode

Fehlende Verifikation

Schlecht: „Schritt 3: Testen, ob es funktioniert" Gut: „Schritt 3: pytest tests/test_auth.py -v ausführen, erwartet: 3 bestanden"

Fehlende Dateipfade

Schlecht: „Die Modelldatei erstellen" Gut: „Erstellen: src/models/user.py"

Ausführungsübergabe

Nach dem Speichern des Plans biete den Ausführungsansatz an:

„Plan vollständig und gespeichert. Bereit zur Ausführung mittels subagent-driven-development – ich werde einen frischen Unteragenten pro Aufgabe mit zweistufiger Überprüfung (Spezifikationskonformität, dann Codequalität) entsenden. Soll ich fortfahren?"

Verwende bei der Ausführung die Skill subagent-driven-development:

• Frische delegate_task pro Aufgabe mit vollständigem Kontext
• Spezifikationskonformitätsprüfung nach jeder Aufgabe
• Codequalitätsprüfung nach Bestehen der Spezifikation
• Nur fortfahren, wenn beide Prüfungen genehmigen

Erinnere dich

Häppchenweise Aufgaben (2-5 Min jede)
Exakte Dateipfade
Vollständiger Code (kopierbar)
Genaue Befehle mit erwarteter Ausgabe
Verifikationsschritte
DRY, YAGNI, TDD
Häufige Commits

Ein guter Plan macht die Implementierung offensichtlich.