4.2 KiB
4.2 KiB
Agent Guidelines für ZellIDE
Projekt-Kontext
ZellIDE ist eine Terminal-basierte IDE-Umgebung für Tim, einen erfahrenen Software-Entwickler der von VSCode zurück ins Terminal möchte. Das Projekt kombiniert Zellij (Terminal-Multiplexer), Helix (Editor), Yazi (File-Manager) und lazygit zu einer integrierten Entwicklungsumgebung.
Lern- und Arbeits-Stil
Tim lernt am besten durch:
- Schrittweises Erweitern von Code-Snippets
- Konkrete Beispiele vor Theorie
- Mini-Challenges zum Festigen
- Learning by doing, nicht durch dicke Dokumentation
Wichtig beim Entwickeln:
- Pragmatische Lösungen vor komplexen Architekturen
- Ein Feature nach dem anderen
- Testen in echten Use-Cases (z.B. infrastructure-Repo)
- Keine Überladung mit zu vielen Optionen auf einmal
Technische Anforderungen
Umgebung
- OS: Linux (primär), auch für Remote-Server
- Shell: Zsh
- Package Manager: System-native (dnf, apt) + uv für Python
- VPN: Tailscale für Server-Zugriff
- Git: Forgejo auf zeus.turkey-court.ts.net
Bestehende Infrastruktur
- Mehrere Server: Zeus (Hetzner), Hephaistos, BigSister (Synology), rom-master-5000 (RPi5)
- Aktuell: tmux auf allen Servern (soll zu Zellij migriert werden)
- Linear für Projekt-Management
- Git-basierte Workflows
Ziel-Setup
- Lokale Entwicklung: ZellIDE mit vollem Feature-Set
- Remote-Server: Gleiche ZellIDE-Umgebung für Konsistenz
- Keine nested Sessions (Zellij in Zellij vermeiden)
Code-Richtlinien
Scripting
- Shell-Scripts: Bash (für Kompatibilität) oder Zsh (wenn zsh-spezifische Features genutzt werden)
- Kommentare: Auf Deutsch, Code-Variablen auf Englisch
- Fehlerbehandlung: Immer explizit prüfen, keine stillen Failures
- Debugging: Tim nutzt custom outputs statt Debugger
Konfigurationsdateien
- Format: KDL für Zellij, TOML für Helix
- Dokumentation: Inline-Kommentare für nicht-offensichtliche Optionen
- Pfade: Absolute Pfade vermeiden, ~/ nutzen wo möglich
Git-Workflow
- Branches: Main für stabile Features, Feature-Branches für Entwicklung
- Commits: Aussagekräftige Messages auf Deutsch
- Remote: zeus.turkey-court.ts.net/totlik/zellide.git
Kommunikations-Präferenzen
Bevorzugt:
- Du-Form (nicht formal)
- Rückfragen stellen bei Unklarheiten
- Schritt-für-Schritt-Erklärungen
- Konkrete Code-Beispiele
Vermeiden:
- Zu viele Optionen gleichzeitig präsentieren
- Theoretische Abhandlungen ohne Code
- Annehmen was Tim will - lieber nachfragen
- Überspringen von Zwischen-Schritten
Testing & Iteration
Test-Projekte
- Primär: ~/git/infrastructure (Ansible, Docker-Compose, Configs)
- Später: Rust-Projekte nach erfolgreicher IDE-Migration
Iterativer Prozess
- Kleine, testbare Einheit entwickeln
- Mit echtem Use-Case testen
- Feedback einholen
- Anpassen und erweitern
- Erst dann zum nächsten Feature
Erfolgs-Kriterien
- Fühlt sich flüssig an wie VSCode
- Keine nervigen Edge-Cases im täglichen Workflow
- Gleiche Erfahrung lokal und remote
- Tim kann seine Muscle-Memory aufbauen
Besondere Hinweise
Helix vs Vim
- Tim kommt von Vim-Bindings
- Helix verwendet selection-first statt verb-noun
- Geduld in der Umgewöhnungsphase
- Keybind-Referenzen bereitstellen
Session-Management
- Session-Namen sind wichtig für Übersicht
- Präfix-System konsequent nutzen
- Keine Session-Verschachtelung
- Auto-Cleanup von alten Sessions ist nice-to-have, nicht kritisch
Erweiterbarkeit
- System soll wachsen können
- Heute IDE, morgen vielleicht Monitor-Dashboards
- Prefix-System ermöglicht einfache Erweiterung
- Nicht zu früh über-engineeren
Nächste Milestones
- Phase 1: Basis-Setup (Zsh-Hooks, Detection, Helper-Scripts)
- Phase 2: Zellij-Layout + Helix-Config für bestehende Sprachen
- Phase 3: Testing mit infrastructure-Repo
- Phase 4: Server-Migration vorbereiten
- Phase 5: Rust-Umgebung einrichten
Fragen bei Unsicherheit
Bevor du Code schreibst oder Entscheidungen triffst:
- Ist das die einfachste Lösung?
- Braucht Tim das wirklich jetzt?
- Passt es zum iterativen Ansatz?
- Hast du alle Informationen oder solltest du nachfragen?
Im Zweifel: Nachfragen! Tim gibt lieber klares Feedback als dass er später umbauen muss.