Pi.Dev Pi ist ein minimalistisches Terminal-Entwicklungs-Framework. Es ist so konzipiert, dass es im Kern schlank bleibt, sich aber durch TypeScript-Erweiterungen, Skills, Prompt-Vorlagen, Designs und Pi-Pakete erweitern lässt. Pi Cheat Sheet für Windows 11 Kurz, praxisnah und auf schnelle Produktivität ausgelegt. 1. Was ist Pi? Pi ist ein minimaler terminalbasierter Coding-Agent. Er kann mit Modellen sprechen und standardmäßig in deinem Projekt: Dateien lesen Dateien schreiben Dateien patchen Shell-Kommandos ausführen Pi arbeitet direkt im aktuellen Projektordner. 2. Schnellstart unter Windows 11 Voraussetzungen Du brauchst: Node.js / npm Git Bash oder einen anderen bash unter Windows Pi braucht auf Windows bash. Laut Doku sucht Pi bash in dieser Reihenfolge: shellPath aus ~/.pi/agent/settings.json Git Bash: C:\Program Files\Git\bin\bash.exe bash.exe im PATH Installation npm install -g --ignore-scripts @earendil-works/pi-coding-agent Dann in dein Projekt: cd /pfad/zu/deinem/projekt pi 3. Authentifizierung Pi kann mit Subscription-Logins oder API Keys arbeiten. Option A: Login in Pi In Pi: /login Dann Provider auswählen. Unterstützt laut Doku u. a.: ChatGPT Plus/Pro (Codex) Claude Pro/Max GitHub Copilot Option B: API Key per Umgebungsvariable Beispiel Anthropic in Git Bash: export ANTHROPIC_API_KEY=sk-ant-... pi Oder OpenAI: export OPENAI_API_KEY=sk-... pi 4. Windows-11-Empfehlung: Das beste Setup Empfohlen Windows Terminal Git Bash optional: VS Code für Editieren optional: API-Key oder /login Wichtige Windows-Terminal-Konfiguration Damit Shift+Enter und Alt+Enter sauber an Pi weitergegeben werden, in settings.json von Windows Terminal ergänzen: { "actions": [ { "command": { "action": "sendInput", "input": "\u001b[13;2u" }, "keys": "shift+enter" }, { "command": { "action": "sendInput", "input": "\u001b[13;3u" }, "keys": "alt+enter" } ] } Das bringt dir: Shift+Enter = neue Zeile im Editor Alt+Enter = Follow-up-Message queueen Ohne das klaut Windows Terminal oft Alt+Enter für Fullscreen. Falls Git Bash nicht gefunden wird Datei: ~/.pi/agent/settings.json Beispiel: { "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe" } 5. Erste produktive Nutzung In deinem Projektordner: pi Dann einfach schreiben: Analysiere dieses Repository und sag mir, wie ich die Tests starte. Oder: Finde die wichtigsten Einstiegspunkte im Code und erkläre die Architektur. 6. Die wichtigsten Built-in-Tools Standardmäßig hat Pi: read – Dateien lesen write – Dateien neu erstellen/überschreiben edit – Dateien patchen bash – Shell-Befehle ausführen Zusätzliche read-only Tools: grep find ls 7. Die wichtigsten Tastenkürzel Eingabe Enter → absenden Shift+Enter → neue Zeile Tab → Autocomplete / Pfadvervollständigung Ctrl+G → externen Editor öffnen ( $VISUAL oder $EDITOR) Steuerung Escape → abbrechen Ctrl+D → beenden (wenn Editor leer) Ctrl+C → Editor leeren / Auswahl abbrechen Modell / Thinking Ctrl+L → Modell wählen Ctrl+P → nächstes Modell Shift+Ctrl+P → vorheriges Modell Shift+Tab → Thinking-Level wechseln Ctrl+T → Thinking-Blocks ein-/ausblenden Queue / Verlauf Alt+Enter → Follow-up-Nachricht queueen Alt+Up → queuete Nachrichten zurück in den Editor holen 8. Die wichtigsten Slash Commands Muss man kennen /login – anmelden /logout – abmelden /model – Modell wechseln /settings – Einstellungen /resume – alte Session öffnen /new – neue Session /name – Session benennen /session – Infos zur Session /tree – Session-Baum / Branches /fork – neue Session aus früherer User-Nachricht /clone – aktuellen Branch duplizieren /compact – Kontext manuell komprimieren /reload – Extensions, Skills, Prompts etc. neu laden /hotkeys – Tastenkürzel anzeigen /quit – Pi beenden 9. Die wichtigsten CLI-Befehle Interaktiv starten pi Mit initialem Prompt pi "Finde alle wichtigen Build-Skripte" One-shot / Print-Modus pi -p "Fasse dieses Repository zusammen" Mit Datei-Referenzen pi @README.md "Fasse diese Datei zusammen" pi @src/app.ts @src/app.test.ts "Prüfe beide Dateien zusammen" Session fortsetzen pi -c Session-Auswahl pi -r Session benennen pi --name "Refactor Login" Bestimmte Session öffnen pi --session Ohne Session-Speicherung pi --no-session 10. Shell-Befehle in Pi Mit Ausgabe an das Modell Im Pi-Editor: !npm test Die Ausgabe wird dem Modell als Kontext gegeben. Ohne Ausgabe an das Modell !!npm test Praktisch für Dinge, die du nur lokal ausführen willst. 11. Dateien referenzieren Interaktiv Im Editor @ tippen → fuzzy Suche nach Dateien. Direkt auf der CLI pi @README.md "Erkläre mir das Projekt" 12. Unbedingt nutzen: AGENTS.md Wenn du Pi schnell produktiv machen willst, ist das der größte Hebel. Projektweit Datei im Projekt: AGENTS.md Beispiel: # Projektanweisungen - Führe nach Codeänderungen `npm run check` aus. - Keine produktiven Migrationen lokal ausführen. - Halte Antworten kurz. - Bevorzuge kleine, gezielte Änderungen. - Nutze zuerst read/grep/find statt unnötiger bash-Kommandos. Wo Pi Kontextdateien lädt ~/.pi/agent/AGENTS.md → global AGENTS.md oder CLAUDE.md im aktuellen oder übergeordneten Verzeichnis Nach Änderung: /reload oder Pi neu starten. 13. Die wichtigsten Settings unter Windows 11 Dateien: global: ~/.pi/agent/settings.json projektbezogen: .pi/settings.json Sehr nützliche Minimal-Konfiguration { "theme": "dark", "quietStartup": false, "defaultThinkingLevel": "medium", "warnings": { "anthropicExtraUsage": true }, "retry": { "enabled": true, "maxRetries": 3, "baseDelayMs": 2000, "provider": { "maxRetries": 0, "maxRetryDelayMs": 60000 } }, "compaction": { "enabled": true, "reserveTokens": 16384, "keepRecentTokens": 20000 } } Windows-spezifisch mit Git Bash { "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe" } 14. Modelle schnell wechseln In Pi /model Auf CLI pi --provider openai --model gpt-4o "Hilf mir beim Refactoring" Oder: pi --model openai/gpt-4o "Hilf mir beim Refactoring" Oder mit Thinking-Level: pi --model sonnet:high "Löse dieses komplexe Problem" 15. Thinking-Level verstehen Mögliche Werte: off minimal low medium high xhigh Faustregel off/minimal → schnell, günstig medium → guter Standard high/xhigh → für komplexe Architektur, Debugging, Refactoring, Planungen Wechseln: Shift+Tab /settings --thinking Beispiel: pi --thinking high 16. Session-Workflow, den du wirklich brauchst Weitermachen pi -c Historie durchsuchen pi -r Neue Session /new Session benennen /name Bugfix Auth Timeout Baum/Navigation /tree Das ist extrem nützlich, um frühere Gesprächsstände wieder aufzunehmen. Fork aus früherer User-Nachricht /fork Aktuellen Branch kopieren /clone 17. Der beste Windows-Workflow im Alltag Workflow A: Repo verstehen cd projekt pi Dann: Analysiere dieses Repository. Erkläre Architektur, wichtige Einstiegspunkte, Build/Test-Kommandos und typische Entwicklungsabläufe. Workflow B: Bug fixen Reproduziere das Problem anhand des Codes. Finde die Ursache. Schlage einen minimalen Fix vor und führe danach die relevanten Checks aus. Workflow C: Refactoring Analysiere das Modul src/... und schlage ein kleines, risikoarmes Refactoring vor. Erkläre erst den Plan, dann führe es aus und prüfe die Änderungen. Workflow D: Testausfälle Untersuche, warum die Tests fehlschlagen. Nutze bevorzugt vorhandene Test- und Lint-Kommandos. Führe danach nur die relevanten Checks erneut aus. 18. Praktische Prompts für produktives Arbeiten Projekt-Scan Fasse dieses Repository zusammen und nenne mir die wichtigsten Kommandos für Build, Test und Lint. Code Review Prüfe die zuletzt geänderten Dateien auf Bugs, Edge Cases und fehlende Tests. Implementierung Implementiere Feature X minimal-invasiv im bestehenden Stil des Projekts. Erkläre kurz deinen Plan und führe danach die passenden Checks aus. Debugging Untersuche die Ursache für den Fehler. Gehe hypothesengetrieben vor und validiere jede Annahme mit Code oder Kommandos. Tests Finde heraus, wie ich die relevanten Tests für dieses Modul ausführen kann, und führe dann nur diese aus. 19. Read-only / sicherer Modus Wenn du Pi erstmal nur analysieren lassen willst: pi --tools read,grep,find,ls -p "Reviewe den Code" Das gibt Pi keine Schreibrechte. Sehr empfehlenswert am Anfang. 20. Nützliche Umgebungsvariablen Wichtige Standardvariablen ANTHROPIC_API_KEY OPENAI_API_KEY GEMINI_API_KEY Pi-spezifisch PI_CODING_AGENT_DIR → anderes Config-Verzeichnis PI_CODING_AGENT_SESSION_DIR → anderes Session-Verzeichnis PI_OFFLINE=1 → keine Startup-Netzwerkoperationen PI_SKIP_VERSION_CHECK=1 → Versionscheck aus PI_TELEMETRY=0 → Telemetrie aus Beispiel in Git Bash: export PI_SKIP_VERSION_CHECK=1 export PI_TELEMETRY=0 pi 21. Wo Pi seine Daten speichert Standardmäßig unter: ~/.pi/agent/ Wichtig: auth.json → Zugangsdaten settings.json → globale Settings keybindings.json → Keybindings AGENTS.md → globale Anweisungen sessions/ → Sessions extensions/ → Extensions skills/ → Skills prompts/ → Prompt Templates themes/ → Themes 22. Eigene Keybindings Datei: ~/.pi/agent/keybindings.json Beispiel: { "tui.input.newLine": ["shift+enter", "ctrl+j"], "app.model.select": ["ctrl+l"] } Unter Windows kann ctrl+j als Fallback für neue Zeile nützlich sein. Danach: /reload 23. Prompt Templates, Skills, Extensions – was ist was? Prompt Templates Wiederverwendbare Textbausteine, die per /name expandieren. Skills Größere, wiederverwendbare Fähigkeiten, die Pi on-demand lädt. Extensions TypeScript-Erweiterungen für Tools, Commands, Events, UI, Provider etc. Für schnellen Start unter Windows Am Anfang brauchst du meist nur: gutes AGENTS.md sinnvolle settings.json optional ein paar Prompt Templates 24. Nützliche One-shot-Kommandos README zusammenfassen pi -p @README.md "Fasse das prägnant zusammen" Code + Test gemeinsam prüfen pi -p @src/app.ts @src/app.test.ts "Prüfe Implementierung und Tests zusammen" Stdin pipen cat README.md | pi -p "Fasse den Text zusammen" Unter Windows/Git Bash ebenfalls nutzbar. 25. Fehlerbehebung unter Windows 11 Problem: Pi startet nicht wegen bash Lösung: Git Bash installieren shellPath setzen { "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe" } Problem: Shift+Enter geht nicht Lösung: Windows Terminal sendInput-Mapping setzen alternativ anderes Terminal testen Problem: Alt+Enter geht nicht Lösung: Windows Terminal remappen, sonst nutzt es Fullscreen Problem: Auth klappt nicht Check: API-Key korrekt gesetzt? richtiges Terminal? /login statt ENV probieren auth.json prüfen Problem: Pi arbeitet zu aggressiv im Dateisystem Lösung: read-only starten: pi --tools read,grep,find,ls Git verwenden vorher committen 26. Meine klare Empfehlung für dein Start-Setup ~/.pi/agent/settings.json { "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe", "theme": "dark", "defaultThinkingLevel": "medium", "compaction": { "enabled": true, "reserveTokens": 16384, "keepRecentTokens": 20000 }, "retry": { "enabled": true, "maxRetries": 3, "baseDelayMs": 2000, "provider": { "maxRetries": 0, "maxRetryDelayMs": 60000 } } } ~/.pi/agent/AGENTS.md # Global Pi Instructions - Be concise and practical. - Prefer minimal, low-risk code changes. - Before changing code, inspect the surrounding files and existing conventions. - After code changes, suggest or run the most relevant checks. - On Windows, prefer commands that work in Git Bash. Projekt- AGENTS.md # Project Instructions - Run `npm test` only when relevant. - Prefer targeted tests over full-suite runs. - Keep changes small and easy to review. - Do not modify CI, release, or deployment config unless explicitly requested. 27. Die 15 wichtigsten Dinge auf einen Blick Installieren: npm install -g --ignore-scripts @earendil-works/pi-coding-agent Starten: pi Unter Windows brauchst du bash. Bestes Setup: Windows Terminal + Git Bash. Login: /login API-Key alternativ via ENV. Neue Zeile: Shift+Enter Modell wechseln: Ctrl+L Shell-Befehl mit Kontext: !npm test Shell-Befehl ohne Kontext: !!npm test Datei referenzieren: @ Alte Session: pi -c Session-Baum: /tree Projektanweisungen in: AGENTS.md Sicher analysieren: pi --tools read,grep,find,ls 28. Mein empfohlener erster echter Einsatz Schritt 1 cd dein-projekt pi Schritt 2 Analysiere dieses Repository. Erkläre mir: 1. Architektur 2. wichtige Einstiegspunkte 3. Build/Test/Lint-Kommandos 4. typische Entwickler-Workflows 5. Risiken oder Stolperfallen Schritt 3 Dann: Erstelle mir einen konkreten Plan, wie wir in diesem Repository produktiv mit dir arbeiten sollten. Pi.Dev | Liste von Fragen bzw. Inhaltsverzeichnis Ich möchte Pi.Dev lernen, weshalb ich mir die gesamte aktuelle Dokumentation als Markdown-Datei gespeichert habe. Ich will an diese Markdown-Datei Fragen stellen, die dann per RAG verarbeitet werden, weil ja sonst der Kontext explodieren würde. Bitte mache mir eine ausführliche Liste solcher Fragen, sodass ich nach und nach alles über Pi lernen kann! Klar — hier ist eine ausführliche, systematische Fragenliste für dein RAG-gestütztes Lernen von Pi.Dev auf Basis deiner Markdown-Dokumentation. Die Fragen sind so aufgebaut, dass du: Pi.Dev strukturiert verstehen kannst, gezielt einzelne Dokumentationsabschnitte abfragen kannst, sowohl Anfänger- als auch Fortgeschrittenenthemen abdeckst, und dein RAG-System mit präzisen, gut retrievbaren Fragen fütterst. Ziel der Fragenliste Statt nur „Was ist Pi.Dev?“ zu fragen, solltest du viele konkrete, eng formulierte Fragen stellen. Das ist für RAG meist deutlich besser, weil: die Retrieval-Phase relevantere Abschnitte findet, Antworten präziser werden, du Wissenslücken systematisch schließen kannst. Ich strukturiere die Fragen deshalb in Lernblöcke. 1. Überblick und Orientierung Diese Fragen helfen dir, das Gesamtbild zu verstehen. Was ist Pi.Dev laut Dokumentation? Welches Problem löst Pi.Dev? Für wen ist Pi.Dev gedacht? Welche Hauptfunktionen bietet Pi.Dev? Wie ist die Dokumentation von Pi.Dev aufgebaut? Welche zentralen Konzepte muss man verstehen, bevor man mit Pi.Dev arbeitet? Welche Begriffe werden in der Dokumentation immer wieder verwendet? Gibt es in der Dokumentation eine empfohlene Lernreihenfolge? Welche ersten Schritte empfiehlt die Dokumentation für Einsteiger? Was unterscheidet Pi.Dev von ähnlichen Plattformen oder Frameworks? Welche typischen Anwendungsfälle nennt die Dokumentation? Welche Einschränkungen oder Grenzen von Pi.Dev werden genannt? Welche Komponenten oder Subsysteme gehören zu Pi.Dev? Welche Architektur oder welches Grundmodell liegt Pi.Dev zugrunde? Welche Voraussetzungen sollte man mitbringen, um Pi.Dev sinnvoll zu nutzen? 2. Einstieg und Setup Damit kannst du Installation, Einrichtung und erste Nutzung verstehen. Wie installiert man Pi.Dev? Welche Systemvoraussetzungen nennt die Dokumentation? Welche Betriebssysteme oder Umgebungen werden unterstützt? Gibt es eine lokale Entwicklungsumgebung für Pi.Dev? Welche Tools oder Abhängigkeiten müssen vorab installiert werden? Wie sieht der schnellste Weg aus, Pi.Dev zum Laufen zu bringen? Gibt es eine Quickstart-Anleitung? Bitte fasse sie Schritt für Schritt zusammen. Wie erstellt man ein erstes Projekt in Pi.Dev? Wie startet man ein neues Pi.Dev-Projekt über CLI, UI oder API? Welche Konfigurationsdateien sind beim Start wichtig? Welche Umgebungsvariablen werden benötigt? Wie richtet man Authentifizierung oder Zugangsdaten ein? Wie überprüft man, ob die Installation korrekt funktioniert? Welche typischen Fehler beim Setup nennt die Dokumentation? Wie behebt man Installationsprobleme laut Doku? Gibt es Unterschiede zwischen Entwicklungs-, Test- und Produktionsumgebung? Wie aktualisiert man Pi.Dev auf eine neue Version? Wie deinstalliert oder bereinigt man eine Pi.Dev-Installation? Welche Best Practices für ein sauberes Setup werden genannt? Gibt es offizielle Starter-Templates oder Beispielprojekte? 3. Kernbegriffe und Datenmodell Hier geht es um die „Sprache“ von Pi.Dev. Welche zentralen Objekte, Entitäten oder Ressourcen definiert Pi.Dev? Was bedeuten die wichtigsten Fachbegriffe in Pi.Dev? Welche Beziehungen bestehen zwischen den zentralen Objekten? Gibt es ein Datenmodell oder Schema? Bitte erklären. Welche Felder oder Eigenschaften haben die wichtigsten Ressourcen? Welche Objekte sind für Anfänger am wichtigsten? Welche Objekte werden am häufigsten in Beispielen verwendet? Welche Lebenszyklen haben die Hauptobjekte? Wie entstehen, verändern und verschwinden diese Objekte? Gibt es Zustände oder Statusmodelle für bestimmte Entitäten? Welche IDs, Referenzen oder Schlüsselkonzepte werden verwendet? Welche Objekte sind persistent, welche temporär? Welche Standardwerte oder Defaults sind wichtig? Welche Validierungsregeln gelten für Eingaben oder Ressourcen? Welche typischen Fehler entstehen durch Missverständnisse im Datenmodell? 4. API-Grundlagen Falls Pi.Dev APIs hat, solltest du sie systematisch abfragen. Welche APIs bietet Pi.Dev? Gibt es REST-, GraphQL-, SDK- oder andere Schnittstellen? Wie authentifiziert man sich an der API? Welche Authentifizierungsverfahren werden unterstützt? Wie ist die API-Dokumentation strukturiert? Welche wichtigsten Endpunkte sollte man zuerst lernen? Wie erstellt man eine erste erfolgreiche API-Anfrage? Wie sieht ein minimales Request/Response-Beispiel aus? Welche Header, Parameter und Payloads sind typisch? Wie werden Fehler über die API zurückgegeben? Welche HTTP-Statuscodes oder Fehlercodes verwendet Pi.Dev? Gibt es Rate Limits oder Nutzungslimits? Wie funktioniert Pagination? Wie funktioniert Filtering, Sorting und Searching? Wie funktionieren Create-, Read-, Update- und Delete-Operationen? Welche API-Ressourcen sind zentral für typische Workflows? Welche API-Konventionen oder Namensmuster verwendet Pi.Dev? Gibt es Versionierung der API? Wie migriert man zwischen API-Versionen? Welche Sicherheitsaspekte gelten bei der API-Nutzung? Gibt es Webhooks, Events oder Streaming-Schnittstellen? Wie testet man API-Anfragen am besten laut Dokumentation? Gibt es offizielle Codebeispiele für verschiedene Programmiersprachen? Welche häufigen API-Fehler nennt die Doku und wie löst man sie? Welche API-Funktionen gelten als experimentell oder veraltet? 5. CLI, SDKs und Entwicklerwerkzeuge Gibt es eine CLI für Pi.Dev? Welche Hauptbefehle existieren? Wie installiert und konfiguriert man die CLI? Welche Kommandos sollte man als Erstes kennen? Wie authentifiziert sich die CLI? Wie erstellt, startet, testet oder deployed man Projekte über die CLI? Welche Flags und Optionen sind besonders wichtig? Gibt es einen Debug- oder Verbose-Modus? Welche SDKs stellt Pi.Dev bereit? Für welche Sprachen gibt es offizielle Bibliotheken? Wie verwendet man das SDK in Sprache X? Bitte mit Beispiel. Welche Unterschiede gibt es zwischen API, SDK und CLI? Wann sollte man welches Tool verwenden? Gibt es Generatoren, Templates oder Scaffolding-Werkzeuge? Welche lokalen Developer-Tools empfiehlt die Dokumentation? Wie lassen sich Logs, Fehler und Requests lokal inspizieren? 6. Projektstruktur und Konfiguration Wie ist ein typisches Pi.Dev-Projekt aufgebaut? Welche Ordner und Dateien sind standardmäßig enthalten? Welche Datei ist für welche Konfiguration zuständig? Welche Konfigurationsoptionen sind besonders wichtig? Wie werden Umgebungen getrennt konfiguriert? Wie verwaltet man Secrets und sensible Daten? Wie überschreibt man Standardkonfigurationen? Welche Konfiguration ist verpflichtend, welche optional? Gibt es Konventionen für Dateibenennung oder Projektstruktur? Wie validiert Pi.Dev die Konfiguration? Welche Konfigurationsfehler treten häufig auf? Wie dokumentiert die Doku empfohlene Projektorganisation? Gibt es Unterschiede zwischen kleinem und großem Projekt-Setup? Wie konfiguriert man externe Integrationen? Wie geht Pi.Dev mit lokaler gegenüber produktiver Konfiguration um? 7. Erster praktischer Workflow Diese Fragen helfen dir, echtes Arbeiten zu verstehen. Was ist der einfachste End-to-End-Workflow in Pi.Dev? Wie erstellt man mit Pi.Dev ein minimales funktionierendes Beispiel? Welche Schritte umfasst ein Standard-Workflow von Anfang bis Ende? Welche Ressourcen müssen in welcher Reihenfolge erstellt werden? Welche Eingaben sind zwingend nötig? Welche Ausgabe oder welches Ergebnis erhält man am Ende? Wie überprüft man, ob der Workflow korrekt funktioniert? Welche typischen Anfängerfehler passieren im ersten Workflow? Gibt es in der Doku ein Hello-World-Beispiel? Bitte vollständig erklären. Welche Teile dieses Beispielprojekts sind besonders lehrreich? Wie lässt sich das Grundbeispiel erweitern? Welche Varianten eines Basis-Workflows beschreibt die Doku? Welche Schritte lassen sich automatisieren? Welche Logs oder Debugging-Hinweise helfen beim ersten Workflow? Wie übersetzt man das Beispiel in einen realen Anwendungsfall? 8. Fortgeschrittene Funktionen Welche fortgeschrittenen Features bietet Pi.Dev? Welche Features sollte man erst nach den Grundlagen lernen? Gibt es Automatisierungen, Pipelines oder Orchestrierungskonzepte? Wie arbeitet Pi.Dev mit komplexeren Workflows? Wie werden Abhängigkeiten zwischen Komponenten modelliert? Gibt es Event-getriebene oder asynchrone Mechanismen? Unterstützt Pi.Dev Hintergrundprozesse oder Jobs? Gibt es Zustandsmaschinen, Trigger oder Rules? Wie werden komplexe Eingaben oder verschachtelte Strukturen verarbeitet? Welche erweiterten Konfigurationsmöglichkeiten gibt es? Welche Skalierungsmechanismen nennt die Doku? Welche fortgeschrittenen Sicherheitsfunktionen gibt es? Gibt es Mandantenfähigkeit, Rollen oder Berechtigungsmodelle? Welche erweiterten Integrationsmöglichkeiten werden beschrieben? Welche Features gelten als Best Practice für produktive Nutzung? Welche fortgeschrittenen Fehlerquellen gibt es? Welche Architekturentscheidungen empfiehlt die Doku für größere Projekte? Welche Möglichkeiten zur Wiederverwendung oder Modularisierung gibt es? Wie lassen sich wiederkehrende Abläufe abstrahieren? Welche fortgeschrittenen Patterns zeigt die Dokumentation? 9. Authentifizierung, Autorisierung und Sicherheit Welche Sicherheitsmodelle unterstützt Pi.Dev? Wie funktioniert Authentifizierung in Pi.Dev genau? Welche Rollen oder Berechtigungsmodelle gibt es? Wie vergibt man Zugriffsrechte? Wie schützt man API-Schlüssel, Tokens oder Secrets? Welche Best Practices für Sicherheit nennt die Dokumentation? Welche Sicherheitsrisiken werden ausdrücklich erwähnt? Wie geht Pi.Dev mit Nutzeridentitäten um? Gibt es Single Sign-On, OAuth oder andere Auth-Verfahren? Wie erneuert oder widerruft man Tokens? Wie protokolliert oder auditierbar sind sicherheitsrelevante Aktionen? Welche Konfigurationen sind für Produktion aus Sicherheitsgründen wichtig? Welche häufigen Sicherheitsfehler machen Entwickler laut Doku? Wie trennt man Rechte zwischen Entwicklung, Test und Produktion? Gibt es Compliance-, Datenschutz- oder Governance-Hinweise? 10. Datenverarbeitung, Persistenz und Speicher Wie speichert Pi.Dev Daten? Welche Datenspeicher oder Storage-Konzepte werden verwendet? Welche Daten sind dauerhaft, welche flüchtig? Wie werden Daten gelesen, geschrieben, aktualisiert und gelöscht? Gibt es Transaktionen oder Konsistenzregeln? Wie modelliert Pi.Dev Beziehungen zwischen Datenobjekten? Welche Limits für Datengrößen oder Payloads nennt die Doku? Wie funktioniert Dateispeicherung oder Asset-Handling? Wie werden Backups oder Wiederherstellung behandelt? Gibt es Export- oder Importfunktionen? Welche Performance-Hinweise zur Datennutzung nennt die Dokumentation? Wie geht Pi.Dev mit Versionsständen oder Revisionen um? Welche Bereinigung oder Retention-Mechanismen gibt es? Wie vermeidet man Dateninkonsistenzen? Welche Best Practices für Datenmodellierung und Datenzugriff werden genannt? 11. Events, Webhooks, Automatisierung Unterstützt Pi.Dev Events oder Webhooks? Welche Event-Typen gibt es? Wie registriert oder konfiguriert man Webhooks? Welche Payloads enthalten Webhooks? Wie validiert man eingehende Webhook-Nachrichten? Wie geht Pi.Dev mit Retries oder Zustellfehlern um? Welche Sicherheitsmechanismen gibt es bei Webhooks? Wie debuggt man fehlgeschlagene Webhooks? Welche typischen Use Cases für Events beschreibt die Doku? Wie verbindet man Pi.Dev mit externen Automatisierungssystemen? Welche Unterschiede gibt es zwischen Polling und Event-basierter Nutzung? Wie baut man eine robuste Event-Verarbeitung mit Pi.Dev auf? Gibt es Reihenfolge-, Idempotenz- oder Duplikat-Hinweise? Welche Best Practices für Event-Handling nennt die Doku? Welche Limits oder Fallstricke gibt es bei Webhooks und Events? 12. Testing, Debugging und Qualitätssicherung Welche Teststrategien empfiehlt die Dokumentation für Pi.Dev? Wie testet man Projekte lokal? Gibt es Mocking-, Sandbox- oder Testumgebungen? Wie schreibt man Unit-, Integrations- oder End-to-End-Tests mit Pi.Dev? Welche Debugging-Tools stehen zur Verfügung? Wie liest und interpretiert man Logs? Welche typischen Fehlermeldungen treten auf und was bedeuten sie? Wie reproduziert man Probleme systematisch? Welche Diagnoseschritte empfiehlt die Doku bei Fehlern? Wie validiert man Konfigurationen vor dem Deployment? Gibt es Health Checks oder Statusprüfungen? Wie überwacht man Laufzeitprobleme? Welche Best Practices zur Qualitätssicherung nennt Pi.Dev? Wie erkennt man Performance-Probleme? Welche Anti-Patterns im Debugging werden erwähnt? 13. Deployment und Betrieb Wie deployt man ein Pi.Dev-Projekt? Welche Deployment-Modelle unterstützt Pi.Dev? Welche Voraussetzungen gelten für Produktion? Wie unterscheidet sich lokaler Betrieb von Produktion? Wie konfiguriert man Produktionsumgebungen? Wie verwaltet man Secrets im Deployment? Welche Build- oder Release-Schritte sind nötig? Gibt es CI/CD-Empfehlungen in der Dokumentation? Wie funktioniert Rollback? Wie überwacht man eine produktive Pi.Dev-Anwendung? Welche Skalierungsoptionen werden beschrieben? Wie geht Pi.Dev mit Ausfällen oder Fehlerfällen in Produktion um? Gibt es Zero-Downtime- oder Migrationshinweise? Welche Infrastruktur-Empfehlungen gibt die Doku? Welche typischen Produktionsfehler nennt die Dokumentation? 14. Performance und Skalierung Welche Performance-Empfehlungen gibt die Doku? Wo entstehen typischerweise Engpässe in Pi.Dev? Welche Limits nennt die Dokumentation? Wie optimiert man API-Nutzung in Pi.Dev? Wie reduziert man Latenz? Welche Caching-Strategien werden empfohlen? Wie geht Pi.Dev mit hoher Last um? Welche Skalierungsstrategien sind vorgesehen? Wie erkennt man ineffiziente Nutzungsmuster? Welche Metriken sollte man beobachten? Wie optimiert man Speicher- oder Rechenverbrauch? Welche Trade-offs zwischen Einfachheit und Performance beschreibt die Doku? Welche Empfehlungen gibt es für große Datenmengen oder viele Requests? Welche Anti-Patterns verschlechtern die Performance? Wie benchmarkt oder profiliert man Pi.Dev-basierte Systeme? 15. Integrationen und Ökosystem Welche externen Dienste kann Pi.Dev integrieren? Welche offiziellen Integrationen werden dokumentiert? Wie verbindet man Pi.Dev mit Datenbanken, APIs oder Dritttools? Welche Authentifizierungsanforderungen gelten bei Integrationen? Wie konfiguriert man eine externe Integration Schritt für Schritt? Welche Integrationen sind besonders häufig oder wichtig? Welche Einschränkungen gibt es bei Integrationen? Wie geht Pi.Dev mit Fehlern in externen Systemen um? Welche Best Practices für robuste Integrationen nennt die Doku? Gibt es Community- oder Drittanbieter-Erweiterungen? Wie entwickelt man eine eigene Integration? Gibt es Plugin-, Adapter- oder Extension-Konzepte? Wie testet man Integrationen zuverlässig? Welche Sicherheitsrisiken gibt es bei Integrationen? Welche Integrationsbeispiele bietet die Doku? 16. Architektur, Design Patterns und Best Practices Welche Architekturprinzipien empfiehlt die Dokumentation für Pi.Dev-Projekte? Welche Design Patterns tauchen in der Doku wiederholt auf? Wie strukturiert man ein größeres Pi.Dev-Projekt sauber? Welche Modularisierungsstrategien werden empfohlen? Wie trennt man Verantwortlichkeiten in Pi.Dev-Anwendungen? Welche Wiederverwendungsstrategien gibt es? Welche Best Practices gelten für Wartbarkeit? Welche Best Practices gelten für Lesbarkeit und Teamarbeit? Welche Anti-Patterns nennt die Dokumentation? Welche Beispiele für gute Architektur enthält die Doku? Wie plant man Pi.Dev-Projekte langfristig? Welche Prinzipien helfen bei Änderbarkeit und Erweiterbarkeit? Wie verhindert man technische Schulden laut Doku? Welche Patterns eignen sich für kleine, welche für große Projekte? Wie begründet die Dokumentation ihre empfohlenen Architekturentscheidungen? 17. Fehlerbehandlung und Troubleshooting Welche Fehlerkategorien unterscheidet Pi.Dev? Wie erkennt man Konfigurationsfehler? Wie erkennt man Authentifizierungs- und Berechtigungsfehler? Wie erkennt man API- oder Netzwerkfehler? Welche Standardstrategie zur Fehlersuche empfiehlt die Doku? Welche häufigen Anfängerfehler nennt die Dokumentation? Welche häufigen Produktionsprobleme nennt die Dokumentation? Wie interpretiert man Fehlermeldungen korrekt? Welche Logs oder Diagnosedaten sind im Fehlerfall am wichtigsten? Welche Retry-Strategien werden empfohlen? Wann sollte man Fehler abfangen und wann weiterreichen? Welche Fehler sollte man dem Nutzer zeigen, welche intern behandeln? Wie dokumentiert Pi.Dev bekannte Probleme oder Limitierungen? Gibt es Troubleshooting-Guides oder FAQ-Bereiche? Welche Maßnahmen helfen, Fehler proaktiv zu vermeiden? 18. Versionierung, Migration und Breaking Changes Wie versioniert Pi.Dev seine Plattform, APIs oder SDKs? Welche Migrationsleitfäden enthält die Dokumentation? Wie erkennt man Breaking Changes? Welche Upgrade-Strategie empfiehlt Pi.Dev? Wie migriert man ein bestehendes Projekt auf eine neue Version? Welche Teile ändern sich bei Upgrades am häufigsten? Gibt es Deprecation-Hinweise? Wie lange werden alte Versionen unterstützt? Welche Rückwärtskompatibilität garantiert Pi.Dev? Wie testet man ein Upgrade sicher? Welche typischen Migrationsfehler nennt die Doku? Wie dokumentiert Pi.Dev Änderungen zwischen Versionen? Welche Changelog- oder Release-Notes-Struktur wird verwendet? Wie bereitet man sich auf zukünftige Änderungen vor? Welche Best Practices gelten für wartbare, upgradefreundliche Projekte? 19. Praxisbeispiele und Tutorials Welche Tutorials enthält die Dokumentation? Welche Beispielprojekte gibt es? Welches Tutorial eignet sich am besten für Anfänger? Welche Tutorials decken fortgeschrittene Themen ab? Wie lässt sich jedes Tutorial in Lernziele zerlegen? Welche Konzepte lernt man aus Beispielprojekt X? Welche Annahmen setzen die Tutorials voraus? Welche Schritte in den Tutorials sind besonders wichtig? Welche impliziten Details werden im Tutorial nicht ausdrücklich erklärt? Wie kann man ein Tutorial abwandeln, um das Gelernte zu vertiefen? Welche häufigen Probleme treten beim Nachbauen der Tutorials auf? Wie überträgt man ein Tutorial auf einen realen Use Case? Welche Best Practices lassen sich aus den Tutorials ableiten? Welche Fehler oder Vereinfachungen enthalten die Tutorials möglicherweise? Welche Reihenfolge der Tutorials ist zum Lernen am sinnvollsten? 20. Dokumentationsverständnis und Meta-Fragen Diese Fragen sind extrem nützlich für RAG, weil sie dein Modell dazu bringen, die Doku selbst zu strukturieren. Bitte fasse die gesamte Pi.Dev-Dokumentation in 10 Hauptthemen zusammen. Welche Kapitel der Dokumentation sind für Einsteiger am wichtigsten? Welche Kapitel sollte man erst später lesen? Welche Begriffe sollte ich mir als Glossar notieren? Welche Konzepte werden an mehreren Stellen der Doku erklärt? Wo gibt es mögliche Widersprüche oder Unklarheiten in der Dokumentation? Welche Informationen werden vorausgesetzt, aber nicht erklärt? Welche Kapitel hängen logisch voneinander ab? Welche Teile der Doku sind besonders praxisrelevant? Welche Teile sind eher Referenz als Lernstoff? Bitte erstelle mir aus der Doku einen Lernpfad für 7 Tage. Bitte erstelle mir aus der Doku einen Lernpfad für 30 Tage. Welche Fragen sollte ich nach dem Lesen von Kapitel X beantworten können? Welche Wissenslücken hätte ich vermutlich nach dem Quickstart noch? Welche Stellen der Dokumentation sollte ich bookmarken? Welche API- oder Referenzseiten brauche ich im Alltag am häufigsten? Welche Beispiele aus der Doku sind am aussagekräftigsten? Bitte extrahiere alle Best Practices aus der Dokumentation. Bitte extrahiere alle Warnungen, Einschränkungen und Fallstricke aus der Dokumentation. Bitte extrahiere alle Codebeispiele und gruppiere sie thematisch. 21. Fragen für systematisches Lernen in Stufen Stufe A: Anfänger Was muss ich über Pi.Dev wissen, um überhaupt starten zu können? Welche 20 Prozent der Doku geben mir 80 Prozent des Nutzens? Welche drei ersten praktischen Aufgaben sollte ich mit Pi.Dev umsetzen? Welche Konzepte darf ich auf keinen Fall verwechseln? Welche Minimalbeispiele sollte ich unbedingt nachbauen? Wie erkenne ich, dass ich die Grundlagen verstanden habe? Welche häufigen Missverständnisse haben Anfänger? Welche Kapitel sind Pflichtlektüre für Anfänger? Welche Fachbegriffe sollte ich zuerst lernen? Was ist der einfachste produktive Use Case mit Pi.Dev? Stufe B: Mittelstufe Welche Konzepte brauche ich, um mehr als nur das Quickstart zu verstehen? Wie strukturiere ich ein echtes Projekt mit Pi.Dev? Welche Konfigurationen und Workflows sind im Alltag am wichtigsten? Welche Integrationen sollte ich früh lernen? Welche Fehlerquellen treten in echten Projekten besonders oft auf? Welche Best Practices unterscheiden gute von schlechten Pi.Dev-Projekten? Wie mache ich mein Projekt robuster, sicherer und wartbarer? Welche fortgeschrittenen Features bringen den größten Mehrwert? Wie teste und deploye ich ein Pi.Dev-Projekt professionell? Welche Architekturentscheidungen sollte ich früh treffen? Stufe C: Fortgeschrittene Wie skaliere ich Pi.Dev für größere Projekte oder Teams? Welche Architektur-Patterns empfiehlt die Doku für komplexe Systeme? Wie optimiere ich Performance, Sicherheit und Betrieb? Welche Migrations- und Versionsstrategien sind langfristig sinnvoll? Wie baue ich erweiterbare Integrationen oder Module? Welche betrieblichen Risiken muss ich in Produktion beachten? Welche Grenzen der Plattform werden bei fortgeschrittener Nutzung relevant? Welche Entscheidungen sind schwer rückgängig zu machen? Welche Trade-offs beschreibt die Doku zwischen Einfachheit, Kontrolle und Skalierung? Wie sieht ein „state of the art“-Setup mit Pi.Dev laut Doku aus? 22. Sehr gute RAG-Frageformate Zusätzlich zu Inhaltsfragen helfen dir diese Frage-Templates enorm, weil sie retrieval-freundlich sind. A. Definitionsfragen Was bedeutet der Begriff „X“ in Pi.Dev? Wie definiert die Dokumentation „X“? Wofür wird „X“ verwendet? B. Vergleichsfragen Was ist der Unterschied zwischen X und Y in Pi.Dev? Wann sollte ich X statt Y verwenden? Welche Vor- und Nachteile haben X und Y? C. Prozessfragen Welche Schritte sind nötig, um X in Pi.Dev einzurichten? Wie läuft der Workflow X Ende-zu-Ende ab? Welche Reihenfolge empfiehlt die Doku für X? D. Fehlerfragen Warum tritt Fehler X auf? Welche Ursachen nennt die Doku für Problem X? Wie behebt man Problem X Schritt für Schritt? E. Best-Practice-Fragen Welche Best Practices nennt die Doku für X? Welche Anti-Patterns sollte man bei X vermeiden? Was empfiehlt die Doku für produktive Nutzung von X? F. Strukturfragen In welchen Kapiteln wird X behandelt? Welche Dokumentationsstellen sind für X relevant? Welche Beispiele zeigt die Doku zu X? G. Extraktionsfragen Liste alle Konfigurationsoptionen für X auf. Extrahiere alle Warnungen zu X. Fasse alle API-Endpunkte zu X zusammen. Zeige alle Codebeispiele zu X. 23. Besonders nützliche Master-Prompts für dein RAG-System Diese Prompts sind praktisch, wenn du nicht nur einzelne Fakten, sondern strukturiertes Lernen willst. „Erkläre mir Thema X ausschließlich auf Basis der bereitgestellten Pi.Dev-Dokumentation und nenne die relevanten Abschnitte.“ „Fasse mir Kapitel X in einfachen Worten zusammen und nenne anschließend die wichtigsten Fachbegriffe.“ „Erstelle aus den Dokumentationsabschnitten zu X eine Schritt-für-Schritt-Anleitung für Anfänger.“ „Vergleiche die Konzepte X und Y nur anhand der Dokumentation und gib typische Anwendungsfälle an.“ „Extrahiere aus der Doku alle Best Practices, Warnungen und Fallstricke zu Thema X.“ „Zeige mir zu Thema X alle relevanten Konfigurationsoptionen mit Bedeutung, Defaults und Beispielen.“ „Erstelle mir zu Thema X fünf Verständnisfragen mit Antworten basierend auf der Doku.“ „Nenne mir zu Thema X die häufigsten Fehler und erkläre, wie die Dokumentation ihre Behebung beschreibt.“ „Baue aus den Dokumentationsstellen zu X einen Lernpfad: Grundlagen, Praxis, fortgeschrittene Nutzung.“ „Gib mir erst eine kurze Antwort, dann eine detaillierte Erklärung und dann ein Minimalbeispiel aus der Doku.“ 24. Empfohlene Lernreihenfolge als Fragenpfad Wenn du wirklich „nach und nach alles“ lernen willst, kannst du in dieser Reihenfolge fragen: Phase 1: Orientierung Was ist Pi.Dev? Welche Kernkonzepte gibt es? Wie ist die Doku aufgebaut? Welche Begriffe muss ich zuerst kennen? Phase 2: Setup Wie installiere ich Pi.Dev? Wie richte ich ein erstes Projekt ein? Wie funktioniert das Hello-World-Beispiel? Welche typischen Setup-Fehler gibt es? Phase 3: Grundlagen Welche Hauptobjekte und Workflows gibt es? Wie funktioniert die API/CLI/SDK? Wie ist ein Projekt strukturiert? Wie konfiguriert man die wichtigsten Dinge? Phase 4: Praxis Wie baue ich einen vollständigen Workflow? Wie teste ich ihn? Wie debugge ich Fehler? Wie deploye ich das Projekt? Phase 5: Professionelle Nutzung Welche Best Practices gibt es? Wie mache ich das Projekt sicher und wartbar? Wie integriere ich externe Systeme? Wie skaliere und überwache ich produktive Anwendungen? Phase 6: Meisterschaft Welche Architekturpatterns empfiehlt die Doku? Wie gehe ich mit Migrationen und Breaking Changes um? Welche fortgeschrittenen Features lohnen sich? Wo liegen die Grenzen und Trade-offs von Pi.Dev? 25. Mein praktischer Tipp für dein RAG-Setup Wenn du diese Fragen wirklich gut nutzen willst, formuliere sie möglichst so: eng kapitelbezogen begriffsscharf mit gewünschtem Ausgabeformat Beispiel statt: „Erklär mir Pi.Dev“ besser: „Erkläre die in der Dokumentation beschriebenen Kernkonzepte von Pi.Dev für Anfänger. Nenne pro Konzept Definition, Zweck, typische Verwendung und relevante Dokumentationsabschnitte.“ Oder statt: „Wie funktioniert die API?“ besser: „Fasse die API-Grundlagen aus der Pi.Dev-Dokumentation zusammen: Authentifizierung, zentrale Endpunkte, Request-Aufbau, Fehlercodes und Best Practices.“ Fragen zu Pi: Überblick und Orientierung Was ist Pi.Dev laut Dokumentation? Pi.Dev ist laut Dokumentation die Plattform bzw. Dokumentationsseite für Pi, einen Coding-Agenten für das Terminal, der als npm-Paket installiert wird und für interaktive Sessions, Konfiguration, Provider-Setup und programmgesteuerte Nutzung gedacht ist. Kurz gesagt: Pi.Dev ist die offizielle Doku zu Pi. Welches Problem löst Pi.Dev? Pi.Dev bzw. Pi löst das Problem, dass viele Coding-Agenten und Entwicklerwerkzeuge zu schwergewichtig, unflexibel oder schlecht anpassbar sind. Kurz gesagt: Pi ist ein minimalistisches Terminal-Coding-Harness es hält den Kern bewusst klein und lässt sich über TypeScript-Erweiterungen, Skills, Prompt-Templates, Themes und Pi-Packages erweitern Damit adressiert Pi.Dev vor allem diese Probleme: Komplexe, aufgeblähte Entwickler-Tools fehlende Anpassbarkeit schwierige Integration in bestehende Workflows Bedarf nach einem einfachen, terminalbasierten Coding-Agenten, der sich programmatisch nutzen lässt, z. B. per: SDK RPC über stdin/stdout JSONL JSON Event Stream TUI-Komponenten Auf Deutsch in einem Satz: Pi.Dev bietet eine schlanke, erweiterbare Terminal-Umgebung für Coding-Agenten und löst damit das Problem unflexibler oder überladener Entwicklungswerkzeuge. Für wen ist Pi.Dev gedacht? Pi.Dev ist für Entwickler gedacht, die einen minimalen terminalbasierten Coding-Agenten nutzen wollen. Laut Kontext ist Pi: ein „minimal terminal coding harness“ gedacht für Nutzung im Terminal erweiterbar für Nutzer mit Bedarf an Extensions, Skills, Prompt-Templates, Themes und Packages auch geeignet für Entwickler, die Pi programmgesteuert einbetten wollen, z. B. über: SDK RPC mode JSON event stream mode TUI components Kurz: Pi.Dev richtet sich vor allem an Entwickler und technische Nutzer, die einen schlanken, erweiterbaren Coding-Agenten im Terminal suchen. Welche Hauptfunktionen bietet Pi.Dev? Pi.Dev bietet laut Dokumentation vor allem diese Hauptfunktionen: Minimaler Terminal-Coding-Harness für interaktive Coding-Sessions Erweiterbarkeit durch: TypeScript-Extensions Skills Prompt-Templates Themes Pi-Packages Programmatic Usage: SDK für Node.js RPC-Modus über stdin/stdout JSONL JSON-Event-Stream-Modus TUI-Komponenten für eigene Terminal-UIs Referenzfunktionen: Session-Format und SessionManager-API Plattform-Setup für: Windows Termux auf Android tmux allgemeine Terminal-Konfiguration Shell-Aliase Anpassungsmöglichkeiten: Custom Models Custom Providers inklusive eigener APIs und OAuth-Flows Nutzungsfunktionen: interaktiver Modus Slash-Commands Kontextdateien Session-Management, Branching und Tree-Navigation Compaction und Branch-Zusammenfassung Konfigurierbarkeit über: Settings Keybindings Kurz gesagt: Pi.Dev ist ein schlankes, terminalbasiertes Coding-Tool, das sich stark anpassen und in eigene Workflows oder Anwendungen integrieren lässt. Wie ist die Dokumentation von Pi.Dev aufgebaut? Die Pi.Dev-Dokumentation ist in mehrere Hauptbereiche gegliedert. Aus dem gegebenen Kontext ergibt sich im Wesentlichen dieser Aufbau: Start / Einstieg Quickstart Using Pi Providers Settings Keybindings Sessions Compaction Anpassung / Erweiterung Skills Locations How Skills Work Skill Commands Skill Structure Frontmatter Validation Example Skill Repositories Pi Packages Programmatic Usage SDK RPC mode JSON event stream mode TUI components Referenz Session format Plattform-Setup Windows Termux on Android tmux Terminal setup Shell aliases Entwicklung Development Kurz gesagt: Die Dokumentation ist modular aufgebaut und deckt Einstieg, Nutzung, Konfiguration, Erweiterung, programmatische Integration, Referenz, Plattformhinweise und Entwicklung ab. Welche zentralen Konzepte muss man verstehen, bevor man mit Pi.Dev arbeitet? Bevor man mit Pi.Dev arbeitet, sollte man vor allem diese zentralen Konzepte verstehen: Kernprinzip von Pi Pi hält den Kern bewusst klein. Workflow-spezifische Funktionen werden über Extensions, Skills, Prompt Templates und Packages ergänzt. Viele Dinge sind absichtlich nicht eingebaut, z. B.: MCP Sub-Agents Permission-Popups Plan-Mode To-dos Background-Bash Anpassbarkeit statt fest eingebauter Features Solche Workflows baut man bei Pi selbst über: Extensions Packages externe Tools wie Container oder tmux Provider-Konzept Pi unterstützt: Subscription-basierte Provider via OAuth API-Key-Provider via Umgebungsvariablen oder Auth-Datei Pi kennt pro Provider die verfügbaren Modelle; diese Liste wird mit jeder Release aktualisiert. Wichtige Einstiegsbereiche Quickstart: Installation, Authentifizierung, erste Session Using Pi: Interaktiver Modus, Slash-Commands, Context-Files, CLI Providers: Einrichtung von Modellanbietern Settings, Keybindings, Sessions, Compaction: zentrale Bedien- und Arbeitskonzepte Programmgesteuerte Nutzung Pi kann nicht nur interaktiv, sondern auch programmgesteuert verwendet werden über: SDK RPC mode JSON event stream TUI components Erweiterungsmodell Für fortgeschrittene Nutzung wichtig: Extensions Skills Prompt Templates Themes Packages Custom Models Custom Providers Kurz gesagt: Man muss verstehen, dass Pi ein schlanker, modularer Coding-Agent ist, bei dem Funktionalität über Erweiterungen und Provider konfiguriert wird statt über viele fest eingebaute Features. Welche Begriffe werden in der Dokumentation immer wieder verwendet? In der gezeigten Dokumentation tauchen diese Begriffe wiederholt bzw. als zentrale Themen auf: Session / Sessions Continue / Resume Fork Session file Session directory Tool Options Start here Quickstart Using Pi Providers Settings Keybindings Compaction Customization UI & Display Config Reference Model Configuration Kurz gesagt: Besonders häufig geht es um Sessions, Einstellungen/Settings, Modelle, Provider und die Nutzung von Pi. Gibt es in der Dokumentation eine empfohlene Lernreihenfolge? Ja. Die Doku empfiehlt implizit eine Lernreihenfolge über den Abschnitt „Start here“ bzw. „Next steps“. Empfohlene Reihenfolge: Quickstart Installation, Authentifizierung, erste Session. Using Pi Interaktiver Modus, Slash-Commands, Context Files, CLI. Providers Anbieter, Subscription/API-Key-Setup, Modellzugang. Settings Globale und projektbezogene Konfiguration. Keybindings Standard-Shortcuts und Anpassungen. Sessions Session-Verwaltung, Branching, Tree-Navigation. Compaction Kontextkomprimierung und Zusammenfassungen. Für Erweiterungen geht es danach typischerweise weiter mit: Extensions / Quick Start Writing an Extension Events, Lifecycle, ExtensionContext State Management, Custom Tools, Custom UI, Error Handling, Mode Behavior, Examples Kurz: Ja, es gibt eine empfohlene Einstiegsreihenfolge, beginnend mit Quickstart und dann den unter Start here / Next steps aufgelisteten Themen. Welche ersten Schritte empfiehlt die Dokumentation für Einsteiger? Die Dokumentation empfiehlt Einsteigern unter „Start here“ vor allem diese ersten Schritte: Quickstart – Installation, Authentifizierung und erste Session Using Pi – interaktiver Modus, Slash-Commands, Kontextdateien und CLI-Referenz Providers – Abo-/API-Key-Setup für integrierte Anbieter Settings – globale und projektbezogene Einstellungen Keybindings – Standard-Shortcuts und eigene Tastenbelegung Sessions – Sitzungsverwaltung, Branching und Baum-Navigation Compaction – Kontextkomprimierung und Zusammenfassungen Kurz: Man soll mit dem Quickstart beginnen und sich danach je nach Bedarf mit Nutzung, Providern, Einstellungen und Sessions vertraut machen. Was unterscheidet Pi.Dev von ähnlichen Plattformen oder Frameworks? Pi.Dev unterscheidet sich laut dem gegebenen Kontext vor allem dadurch, dass es nicht nur eine einfache CLI oder ein einzelnes Framework ist, sondern eine umfassende, anpassbare Plattform für KI-gestützte Arbeit im Terminal und programmatische Integration. Wichtige Unterscheidungsmerkmale aus dem Kontext: Breite Funktionsabdeckung: interaktive Nutzung Sessions mit Branching und Tree-Navigation Context Compaction und Summaries Slash Commands und Context Files Starke Anpassbarkeit: Extensions Skills Prompt Templates Themes Pi Packages Custom Models Custom Providers Programmierbare Integration: SDK für Node.js RPC-Modus über stdin/stdout JSONL JSON Event Stream TUI-Komponenten für eigene Terminal-UIs Modell- und Provider-Flexibilität: Unterstützung für eingebaute Provider konfigurierbare eigene Modelle eigene Provider inkl. API- und OAuth-Anbindung Fokus auf Terminal- und Workflow-Produktivität: Keybindings Sessions plattformspezifische Setups für Windows, Termux, tmux und Terminal-Konfiguration Kurz gesagt: Pi.Dev hebt sich durch die Kombination aus Terminal-zentrierter KI-Nutzung, tiefer Erweiterbarkeit, programmatischer Einbettung und flexibler Modell-/Provider-Konfiguration ab. Es wirkt damit eher wie ein komplettes Ökosystem für KI-Workflows als nur wie ein einzelnes Tool oder ein eng begrenztes Framework. Welche typischen Anwendungsfälle nennt die Dokumentation? Die Dokumentation nennt folgende typische Anwendungsfälle: Berechtigungsabfragen, z. B. vor rm -rf oder sudo Git-Checkpointing, z. B. nach jedem Schritt stashen und beim Branch wiederherstellen Pfadschutz, z. B. Schreibzugriffe auf .env oder node_modules/ blockieren Benutzerdefinierte Kompaktierung/Zusammenfassung Gesprächszusammenfassungen Interaktive Tools, z. B. Fragen, Wizards, eigene Dialoge Zustandsbehaftete Tools, z. B. Todo-Listen oder Connection-Pools Externe Integrationen, z. B. File-Watcher, Webhooks, CI-Trigger Spiele zur Überbrückung der Wartezeit, z. B. snake.ts Welche Einschränkungen oder Grenzen von Pi.Dev werden genannt? Im gegebenen Kontext werden kaum direkte „Einschränkungen“ von Pi.Dev beschrieben. Genannt werden vor allem Konfigurations- und Deaktivierungsgrenzen bei Tools: --tools / -t: nur bestimmte Built-in-, Extension- oder Custom-Tools erlauben --exclude-tools / -xt: bestimmte Tools gezielt deaktivieren --no-builtin-tools / -nbt: alle eingebauten Tools deaktivieren, benutzerdefinierte/Extension-Tools bleiben aktiv --no-tools / -nt: alle Tools komplett deaktivieren Außerdem wird implizit sichtbar, dass die eingebauten Tools auf diese Liste begrenzt sind: read bash edit write grep find ls Wenn du möchtest, kann ich die Antwort auch noch als kurze Zusammenfassung auf Deutsch oder als Stichpunktliste für Dokumentation umformulieren. Welche Komponenten oder Subsysteme gehören zu Pi.Dev? Zu Pi.Dev gehören laut dem gegebenen Kontext diese Komponenten bzw. Subsysteme: Quickstart Using Pi Providers Settings Keybindings Sessions Compaction Unter Customization / Programmatic usage: SDK RPC mode JSON event stream mode TUI components Weitere Referenz-/Plattformbereiche: Session format Windows Termux on Android tmux Terminal setup Shell aliases Außerdem im Paket-/Erweiterungsbereich: Install and Manage Package Sources Creating a Pi Package Package Structure Dependencies Package Filtering Enable and Disable Resources Scope and Deduplication Und speziell für TUI-Komponenten: @earendil-works/pi-tui Component Interface mit: render(width: number): string[] handleInput?(data: string): void wantsKeyRelease?: boolean invalidate(): void Welche Architektur oder welches Grundmodell liegt Pi.Dev zugrunde? Pi.Dev basiert auf einem kleinen, modularen Kern. Das Grundmodell laut Kontext ist: Core klein halten workflow-spezifisches Verhalten auslagern in: Extensions Skills Prompt Templates Packages Zusätzlich ist Pi bewusst so entworfen, dass es nicht viele fest eingebaute Funktionen mitbringt, wie z. B.: MCP Sub-Agents Permission-Popups Plan-Mode To-dos Background-Bash Stattdessen soll man solche Funktionen über Erweiterungen oder externe Tools ergänzen. Kurz gesagt: Pi.Dev folgt einer minimalistischen, erweiterbaren Plugin-/Modul-Architektur. Welche Voraussetzungen sollte man mitbringen, um Pi.Dev sinnvoll zu nutzen? Um Pi.Dev sinnvoll zu nutzen, sollte man vor allem Folgendes mitbringen: Grundlegende Terminal-/CLI-Kenntnisse, da Pi als npm-Paket installiert und über die Kommandozeile genutzt wird. Node.js / npm, weil die Installation über npm install -g ... erfolgt. Ein eingerichtetes Modell bzw. Provider-Zugang, da die Doku auf Providers, Authentication und Model Configuration verweist. Verständnis für Sessions, Slash-Commands und Konfiguration, weil Pi interaktiv arbeitet und über Settings, Keybindings, Sessions und Context Files angepasst wird. Vorsicht bei Skills, denn laut Doku können Skills Aktionen ausführen und sogar ausführbaren Code enthalten; man sollte Inhalte daher prüfen, bevor man sie verwendet. Kurz gesagt: am hilfreichsten sind Erfahrung mit Entwicklerwerkzeugen, Terminal, npm und der Arbeit mit KI-Modellen/Providern. Pi + Straico Schreibe mir eine ausführliche Anleitung, wie ich meine laufende Straico-Ollama-Proxy-Instanz in Pi nutzen kann. Also welche Dateien (wahrscheinlich im .pi-Ordner) muss ich editieren und wie? Klar — hier ist eine ausführliche Schritt-für-Schritt-Anleitung, wie du deine laufende Straico-Ollama-Proxy-Instanz in Pi einbindest. Ich gehe dabei von diesem Setup aus: dein Proxy läuft lokal erreichbar unter: OpenAI/LMStudio-kompatibel: http://127.0.0.1:11434/v1 Pi soll über Custom Models darauf zugreifen dafür bearbeiten wir vor allem: ~/.pi/agent/models.json Ziel Pi soll deinen Straico-Proxy wie einen OpenAI-kompatiblen lokalen Anbieter behandeln, damit du die darüber verfügbaren Modelle in /model auswählen kannst. Da dein Proxy laut Doku OpenAI Chat Completions unter /v1/chat/completions unterstützt, ist in Pi die richtige API-Einstellung: api: "openai-completions" Welche Datei musst du editieren? Hauptdatei Die wichtigste Datei ist: ~/.pi/agent/models.json Falls sie noch nicht existiert, kannst du sie einfach anlegen. Was kommt in models.json? Du definierst darin einen custom provider. Für deinen Straico-Ollama-Proxy ist das Grundprinzip: baseUrl = http://127.0.0.1:11434/v1 api = "openai-completions" apiKey = irgendein Wert oder dein echter Straico-Key, je nachdem was der Proxy erwartet models = Liste der Modelle, die Pi anzeigen soll Wichtig vorab: Welchen API-Key erwartet dein Proxy? Hier gibt es zwei mögliche Varianten: Variante A: Der Proxy benötigt nach außen keinen Key Manche lokalen Proxies hängen intern am echten Straico-Key und erwarten von Pi selbst keinen echten API-Key mehr. Dann kannst du in Pi einfach etwas Dummy-artiges setzen, z. B.: "apiKey": "straico" Variante B: Der Proxy erwartet einen Bearer-Key im OpenAI-Stil Dann solltest du deinen echten Key oder eine Umgebungsvariable verwenden, z. B.: "apiKey": "$STRAICO_API_KEY" Wenn du nicht sicher bist, starte erstmal mit einem Dummy-Wert. Falls Requests mit Auth-Fehlern scheitern, nimm den echten Key. Schritt-für-Schritt Schritt 1: Prüfen, ob dein Proxy läuft Teste im Terminal: curl http://127.0.0.1:11434/v1/models Wenn dein Proxy korrekt läuft, solltest du eine JSON-Antwort bekommen. Alternativ: curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer straico" \ -d '{ "model": "gpt-4o-mini", "messages": [ { "role": "user", "content": "Sag hallo" } ] }' Wenn das funktioniert, ist dein Proxy für Pi grundsätzlich nutzbar. Der konkrete Modellname hängt natürlich davon ab, welche Modelle dein Proxy über Straico anbietet. Schritt 2: .pi-Ordner prüfen Im Terminal: ls ~/.pi/agent Wenn der Ordner noch nicht existiert, lege ihn an: mkdir -p ~/.pi/agent Schritt 3: models.json erstellen oder öffnen Zum Beispiel mit nano: nano ~/.pi/agent/models.json Oder mit VS Code: code ~/.pi/agent/models.json Minimal funktionierende Konfiguration Wenn du erstmal nur einen einfachen Eintrag willst, nimm das hier: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 16384, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Warum diese compat-Werte sinnvoll sind Viele OpenAI-kompatible Proxies sind nicht 100 % OpenAI-identisch. Deshalb sind diese Flags bei lokalen/proxy-basierten Setups oft hilfreich: supportsDeveloperRole: false Pi verwendet bei reasoning-fähigen Modellen teils die Rolle developer. Viele kompatible Server verstehen aber nur system. Mit false sendet Pi stattdessen system. supportsReasoningEffort: false Viele kompatible APIs kennen den Parameter reasoning_effort nicht. supportsUsageInStreaming: false Einige Server liefern keine Usage-Daten im Streaming oder brechen bei include_usage ab. maxTokensField: "max_tokens" Viele kompatible APIs erwarten eher max_tokens statt max_completion_tokens. Wenn du mehrere Modelle eintragen willst Dann ergänze einfach mehrere Einträge unter models. Beispiel: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 16384, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } }, { "id": "claude-3-5-sonnet", "name": "Straico Claude 3.5 Sonnet", "reasoning": false, "input": ["text"], "contextWindow": 200000, "maxTokens": 8192, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } }, { "id": "gemini-1.5-pro", "name": "Straico Gemini 1.5 Pro", "reasoning": false, "input": ["text"], "contextWindow": 1000000, "maxTokens": 8192, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Woher bekommst du die richtigen Modell-IDs? Das ist ein sehr wichtiger Punkt: Pi sendet an den Proxy genau den Wert aus id. Also müssen die IDs exakt so heißen, wie dein Proxy sie erwartet. Am besten so prüfen: curl http://127.0.0.1:11434/v1/models Dann bekommst du hoffentlich eine Liste in etwa so: { "data": [ { "id": "gpt-4o-mini", ... }, { "id": "claude-3-5-sonnet", ... } ] } Genau diese id-Werte übernimmst du in models.json. Wenn du dort falsche IDs einträgst, tauchen die Modelle zwar in Pi auf, aber Requests schlagen fehl. Bessere und sichere Variante mit Umgebungsvariable für den API-Key Falls dein Proxy einen echten Key erwartet, solltest du den nicht hart in models.json schreiben. 1. Umgebungsvariable setzen Temporär im aktuellen Terminal: export STRAICO_API_KEY="dein_key_hier" Oder dauerhaft in deiner Shell-Konfiguration, z. B. in ~/.zshrc oder ~/.bashrc: export STRAICO_API_KEY="dein_key_hier" Danach Shell neu laden: source ~/.zshrc oder: source ~/.bashrc 2. In models.json verwenden "apiKey": "$STRAICO_API_KEY" Beispiel komplett: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "$STRAICO_API_KEY", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 16384, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Danach in Pi verwenden Die Doku sagt: models.json wird jedes Mal neu geladen, wenn du /model öffnest. Du musst Pi also normalerweise nicht neu starten. Vorgehen in Pi Pi öffnen /model eingeben Nach deinem Provider bzw. Modell suchen Modell auswählen Was du in /model sehen solltest Pi listet die Einträge nach id, verwendet aber name für Anzeige/Matching-Details. Also z. B.: gpt-4o-mini claude-3-5-sonnet mit schönerem Anzeigenamen, falls gesetzt. Empfehlung: Erst mit einem einzigen Modell starten Bevor du 10 Modelle einträgst, teste erstmal nur eins: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false } ] } } } Das reicht oft schon, weil viele Felder Default-Werte haben. Noch robusteres Beispiel für viele Proxy-Server Wenn dein Proxy etwas zickig ist, ist diese Version oft ein guter Start: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "supportsStore": false, "supportsStrictMode": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 8192, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Falls du Bilder nutzen willst Wenn ein Modell Bildinput unterstützt, setze: "input": ["text", "image"] Beispiel: { "id": "gpt-4o", "name": "Straico GPT-4o", "reasoning": false, "input": ["text", "image"] } Aber nur dann, wenn dein Proxy/Upstream das wirklich unterstützt. Falls du Reasoning-Modelle eintragen willst Wenn ein Modell wirklich erweitertes Denken unterstützt, kannst du setzen: "reasoning": true Aber: Bei OpenAI-kompatiblen Proxies ist genau das oft der Bereich, wo Inkompatibilitäten auftreten. Deshalb mein Rat: zuerst mit reasoning: false testen erst später true aktivieren ggf. mit zusätzlichem compat feinjustieren Typische Dateistruktur am Ende Datei: ~/.pi/agent/models.json Beispielinhalt: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 8192, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Fehlerbehebung 1. Modell erscheint nicht in Pi Prüfe: Ist die Datei wirklich unter ~/.pi/agent/models.json gespeichert? Ist das JSON gültig? Öffnest du danach /model neu? JSON testen z. B. mit: cat ~/.pi/agent/models.json | jq . Wenn jq einen Fehler meldet, ist die Datei syntaktisch kaputt. 2. Modell erscheint, aber Antworten schlagen fehl Dann sind meist diese Ursachen wahrscheinlich: falsche id falscher baseUrl Proxy erwartet echten API-Key Proxy versteht bestimmte OpenAI-Felder nicht Dann probiere: id mit /v1/models prüfen apiKey auf echten Straico-Key umstellen compat erweitern 3. 401 / Unauthorized Dann erwartet dein Proxy wahrscheinlich Auth. Setze in models.json: "apiKey": "$STRAICO_API_KEY" und exportiere den Key in deiner Shell. 4. Fehler wegen unbekannter Rollen Dann ist fast immer dieses Flag nötig: "supportsDeveloperRole": false 5. Fehler wegen reasoning_effort Dann: "supportsReasoningEffort": false 6. Streaming- oder Usage-Fehler Dann: "supportsUsageInStreaming": false Optional: mehrere Provider statt eines einzigen Wenn du später zusätzlich noch z. B. echtes Ollama lokal oder andere Proxies nutzen willst, kannst du einfach in derselben Datei mehrere Provider definieren. Beispiel: { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "models": [ { "id": "gpt-4o-mini" } ] }, "ollama": { "baseUrl": "http://localhost:11434/v1", "api": "openai-completions", "apiKey": "ollama", "models": [ { "id": "llama3.1:8b" } ] } } } Aber Achtung: Wenn dein Straico-Proxy schon auf Port 11434 läuft, kollidiert das natürlich mit echtem lokalem Ollama. Mein praktischer Vorschlag für dich Wenn du einfach nur loslegen willst, würde ich genau so anfangen: ~/.pi/agent/models.json { "providers": { "straico-local": { "baseUrl": "http://127.0.0.1:11434/v1", "api": "openai-completions", "apiKey": "straico", "compat": { "supportsDeveloperRole": false, "supportsReasoningEffort": false, "supportsUsageInStreaming": false, "maxTokensField": "max_tokens" }, "models": [ { "id": "gpt-4o-mini", "name": "Straico GPT-4o Mini", "reasoning": false, "input": ["text"], "contextWindow": 128000, "maxTokens": 8192, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 } } ] } } } Dann: /model in Pi öffnen Modell auswählen Testprompt senden Wenn du willst, kann ich dir im nächsten Schritt auch noch eine von diesen drei Sachen direkt fertig bauen: eine konkrete models.json für deine Straico-Modelle, eine Minimalversion plus Debug-Version, oder eine Anleitung, wie du die verfügbaren Modell-IDs automatisch aus dem Proxy ausliest und korrekt in Pi einträgst. Wenn du möchtest, schreibe ich dir direkt die fertige models.json — am besten, wenn du mir die Ausgabe von curl http://127.0.0.1:11434/v1/models schickst. Pi: Packages aktualiseren Packages in Pi kannst du mit den pi update-Befehlen aktualisieren: Alle Packages aktualisieren: pi update oder nur die Extensions/Packages: pi update --extensions Nur ein bestimmtes Package aktualisieren: pi update npm:@foo/bar oder: pi update --extension npm:@foo/bar Nur Pi selbst aktualisieren, nicht die Packages: pi update --self Kurz: Für Packages allgemein nutzt man vor allem pi update oder pi update --extensions. Pi: Sich vorstellen? Ja — dafür gibt es nicht unbedingt einen speziellen „Vorstellungs“-Befehl, aber es gibt in Pi klare Wege, solche Präferenzen festzuhalten. Am passendsten aus deinem Kontext: 1. Über AGENTS.md Pi lädt beim Start automatisch: ~/.pi/agent/AGENTS.md für globale Anweisungen AGENTS.md oder CLAUDE.md im Projekt und in Parent-Verzeichnissen Dort kannst du Dinge reinschreiben wie: Bitte nenne mich Alex. Antworte auf Deutsch. Sei kurz und pragmatisch. Wenn etwas unklar ist, frage zuerst nach. Das ist der beste Weg, wenn du willst, dass Pi sich das dauerhaft merkt. Wichtig: Nach Änderungen Pi neu starten oder /reload ausführen. 2. Direkt in der Session sagen Du kannst einfach in einer Session schreiben: Nenne mich bitte Alex. Antworte auf Deutsch. Ich mag knappe Antworten. Das gilt dann für die laufende Unterhaltung, aber ist weniger dauerhaft als AGENTS.md. 3. Falls du es globaler/strikter willst: SYSTEM.md Laut Kontext kannst du auch den System-Prompt anpassen über: Projekt: .pi/SYSTEM.md Global: ~/.pi/agent/SYSTEM.md Oder ergänzen mit APPEND_SYSTEM.md. Das ist eher für stärkere, systemweite Steuerung gedacht. Für „Wie soll ich genannt werden?“ ist meist AGENTS.md einfacher und passender. Kurzantwort Nein, es scheint keinen speziellen eingebauten /introduce- oder Profil-Befehl dafür zu geben. Ja, du kannst das sehr gut über AGENTS.md lösen — z. B. global in ~/.pi/agent/AGENTS.md. Beispiel: Nenne mich Chris. Sprich mich per du an. Antworte standardmäßig auf Deutsch. Pi: NPM Pakete analysieren und aufräumen 1. Installierte Pakete anzeigen # Alle installierten Pakete (Top-Level) npm list --depth=0 # Inklusive Dev-Dependencies npm list --depth=0 --all # Global installierte Pakete npm list -g --depth=0 # Als JSON für weitere Verarbeitung npm list --json 2. Ungenutzte Pakete finden Mit depcheck (empfohlen) # Installation npm install -g depcheck # Analyse ausführen depcheck # Ausgabe zeigt: # - Unused dependencies # - Unused devDependencies # - Missing dependencies Mit npm-check npm install -g npm-check # Interaktiver Modus npm-check -u # Nur ungenutzte anzeigen npm-check --skip-unused 3. Pakete restlos entfernen # Einzelnes Paket entfernen npm uninstall paketname # Mehrere auf einmal npm uninstall paket1 paket2 paket3 # Dev-Dependency entfernen npm uninstall paketname --save-dev # Nach dem Entfernen: Cache leeren npm cache clean --force 4. Aufräumen # Verwaiste Pakete entfernen (nicht in package.json) npm prune # node_modules komplett neu aufbauen rm -rf node_modules package-lock.json npm install 5. Praktischer Workflow # 1. Überblick verschaffen npm list --depth=0 # 2. Ungenutzte finden depcheck # 3. Entfernen npm uninstall # 4. Testen ob alles noch funktioniert npm run build npm test Tipp: Package.json manuell prüfen Schau in dependencies und devDependencies: Wird das Paket wirklich importiert? Ist es vielleicht durch ein anderes ersetzt worden? Sind veraltete Polyfills noch nötig?