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:

Pi arbeitet direkt im aktuellen Projektordner.

2. Schnellstart unter Windows 11

Voraussetzungen

Du brauchst:

Laut Doku sucht Pi bash in dieser Reihenfolge:

  1. shellPath aus ~/.pi/agent/settings.json
  2. Git Bash: C:\Program Files\Git\bin\bash.exe
  3. 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.:

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

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:

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:

Zusätzliche read-only Tools:

7. Die wichtigsten Tastenkürzel

Eingabe

Steuerung

Modell / Thinking

Queue / Verlauf

8. Die wichtigsten Slash Commands

Muss man kennen

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 <path|id>

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

Nach Änderung:

/reload

oder Pi neu starten.

13. Die wichtigsten Settings unter Windows 11

Dateien:

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:

Faustregel

Wechseln:

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

Pi-spezifisch

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:

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:

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:

{
  "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe"
}

Problem: Shift+Enter geht nicht

Lösung:

Problem: Alt+Enter geht nicht

Lösung:

Problem: Auth klappt nicht

Check:

Problem: Pi arbeitet zu aggressiv im Dateisystem

Lösung:

pi --tools read,grep,find,ls

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

  1. Installieren:
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
  1. Starten:
pi

  1. Unter Windows brauchst du bash.

  2. Bestes Setup: Windows Terminal + Git Bash.

  3. Login:

/login

  1. API-Key alternativ via ENV.

  2. Neue Zeile:
    Shift+Enter

  3. Modell wechseln:
    Ctrl+L

  4. Shell-Befehl mit Kontext:

!npm test
  1. Shell-Befehl ohne Kontext:
!!npm test

  1. Datei referenzieren:
    @

  2. Alte Session:

pi -c
  1. Session-Baum:
/tree
  1. Projektanweisungen in:
AGENTS.md
  1. 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:

  1. Pi.Dev strukturiert verstehen kannst,
  2. gezielt einzelne Dokumentationsabschnitte abfragen kannst,
  3. sowohl Anfänger- als auch Fortgeschrittenenthemen abdeckst,
  4. 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:

Ich strukturiere die Fragen deshalb in Lernblöcke.

1. Überblick und Orientierung

Diese Fragen helfen dir, das Gesamtbild zu verstehen.

  1. Was ist Pi.Dev laut Dokumentation?
  2. Welches Problem löst Pi.Dev?
  3. Für wen ist Pi.Dev gedacht?
  4. Welche Hauptfunktionen bietet Pi.Dev?
  5. Wie ist die Dokumentation von Pi.Dev aufgebaut?
  6. Welche zentralen Konzepte muss man verstehen, bevor man mit Pi.Dev arbeitet?
  7. Welche Begriffe werden in der Dokumentation immer wieder verwendet?
  8. Gibt es in der Dokumentation eine empfohlene Lernreihenfolge?
  9. Welche ersten Schritte empfiehlt die Dokumentation für Einsteiger?
  10. Was unterscheidet Pi.Dev von ähnlichen Plattformen oder Frameworks?
  11. Welche typischen Anwendungsfälle nennt die Dokumentation?
  12. Welche Einschränkungen oder Grenzen von Pi.Dev werden genannt?
  13. Welche Komponenten oder Subsysteme gehören zu Pi.Dev?
  14. Welche Architektur oder welches Grundmodell liegt Pi.Dev zugrunde?
  15. Welche Voraussetzungen sollte man mitbringen, um Pi.Dev sinnvoll zu nutzen?

2. Einstieg und Setup

Damit kannst du Installation, Einrichtung und erste Nutzung verstehen.

  1. Wie installiert man Pi.Dev?
  2. Welche Systemvoraussetzungen nennt die Dokumentation?
  3. Welche Betriebssysteme oder Umgebungen werden unterstützt?
  4. Gibt es eine lokale Entwicklungsumgebung für Pi.Dev?
  5. Welche Tools oder Abhängigkeiten müssen vorab installiert werden?
  6. Wie sieht der schnellste Weg aus, Pi.Dev zum Laufen zu bringen?
  7. Gibt es eine Quickstart-Anleitung? Bitte fasse sie Schritt für Schritt zusammen.
  8. Wie erstellt man ein erstes Projekt in Pi.Dev?
  9. Wie startet man ein neues Pi.Dev-Projekt über CLI, UI oder API?
  10. Welche Konfigurationsdateien sind beim Start wichtig?
  11. Welche Umgebungsvariablen werden benötigt?
  12. Wie richtet man Authentifizierung oder Zugangsdaten ein?
  13. Wie überprüft man, ob die Installation korrekt funktioniert?
  14. Welche typischen Fehler beim Setup nennt die Dokumentation?
  15. Wie behebt man Installationsprobleme laut Doku?
  16. Gibt es Unterschiede zwischen Entwicklungs-, Test- und Produktionsumgebung?
  17. Wie aktualisiert man Pi.Dev auf eine neue Version?
  18. Wie deinstalliert oder bereinigt man eine Pi.Dev-Installation?
  19. Welche Best Practices für ein sauberes Setup werden genannt?
  20. Gibt es offizielle Starter-Templates oder Beispielprojekte?

3. Kernbegriffe und Datenmodell

Hier geht es um die „Sprache“ von Pi.Dev.

  1. Welche zentralen Objekte, Entitäten oder Ressourcen definiert Pi.Dev?
  2. Was bedeuten die wichtigsten Fachbegriffe in Pi.Dev?
  3. Welche Beziehungen bestehen zwischen den zentralen Objekten?
  4. Gibt es ein Datenmodell oder Schema? Bitte erklären.
  5. Welche Felder oder Eigenschaften haben die wichtigsten Ressourcen?
  6. Welche Objekte sind für Anfänger am wichtigsten?
  7. Welche Objekte werden am häufigsten in Beispielen verwendet?
  8. Welche Lebenszyklen haben die Hauptobjekte?
  9. Wie entstehen, verändern und verschwinden diese Objekte?
  10. Gibt es Zustände oder Statusmodelle für bestimmte Entitäten?
  11. Welche IDs, Referenzen oder Schlüsselkonzepte werden verwendet?
  12. Welche Objekte sind persistent, welche temporär?
  13. Welche Standardwerte oder Defaults sind wichtig?
  14. Welche Validierungsregeln gelten für Eingaben oder Ressourcen?
  15. Welche typischen Fehler entstehen durch Missverständnisse im Datenmodell?

4. API-Grundlagen

Falls Pi.Dev APIs hat, solltest du sie systematisch abfragen.

  1. Welche APIs bietet Pi.Dev?
  2. Gibt es REST-, GraphQL-, SDK- oder andere Schnittstellen?
  3. Wie authentifiziert man sich an der API?
  4. Welche Authentifizierungsverfahren werden unterstützt?
  5. Wie ist die API-Dokumentation strukturiert?
  6. Welche wichtigsten Endpunkte sollte man zuerst lernen?
  7. Wie erstellt man eine erste erfolgreiche API-Anfrage?
  8. Wie sieht ein minimales Request/Response-Beispiel aus?
  9. Welche Header, Parameter und Payloads sind typisch?
  10. Wie werden Fehler über die API zurückgegeben?
  11. Welche HTTP-Statuscodes oder Fehlercodes verwendet Pi.Dev?
  12. Gibt es Rate Limits oder Nutzungslimits?
  13. Wie funktioniert Pagination?
  14. Wie funktioniert Filtering, Sorting und Searching?
  15. Wie funktionieren Create-, Read-, Update- und Delete-Operationen?
  16. Welche API-Ressourcen sind zentral für typische Workflows?
  17. Welche API-Konventionen oder Namensmuster verwendet Pi.Dev?
  18. Gibt es Versionierung der API?
  19. Wie migriert man zwischen API-Versionen?
  20. Welche Sicherheitsaspekte gelten bei der API-Nutzung?
  21. Gibt es Webhooks, Events oder Streaming-Schnittstellen?
  22. Wie testet man API-Anfragen am besten laut Dokumentation?
  23. Gibt es offizielle Codebeispiele für verschiedene Programmiersprachen?
  24. Welche häufigen API-Fehler nennt die Doku und wie löst man sie?
  25. Welche API-Funktionen gelten als experimentell oder veraltet?

5. CLI, SDKs und Entwicklerwerkzeuge

  1. Gibt es eine CLI für Pi.Dev? Welche Hauptbefehle existieren?
  2. Wie installiert und konfiguriert man die CLI?
  3. Welche Kommandos sollte man als Erstes kennen?
  4. Wie authentifiziert sich die CLI?
  5. Wie erstellt, startet, testet oder deployed man Projekte über die CLI?
  6. Welche Flags und Optionen sind besonders wichtig?
  7. Gibt es einen Debug- oder Verbose-Modus?
  8. Welche SDKs stellt Pi.Dev bereit?
  9. Für welche Sprachen gibt es offizielle Bibliotheken?
  10. Wie verwendet man das SDK in Sprache X? Bitte mit Beispiel.
  11. Welche Unterschiede gibt es zwischen API, SDK und CLI?
  12. Wann sollte man welches Tool verwenden?
  13. Gibt es Generatoren, Templates oder Scaffolding-Werkzeuge?
  14. Welche lokalen Developer-Tools empfiehlt die Dokumentation?
  15. Wie lassen sich Logs, Fehler und Requests lokal inspizieren?

6. Projektstruktur und Konfiguration

  1. Wie ist ein typisches Pi.Dev-Projekt aufgebaut?
  2. Welche Ordner und Dateien sind standardmäßig enthalten?
  3. Welche Datei ist für welche Konfiguration zuständig?
  4. Welche Konfigurationsoptionen sind besonders wichtig?
  5. Wie werden Umgebungen getrennt konfiguriert?
  6. Wie verwaltet man Secrets und sensible Daten?
  7. Wie überschreibt man Standardkonfigurationen?
  8. Welche Konfiguration ist verpflichtend, welche optional?
  9. Gibt es Konventionen für Dateibenennung oder Projektstruktur?
  10. Wie validiert Pi.Dev die Konfiguration?
  11. Welche Konfigurationsfehler treten häufig auf?
  12. Wie dokumentiert die Doku empfohlene Projektorganisation?
  13. Gibt es Unterschiede zwischen kleinem und großem Projekt-Setup?
  14. Wie konfiguriert man externe Integrationen?
  15. Wie geht Pi.Dev mit lokaler gegenüber produktiver Konfiguration um?

7. Erster praktischer Workflow

Diese Fragen helfen dir, echtes Arbeiten zu verstehen.

  1. Was ist der einfachste End-to-End-Workflow in Pi.Dev?
  2. Wie erstellt man mit Pi.Dev ein minimales funktionierendes Beispiel?
  3. Welche Schritte umfasst ein Standard-Workflow von Anfang bis Ende?
  4. Welche Ressourcen müssen in welcher Reihenfolge erstellt werden?
  5. Welche Eingaben sind zwingend nötig?
  6. Welche Ausgabe oder welches Ergebnis erhält man am Ende?
  7. Wie überprüft man, ob der Workflow korrekt funktioniert?
  8. Welche typischen Anfängerfehler passieren im ersten Workflow?
  9. Gibt es in der Doku ein Hello-World-Beispiel? Bitte vollständig erklären.
  10. Welche Teile dieses Beispielprojekts sind besonders lehrreich?
  11. Wie lässt sich das Grundbeispiel erweitern?
  12. Welche Varianten eines Basis-Workflows beschreibt die Doku?
  13. Welche Schritte lassen sich automatisieren?
  14. Welche Logs oder Debugging-Hinweise helfen beim ersten Workflow?
  15. Wie übersetzt man das Beispiel in einen realen Anwendungsfall?

8. Fortgeschrittene Funktionen

  1. Welche fortgeschrittenen Features bietet Pi.Dev?
  2. Welche Features sollte man erst nach den Grundlagen lernen?
  3. Gibt es Automatisierungen, Pipelines oder Orchestrierungskonzepte?
  4. Wie arbeitet Pi.Dev mit komplexeren Workflows?
  5. Wie werden Abhängigkeiten zwischen Komponenten modelliert?
  6. Gibt es Event-getriebene oder asynchrone Mechanismen?
  7. Unterstützt Pi.Dev Hintergrundprozesse oder Jobs?
  8. Gibt es Zustandsmaschinen, Trigger oder Rules?
  9. Wie werden komplexe Eingaben oder verschachtelte Strukturen verarbeitet?
  10. Welche erweiterten Konfigurationsmöglichkeiten gibt es?
  11. Welche Skalierungsmechanismen nennt die Doku?
  12. Welche fortgeschrittenen Sicherheitsfunktionen gibt es?
  13. Gibt es Mandantenfähigkeit, Rollen oder Berechtigungsmodelle?
  14. Welche erweiterten Integrationsmöglichkeiten werden beschrieben?
  15. Welche Features gelten als Best Practice für produktive Nutzung?
  16. Welche fortgeschrittenen Fehlerquellen gibt es?
  17. Welche Architekturentscheidungen empfiehlt die Doku für größere Projekte?
  18. Welche Möglichkeiten zur Wiederverwendung oder Modularisierung gibt es?
  19. Wie lassen sich wiederkehrende Abläufe abstrahieren?
  20. Welche fortgeschrittenen Patterns zeigt die Dokumentation?

9. Authentifizierung, Autorisierung und Sicherheit

  1. Welche Sicherheitsmodelle unterstützt Pi.Dev?
  2. Wie funktioniert Authentifizierung in Pi.Dev genau?
  3. Welche Rollen oder Berechtigungsmodelle gibt es?
  4. Wie vergibt man Zugriffsrechte?
  5. Wie schützt man API-Schlüssel, Tokens oder Secrets?
  6. Welche Best Practices für Sicherheit nennt die Dokumentation?
  7. Welche Sicherheitsrisiken werden ausdrücklich erwähnt?
  8. Wie geht Pi.Dev mit Nutzeridentitäten um?
  9. Gibt es Single Sign-On, OAuth oder andere Auth-Verfahren?
  10. Wie erneuert oder widerruft man Tokens?
  11. Wie protokolliert oder auditierbar sind sicherheitsrelevante Aktionen?
  12. Welche Konfigurationen sind für Produktion aus Sicherheitsgründen wichtig?
  13. Welche häufigen Sicherheitsfehler machen Entwickler laut Doku?
  14. Wie trennt man Rechte zwischen Entwicklung, Test und Produktion?
  15. Gibt es Compliance-, Datenschutz- oder Governance-Hinweise?

10. Datenverarbeitung, Persistenz und Speicher

  1. Wie speichert Pi.Dev Daten?
  2. Welche Datenspeicher oder Storage-Konzepte werden verwendet?
  3. Welche Daten sind dauerhaft, welche flüchtig?
  4. Wie werden Daten gelesen, geschrieben, aktualisiert und gelöscht?
  5. Gibt es Transaktionen oder Konsistenzregeln?
  6. Wie modelliert Pi.Dev Beziehungen zwischen Datenobjekten?
  7. Welche Limits für Datengrößen oder Payloads nennt die Doku?
  8. Wie funktioniert Dateispeicherung oder Asset-Handling?
  9. Wie werden Backups oder Wiederherstellung behandelt?
  10. Gibt es Export- oder Importfunktionen?
  11. Welche Performance-Hinweise zur Datennutzung nennt die Dokumentation?
  12. Wie geht Pi.Dev mit Versionsständen oder Revisionen um?
  13. Welche Bereinigung oder Retention-Mechanismen gibt es?
  14. Wie vermeidet man Dateninkonsistenzen?
  15. Welche Best Practices für Datenmodellierung und Datenzugriff werden genannt?

11. Events, Webhooks, Automatisierung

  1. Unterstützt Pi.Dev Events oder Webhooks?
  2. Welche Event-Typen gibt es?
  3. Wie registriert oder konfiguriert man Webhooks?
  4. Welche Payloads enthalten Webhooks?
  5. Wie validiert man eingehende Webhook-Nachrichten?
  6. Wie geht Pi.Dev mit Retries oder Zustellfehlern um?
  7. Welche Sicherheitsmechanismen gibt es bei Webhooks?
  8. Wie debuggt man fehlgeschlagene Webhooks?
  9. Welche typischen Use Cases für Events beschreibt die Doku?
  10. Wie verbindet man Pi.Dev mit externen Automatisierungssystemen?
  11. Welche Unterschiede gibt es zwischen Polling und Event-basierter Nutzung?
  12. Wie baut man eine robuste Event-Verarbeitung mit Pi.Dev auf?
  13. Gibt es Reihenfolge-, Idempotenz- oder Duplikat-Hinweise?
  14. Welche Best Practices für Event-Handling nennt die Doku?
  15. Welche Limits oder Fallstricke gibt es bei Webhooks und Events?

12. Testing, Debugging und Qualitätssicherung

  1. Welche Teststrategien empfiehlt die Dokumentation für Pi.Dev?
  2. Wie testet man Projekte lokal?
  3. Gibt es Mocking-, Sandbox- oder Testumgebungen?
  4. Wie schreibt man Unit-, Integrations- oder End-to-End-Tests mit Pi.Dev?
  5. Welche Debugging-Tools stehen zur Verfügung?
  6. Wie liest und interpretiert man Logs?
  7. Welche typischen Fehlermeldungen treten auf und was bedeuten sie?
  8. Wie reproduziert man Probleme systematisch?
  9. Welche Diagnoseschritte empfiehlt die Doku bei Fehlern?
  10. Wie validiert man Konfigurationen vor dem Deployment?
  11. Gibt es Health Checks oder Statusprüfungen?
  12. Wie überwacht man Laufzeitprobleme?
  13. Welche Best Practices zur Qualitätssicherung nennt Pi.Dev?
  14. Wie erkennt man Performance-Probleme?
  15. Welche Anti-Patterns im Debugging werden erwähnt?

13. Deployment und Betrieb

  1. Wie deployt man ein Pi.Dev-Projekt?
  2. Welche Deployment-Modelle unterstützt Pi.Dev?
  3. Welche Voraussetzungen gelten für Produktion?
  4. Wie unterscheidet sich lokaler Betrieb von Produktion?
  5. Wie konfiguriert man Produktionsumgebungen?
  6. Wie verwaltet man Secrets im Deployment?
  7. Welche Build- oder Release-Schritte sind nötig?
  8. Gibt es CI/CD-Empfehlungen in der Dokumentation?
  9. Wie funktioniert Rollback?
  10. Wie überwacht man eine produktive Pi.Dev-Anwendung?
  11. Welche Skalierungsoptionen werden beschrieben?
  12. Wie geht Pi.Dev mit Ausfällen oder Fehlerfällen in Produktion um?
  13. Gibt es Zero-Downtime- oder Migrationshinweise?
  14. Welche Infrastruktur-Empfehlungen gibt die Doku?
  15. Welche typischen Produktionsfehler nennt die Dokumentation?

14. Performance und Skalierung

  1. Welche Performance-Empfehlungen gibt die Doku?
  2. Wo entstehen typischerweise Engpässe in Pi.Dev?
  3. Welche Limits nennt die Dokumentation?
  4. Wie optimiert man API-Nutzung in Pi.Dev?
  5. Wie reduziert man Latenz?
  6. Welche Caching-Strategien werden empfohlen?
  7. Wie geht Pi.Dev mit hoher Last um?
  8. Welche Skalierungsstrategien sind vorgesehen?
  9. Wie erkennt man ineffiziente Nutzungsmuster?
  10. Welche Metriken sollte man beobachten?
  11. Wie optimiert man Speicher- oder Rechenverbrauch?
  12. Welche Trade-offs zwischen Einfachheit und Performance beschreibt die Doku?
  13. Welche Empfehlungen gibt es für große Datenmengen oder viele Requests?
  14. Welche Anti-Patterns verschlechtern die Performance?
  15. Wie benchmarkt oder profiliert man Pi.Dev-basierte Systeme?

15. Integrationen und Ökosystem

  1. Welche externen Dienste kann Pi.Dev integrieren?
  2. Welche offiziellen Integrationen werden dokumentiert?
  3. Wie verbindet man Pi.Dev mit Datenbanken, APIs oder Dritttools?
  4. Welche Authentifizierungsanforderungen gelten bei Integrationen?
  5. Wie konfiguriert man eine externe Integration Schritt für Schritt?
  6. Welche Integrationen sind besonders häufig oder wichtig?
  7. Welche Einschränkungen gibt es bei Integrationen?
  8. Wie geht Pi.Dev mit Fehlern in externen Systemen um?
  9. Welche Best Practices für robuste Integrationen nennt die Doku?
  10. Gibt es Community- oder Drittanbieter-Erweiterungen?
  11. Wie entwickelt man eine eigene Integration?
  12. Gibt es Plugin-, Adapter- oder Extension-Konzepte?
  13. Wie testet man Integrationen zuverlässig?
  14. Welche Sicherheitsrisiken gibt es bei Integrationen?
  15. Welche Integrationsbeispiele bietet die Doku?

16. Architektur, Design Patterns und Best Practices

  1. Welche Architekturprinzipien empfiehlt die Dokumentation für Pi.Dev-Projekte?
  2. Welche Design Patterns tauchen in der Doku wiederholt auf?
  3. Wie strukturiert man ein größeres Pi.Dev-Projekt sauber?
  4. Welche Modularisierungsstrategien werden empfohlen?
  5. Wie trennt man Verantwortlichkeiten in Pi.Dev-Anwendungen?
  6. Welche Wiederverwendungsstrategien gibt es?
  7. Welche Best Practices gelten für Wartbarkeit?
  8. Welche Best Practices gelten für Lesbarkeit und Teamarbeit?
  9. Welche Anti-Patterns nennt die Dokumentation?
  10. Welche Beispiele für gute Architektur enthält die Doku?
  11. Wie plant man Pi.Dev-Projekte langfristig?
  12. Welche Prinzipien helfen bei Änderbarkeit und Erweiterbarkeit?
  13. Wie verhindert man technische Schulden laut Doku?
  14. Welche Patterns eignen sich für kleine, welche für große Projekte?
  15. Wie begründet die Dokumentation ihre empfohlenen Architekturentscheidungen?

17. Fehlerbehandlung und Troubleshooting

  1. Welche Fehlerkategorien unterscheidet Pi.Dev?
  2. Wie erkennt man Konfigurationsfehler?
  3. Wie erkennt man Authentifizierungs- und Berechtigungsfehler?
  4. Wie erkennt man API- oder Netzwerkfehler?
  5. Welche Standardstrategie zur Fehlersuche empfiehlt die Doku?
  6. Welche häufigen Anfängerfehler nennt die Dokumentation?
  7. Welche häufigen Produktionsprobleme nennt die Dokumentation?
  8. Wie interpretiert man Fehlermeldungen korrekt?
  9. Welche Logs oder Diagnosedaten sind im Fehlerfall am wichtigsten?
  10. Welche Retry-Strategien werden empfohlen?
  11. Wann sollte man Fehler abfangen und wann weiterreichen?
  12. Welche Fehler sollte man dem Nutzer zeigen, welche intern behandeln?
  13. Wie dokumentiert Pi.Dev bekannte Probleme oder Limitierungen?
  14. Gibt es Troubleshooting-Guides oder FAQ-Bereiche?
  15. Welche Maßnahmen helfen, Fehler proaktiv zu vermeiden?

18. Versionierung, Migration und Breaking Changes

  1. Wie versioniert Pi.Dev seine Plattform, APIs oder SDKs?
  2. Welche Migrationsleitfäden enthält die Dokumentation?
  3. Wie erkennt man Breaking Changes?
  4. Welche Upgrade-Strategie empfiehlt Pi.Dev?
  5. Wie migriert man ein bestehendes Projekt auf eine neue Version?
  6. Welche Teile ändern sich bei Upgrades am häufigsten?
  7. Gibt es Deprecation-Hinweise?
  8. Wie lange werden alte Versionen unterstützt?
  9. Welche Rückwärtskompatibilität garantiert Pi.Dev?
  10. Wie testet man ein Upgrade sicher?
  11. Welche typischen Migrationsfehler nennt die Doku?
  12. Wie dokumentiert Pi.Dev Änderungen zwischen Versionen?
  13. Welche Changelog- oder Release-Notes-Struktur wird verwendet?
  14. Wie bereitet man sich auf zukünftige Änderungen vor?
  15. Welche Best Practices gelten für wartbare, upgradefreundliche Projekte?

19. Praxisbeispiele und Tutorials

  1. Welche Tutorials enthält die Dokumentation?
  2. Welche Beispielprojekte gibt es?
  3. Welches Tutorial eignet sich am besten für Anfänger?
  4. Welche Tutorials decken fortgeschrittene Themen ab?
  5. Wie lässt sich jedes Tutorial in Lernziele zerlegen?
  6. Welche Konzepte lernt man aus Beispielprojekt X?
  7. Welche Annahmen setzen die Tutorials voraus?
  8. Welche Schritte in den Tutorials sind besonders wichtig?
  9. Welche impliziten Details werden im Tutorial nicht ausdrücklich erklärt?
  10. Wie kann man ein Tutorial abwandeln, um das Gelernte zu vertiefen?
  11. Welche häufigen Probleme treten beim Nachbauen der Tutorials auf?
  12. Wie überträgt man ein Tutorial auf einen realen Use Case?
  13. Welche Best Practices lassen sich aus den Tutorials ableiten?
  14. Welche Fehler oder Vereinfachungen enthalten die Tutorials möglicherweise?
  15. 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.

  1. Bitte fasse die gesamte Pi.Dev-Dokumentation in 10 Hauptthemen zusammen.
  2. Welche Kapitel der Dokumentation sind für Einsteiger am wichtigsten?
  3. Welche Kapitel sollte man erst später lesen?
  4. Welche Begriffe sollte ich mir als Glossar notieren?
  5. Welche Konzepte werden an mehreren Stellen der Doku erklärt?
  6. Wo gibt es mögliche Widersprüche oder Unklarheiten in der Dokumentation?
  7. Welche Informationen werden vorausgesetzt, aber nicht erklärt?
  8. Welche Kapitel hängen logisch voneinander ab?
  9. Welche Teile der Doku sind besonders praxisrelevant?
  10. Welche Teile sind eher Referenz als Lernstoff?
  11. Bitte erstelle mir aus der Doku einen Lernpfad für 7 Tage.
  12. Bitte erstelle mir aus der Doku einen Lernpfad für 30 Tage.
  13. Welche Fragen sollte ich nach dem Lesen von Kapitel X beantworten können?
  14. Welche Wissenslücken hätte ich vermutlich nach dem Quickstart noch?
  15. Welche Stellen der Dokumentation sollte ich bookmarken?
  16. Welche API- oder Referenzseiten brauche ich im Alltag am häufigsten?
  17. Welche Beispiele aus der Doku sind am aussagekräftigsten?
  18. Bitte extrahiere alle Best Practices aus der Dokumentation.
  19. Bitte extrahiere alle Warnungen, Einschränkungen und Fallstricke aus der Dokumentation.
  20. Bitte extrahiere alle Codebeispiele und gruppiere sie thematisch.

21. Fragen für systematisches Lernen in Stufen

Stufe A: Anfänger

  1. Was muss ich über Pi.Dev wissen, um überhaupt starten zu können?
  2. Welche 20 Prozent der Doku geben mir 80 Prozent des Nutzens?
  3. Welche drei ersten praktischen Aufgaben sollte ich mit Pi.Dev umsetzen?
  4. Welche Konzepte darf ich auf keinen Fall verwechseln?
  5. Welche Minimalbeispiele sollte ich unbedingt nachbauen?
  6. Wie erkenne ich, dass ich die Grundlagen verstanden habe?
  7. Welche häufigen Missverständnisse haben Anfänger?
  8. Welche Kapitel sind Pflichtlektüre für Anfänger?
  9. Welche Fachbegriffe sollte ich zuerst lernen?
  10. Was ist der einfachste produktive Use Case mit Pi.Dev?

Stufe B: Mittelstufe

  1. Welche Konzepte brauche ich, um mehr als nur das Quickstart zu verstehen?
  2. Wie strukturiere ich ein echtes Projekt mit Pi.Dev?
  3. Welche Konfigurationen und Workflows sind im Alltag am wichtigsten?
  4. Welche Integrationen sollte ich früh lernen?
  5. Welche Fehlerquellen treten in echten Projekten besonders oft auf?
  6. Welche Best Practices unterscheiden gute von schlechten Pi.Dev-Projekten?
  7. Wie mache ich mein Projekt robuster, sicherer und wartbarer?
  8. Welche fortgeschrittenen Features bringen den größten Mehrwert?
  9. Wie teste und deploye ich ein Pi.Dev-Projekt professionell?
  10. Welche Architekturentscheidungen sollte ich früh treffen?

Stufe C: Fortgeschrittene

  1. Wie skaliere ich Pi.Dev für größere Projekte oder Teams?
  2. Welche Architektur-Patterns empfiehlt die Doku für komplexe Systeme?
  3. Wie optimiere ich Performance, Sicherheit und Betrieb?
  4. Welche Migrations- und Versionsstrategien sind langfristig sinnvoll?
  5. Wie baue ich erweiterbare Integrationen oder Module?
  6. Welche betrieblichen Risiken muss ich in Produktion beachten?
  7. Welche Grenzen der Plattform werden bei fortgeschrittener Nutzung relevant?
  8. Welche Entscheidungen sind schwer rückgängig zu machen?
  9. Welche Trade-offs beschreibt die Doku zwischen Einfachheit, Kontrolle und Skalierung?
  10. 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

B. Vergleichsfragen

C. Prozessfragen

D. Fehlerfragen

E. Best-Practice-Fragen

F. Strukturfragen

G. Extraktionsfragen

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.

  1. „Erkläre mir Thema X ausschließlich auf Basis der bereitgestellten Pi.Dev-Dokumentation und nenne die relevanten Abschnitte.“

  2. „Fasse mir Kapitel X in einfachen Worten zusammen und nenne anschließend die wichtigsten Fachbegriffe.“

  3. „Erstelle aus den Dokumentationsabschnitten zu X eine Schritt-für-Schritt-Anleitung für Anfänger.“

  4. „Vergleiche die Konzepte X und Y nur anhand der Dokumentation und gib typische Anwendungsfälle an.“

  5. „Extrahiere aus der Doku alle Best Practices, Warnungen und Fallstricke zu Thema X.“

  6. „Zeige mir zu Thema X alle relevanten Konfigurationsoptionen mit Bedeutung, Defaults und Beispielen.“

  7. „Erstelle mir zu Thema X fünf Verständnisfragen mit Antworten basierend auf der Doku.“

  8. „Nenne mir zu Thema X die häufigsten Fehler und erkläre, wie die Dokumentation ihre Behebung beschreibt.“

  9. „Baue aus den Dokumentationsstellen zu X einen Lernpfad: Grundlagen, Praxis, fortgeschrittene Nutzung.“

  10. „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

Phase 2: Setup

Phase 3: Grundlagen

Phase 4: Praxis

Phase 5: Professionelle Nutzung

Phase 6: Meisterschaft

25. Mein praktischer Tipp für dein RAG-Setup

Wenn du diese Fragen wirklich gut nutzen willst, formuliere sie möglichst so:

Beispiel statt:

besser:

Oder statt:

besser:

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:

Damit adressiert Pi.Dev vor allem diese Probleme:

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:

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:

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:

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:

  1. 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

  2. Anpassbarkeit statt fest eingebauter Features

    • Solche Workflows baut man bei Pi selbst über:
      • Extensions
      • Packages
      • externe Tools wie Container oder tmux

  3. 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.

  4. 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

  5. Programmgesteuerte Nutzung

    • Pi kann nicht nur interaktiv, sondern auch programmgesteuert verwendet werden über:
      • SDK
      • RPC mode
      • JSON event stream
      • TUI components

  6. 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:

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:

  1. Quickstart
    Installation, Authentifizierung, erste Session.

  2. Using Pi
    Interaktiver Modus, Slash-Commands, Context Files, CLI.

  3. Providers
    Anbieter, Subscription/API-Key-Setup, Modellzugang.

  4. Settings
    Globale und projektbezogene Konfiguration.

  5. Keybindings
    Standard-Shortcuts und Anpassungen.

  6. Sessions
    Session-Verwaltung, Branching, Tree-Navigation.

  7. Compaction
    Kontextkomprimierung und Zusammenfassungen.

Für Erweiterungen geht es danach typischerweise weiter mit:

  1. Extensions / Quick Start
  2. Writing an Extension
  3. Events, Lifecycle, ExtensionContext
  4. 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:

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:

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:

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:

Außerdem wird implizit sichtbar, dass die eingebauten Tools auf diese Liste begrenzt sind:

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:

Unter Customization / Programmatic usage:

Weitere Referenz-/Plattformbereiche:

Außerdem im Paket-/Erweiterungsbereich:

Und speziell für TUI-Komponenten:

Welche Architektur oder welches Grundmodell liegt Pi.Dev zugrunde?

Pi.Dev basiert auf einem kleinen, modularen Kern.

Das Grundmodell laut Kontext ist:

Zusätzlich ist Pi bewusst so entworfen, dass es nicht viele fest eingebaute Funktionen mitbringt, wie z. B.:

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:

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:

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:

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:

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

  1. Pi öffnen
  2. /model eingeben
  3. Nach deinem Provider bzw. Modell suchen
  4. 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.:

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:

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:

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:

Dann probiere:

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:

  1. /model in Pi öffnen
  2. Modell auswählen
  3. Testprompt senden

Wenn du willst, kann ich dir im nächsten Schritt auch noch eine von diesen drei Sachen direkt fertig bauen:

  1. eine konkrete models.json für deine Straico-Modelle,
  2. eine Minimalversion plus Debug-Version,
  3. 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:

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:

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:

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:

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 <ungenutzte-pakete>

# 4. Testen ob alles noch funktioniert
npm run build
npm test

Tipp: Package.json manuell prüfen

Schau in dependencies und devDependencies: