---
name: grilling
description: Nimm den Nutzer zu einem Plan, einer Entscheidung oder einer Idee schonungslos ins Kreuzverhör. Einsetzen, wenn er sein Denken auf die Probe stellen will oder eine 'grill'-Formulierung benutzt.
---

Befrage mich schonungslos zu jedem Aspekt davon, bis wir ein gemeinsames Verständnis erreicht haben. Geh jeden Ast des Entscheidungsbaums ab und löse die Abhängigkeiten zwischen den Entscheidungen eine nach der anderen auf. Nenne zu jeder Frage deine empfohlene Antwort.

Stell die Fragen einzeln und warte auf meine Antwort, bevor du weitermachst. Mehrere Fragen auf einmal sind verwirrend.

Wenn sich eine Tatsache durch Erkunden der Umgebung finden lässt (Dateisystem, Werkzeuge und so weiter), schlag sie nach, statt mich zu fragen. Die Entscheidungen gehören aber mir — leg mir jede einzelne vor und warte auf meine Antwort.

Handle nicht danach, bevor ich bestätigt habe, dass wir ein gemeinsames Verständnis erreicht haben.

---
name: systematic-debugging
description: Einsetzen bei jedem Bug, Testfehler oder unerwarteten Verhalten — bevor Fixes vorgeschlagen werden
---

# Systematisches Debugging

Grundsatz: IMMER die Ursache finden, bevor ein Fix versucht wird. Symptom-Fixes sind ein Fehlschlag.

## Das eiserne Gesetz

KEINE FIXES OHNE VORHERIGE URSACHENFORSCHUNG

Wer Phase 1 nicht abgeschlossen hat, darf keine Fixes vorschlagen.

## Besonders dann einsetzen, wenn
- Zeitdruck herrscht (Notfälle machen Raten verlockend)
- „nur ein schneller Fix“ naheliegend scheint
- schon mehrere Fixes probiert wurden

## Nicht überspringen, wenn
- das Problem einfach wirkt (auch einfache Bugs haben Ursachen)
- es eilt (Hetze garantiert Nacharbeit)

---
name: requesting-code-review
description: Einsetzen beim Abschluss von Aufgaben, bei grösseren Features und vor dem Merge — prüft, ob die Arbeit die Anforderungen erfüllt
---

# Code-Review anfordern

Einen Review-Subagenten losschicken, der Probleme fängt, bevor sie sich fortpflanzen. Der Reviewer bekommt einen eigens gebauten Kontext zur Beurteilung, niemals den Verlauf der laufenden Session.

Grundsatz: Früh reviewen, oft reviewen.

## Pflicht
- Nach jeder Aufgabe in der Subagenten-Entwicklung
- Nach einem abgeschlossenen grösseren Feature
- Vor dem Merge nach main

## Auf das Feedback reagieren
- Kritische Punkte sofort beheben
- Wichtige Punkte vor dem Weiterarbeiten beheben
- Kleinigkeiten für später notieren
- Widersprechen, wenn der Reviewer falsch liegt (mit Begründung)

---
description: Session-Start — letzten Stand aus dem Vault holen und Top-3 Next Steps vorschlagen
---

# /morgen — Session-Start

Du holst den Kontext der letzten Session aus dem Vault und briefst den User in unter 15 Zeilen.

### 3. Branch-Realität prüfen
- `git status` — stimmt der Stand aus `aktueller-stand.md` noch?
- `git log --oneline -5` — gab es Commits seit letzter Daily-Note?
- Bei Abweichung: Daily-Note ist die Wahrheit über Entscheidungen, git ist die Wahrheit über Code

## Verbote
- Keine Wiederholung der ganzen Daily-Note — nur die für heute relevanten Punkte
- Keine generischen "Lass uns starten"-Sätze — direkt mit Stand starten
- Top-3 müssen aus Daily-Note + project_*.md ableitbar sein, nicht erfunden
- Wenn die letzte Daily-Note älter als 5 Tage ist: explizit erwähnen

---
description: Tagesabschluss — Daily-Note schreiben, Status-Snapshot updaten, Page-Steckbriefe pflegen
---

# /abend — Tagesabschluss

Du fasst die heutige Session zusammen und persistierst den Kontext in den Vault, damit morgen alles wieder abrufbar ist.

### 2. Daily-Note schreiben/ergänzen
### Gemacht
- Stichpunkte (mit Commit-Hashes wenn relevant)

### Offen / nächste Session
- [ ] Konkreter nächster Schritt mit Datei-Pfad
- [ ] Blocker / Wartepositionen

## Verbote
- Keine Daily-Note ohne Branch-/WIP-Stand
- User-Sektionen in `daily/YYYY-MM-DD.md` (oben) NIE überschreiben — nur unten anfügen
- Keine Emojis in Files erfinden — nur die Vault-Konventionen nutzen