Extensions

Pi Extensions — den Coding Agent selbst erweitern

0:00 Jetzt kommen wir an den Punkt, an dem sich der ganze Entwurf von Pi erklärt. Extensions sind der Grund, warum der Kern klein bleiben darf: Was fehlt, schreiben Sie selbst — in TypeScript, in einer Datei, in Ihrem Projekt. Wir schauen uns die drei Hebel an, die Ihnen dafür zur Verfügung stehen: Ereignisse abonnieren, Werkzeuge registrieren, Kommandos anlegen.

0:21 Und wir sprechen über die Verantwortung, die damit kommt — denn eine Erweiterung läuft mit denselben Rechten wie alles andere in diesem Prozess.

Den Agenten umbauen

0:30 Acht Kapitel, die vom Grundgerüst bis zur selbstgeschriebenen Sicherheitsregel führen. Ein Hinweis vorweg, den ich in jedem Kapitel wiederholen werde: Erweiterungen sind TypeScript mit vollen Prozessrechten. Das ist gleichzeitig ihre Stärke und ihr Risiko. Wenn Sie in Ihrem Team eine Erweiterung einführen, ist sie kein Konfigurationsdetail, sondern Code — mit Review, mit Tests, mit Verantwortlichkeit.

0:54 Wer das ernst nimmt, bekommt ein Werkzeug, das genau auf das eigene Projekt passt. Vier Punkte. Erstens der Aufbau: eine Erweiterung ist ein TypeScript-Modul, das eine Schnittstelle bekommt und damit arbeitet. Zweitens die drei Hebel — Ereignisse, Werkzeuge, Kommandos —, mit denen sich fast alles abdecken lässt. Drittens die Berechtigungsprüfungen über das Werkzeugaufruf-Ereignis; das ist die Stelle, an der Sie die Nachfragen bauen, die der Kern nicht mitbringt.

1:23 Und viertens der sichere Entwurf: enge Zuständigkeit, klare Grenzen, lesbarer Code.

Architektur und Möglichkeiten von Pi Extensions

1:29 Beginnen wir mit dem Aufbau. Er ist überschaubar — eine Datei, eine exportierte Funktion, ein Objekt mit Methoden. Und zwei Fragen aus dem Alltag klären wir gleich mit: Wo liegen Erweiterungen, und wann werden sie geladen? Eine Erweiterung ist ein TypeScript-Modul, das eine Standardfunktion exportiert und dabei die Erweiterungs-Schnittstelle erhält.

1:51 Geladen wird aus zwei Orten: einem globalen Verzeichnis für alle Projekte und einem projektlokalen, das Projektvertrauen voraussetzt. Zum Testen gibt es eine Startoption für eine einzelne Datei. Das Bild dazu: ein Steuergerät mit Anschlussleiste. Sie klemmen Ihre eigene Logik an definierte Kontakte — Sie öffnen nicht das Gerät. Genau das meint das Projekt mit „ohne die Innereien forken zu müssen".

2:16 Die Ereignisliste ist lang und gut sortiert: Sitzungsstart, Agentenstart, Werkzeugaufruf, Eingabe, Modellwahl und weitere. Über eine Methode registrieren Sie Werkzeuge, die das Modell aufrufen kann; über eine andere eigene Schrägstrich-Kommandos für Menschen. Und ein Detail, das die Entwicklung angenehm macht: Ein Neuladen-Befehl lädt Erweiterungen ohne Sitzungsverlust.

2:38 Sie ändern also Code, laden neu und probieren weiter — eine kurze Rückkopplungsschleife, wie man sie sich beim Experimentieren wünscht. Worauf es hier ankommt, ist die Struktur, nicht die Zeilen. Ein Typ-Import, eine exportierte Standardfunktion, die das Schnittstellenobjekt bekommt — und darin die Registrierungen. Im Beispiel ist es nur eine Meldung beim Sitzungsstart, aber das Muster ist immer dasselbe: Sie hängen sich an einen Zeitpunkt und tun etwas.

3:06 Die Fußnote nennt ein Detail für später: Asynchrone Fabrikfunktionen laufen fertig, bevor das Sitzungsstart-Ereignis feuert. Sie können also aufwendige Vorbereitung erledigen, ohne Wettläufe zu riskieren.

Eigene Tools ergänzen

3:19 Jetzt der erste große Hebel: eigene Werkzeuge. Damit erweitern Sie nicht Ihre Bedienung, sondern die Fähigkeiten des Modells — und das ist ein wichtiger Unterschied. Ein Werkzeug wird registriert und ist danach vom Modell aufrufbar. Es hat einen Namen, eine Beschreibung, typisierte Parameter und eine Ausführungsfunktion, die Inhalt zurückgibt.

3:40 Die Parameter werden über ein Schema beschrieben — damit kann das Modell keine unsinnigen Aufrufe formulieren, weil die Form vorgegeben ist. Der Vergleich: Sie hängen ein neues Werkzeug an die Wandtafel und schreiben darunter, wofür es gut ist. Ob es benutzt wird, entscheidet die Beschriftung — genau wie bei den Skills.

3:59 Die Beschreibung entscheidet, ob das Modell das Werkzeug wählt — dieselbe Logik wie bei Skills, und derselbe häufige Fehler. Typisierte Parameter verhindern unsinnige Aufrufe und ersparen Ihnen Prüfcode. Ein eigenes Werkzeug kann außerdem etwas kapseln, das als freies Shell-Kommando riskant wäre: Sie erlauben genau eine Operation mit genau diesen Werten.

4:20 Und Rückgaben landen als Werkzeugergebnis im Kontext — halten Sie sie deshalb knapp, sonst zahlen Sie bei jedem Aufruf mit Kontextbudget. Worauf es hier ankommt, sind vier Bestandteile. Der Name, unter dem das Modell das Werkzeug anspricht. Die Beschreibung, die über die Auswahl entscheidet. Das Parameterschema, hier ein einzelner Textwert. Und die Ausführungsfunktion, die strukturierten Inhalt zurückgibt. Das Beispiel ist absichtlich banal — ein Gruß.

4:49 Ersetzen Sie es im Kopf durch etwas Nützliches: eine Abfrage in Ihrer Testdatenbank, ein Generator für Projektdateien, ein Aufruf Ihres internen Dienstes. Und schreiben Sie die Beschreibung so, wie Sie eine Skill-Beschreibung schreiben würden: mit Auslösern. In dieser Übung kapseln Sie eine wiederkehrende Projektoperation als typisiertes Werkzeug — statt sie über freie Shell-Aufrufe zu erledigen.

5:13 Das Erfolgskriterium hat einen anspruchsvollen Teil: Das Modell muss das Werkzeug bei passender Aufgabe selbst aufrufen. Damit prüfen Sie Ihre Beschreibung, nicht Ihren Code. Und wenn es nicht aufgerufen wird, liegt die Antwort fast immer in der Beschreibung — sie ist zu allgemein oder nennt nicht die Wörter, die Sie im Alltag verwenden.

Benutzerdefinierte Commands entwickeln

5:33 Der zweite Hebel sind eigene Kommandos. Und hier lohnt sich eine klare Unterscheidung, die im Gespräch oft durcheinandergeht: Kommandos sind für Menschen, Werkzeuge sind für Modelle. Ein Kommando wird registriert und danach von Ihnen per Schrägstrich aufgerufen. Es bekommt die Argumente als Text und einen Kontext mit Oberflächenfunktionen.

5:53 Der Unterschied zum Werkzeug ist die Aufrufrichtung: Das Werkzeug ruft das Modell, das Kommando rufen Sie. Der Vergleich: Der Werkzeugkasten ist für die Fachkraft, der Lichtschalter ist für Sie. Beides gehört in eine Werkstatt, aber es wäre merkwürdig, den Lichtschalter der Fachkraft in die Hand zu drücken. Kommandos eignen sich für menschliche Abläufe: Status anzeigen, etwas umschalten, aufräumen. Werkzeuge eignen sich für Fähigkeiten innerhalb einer Aufgabe.

6:21 Die Beschreibung eines Kommandos erscheint in der Kommandoliste — auch hier hilft Präzision. Und Kommandos können Dialoge zeigen und Zustände setzen, was für interaktive Abläufe praktisch ist. Eine Abgrenzung noch, die Ihnen Arbeit spart: Wenn Sie nur einen Textbaustein brauchen, nehmen Sie eine Prompt-Vorlage aus Modul neun. Dafür braucht es keine Erweiterung.

6:43 Worauf es hier ankommt: Ein Name, eine Beschreibung, eine Behandlungsfunktion, die Argumente und Kontext bekommt. Im Beispiel wird eine Meldung angezeigt, mit einem Rückfallwert, falls kein Argument übergeben wurde — dasselbe Muster wie bei den Vorlagenparametern. Der Aufwand ist minimal, und darin liegt die Versuchung. Die Fußnote sagt es deutlich: Für Textbausteine genügt eine Prompt-Vorlage.

7:08 Ein Kommando lohnt sich, wenn wirklich Logik dahinter steht — eine Abfrage, ein Umschalten, eine Prüfung.

Verhalten der Oberfläche beeinflussen

7:15 Jetzt zu den Rückmeldungen. Erweiterungen können Dialoge zeigen und Hinweise einblenden — und hier gilt mehr als sonst: Weniger ist mehr. Eine gesprächige Erweiterung nervt binnen einer Stunde. Über das Oberflächenobjekt stehen vier Dinge bereit: eine Ja-Nein-Rückfrage, eine Auswahl, eine Benachrichtigung und eine dauerhafte Statusanzeige für die Erweiterung.

7:38 Dazu kommt die Möglichkeit, Eingaben abzufangen oder umzuformen. Das ist ein mächtiges Instrument — und ein leicht missbrauchtes. Denken Sie an die Software, die bei jedem Start ein Hinweisfenster zeigt: Nach drei Tagen klicken Sie es weg, ohne es gelesen zu haben. Genau diesen Zustand wollen Sie bei Sicherheitsabfragen nicht erreichen.

7:58 Rückfragen gehören dorthin, wo eine echte Entscheidung nötig ist — nicht als Bestätigungsritual. Statusanzeigen zeigen sinnvoll, dass im Hintergrund etwas läuft. Der dritte Punkt ist der wichtigste: Zu viele Hinweise trainieren Wegklicken statt Aufmerksamkeit; Sie erzeugen damit genau die Scheinsicherheit, die Pi im Kern vermeiden wollte.

8:18 Und das Eingabe-Ereignis erlaubt, Prompts abzufangen oder umzuformen — ein starker Hebel, den Sie sichtbar machen sollten, wenn Sie ihn nutzen. Vier Fehler bei der Oberfläche. Bei jedem Werkzeugaufruf bestätigen lassen — dann liest es niemand mehr, und die Prüfung ist wertlos. Statusanzeigen setzen und nie zurücksetzen, sodass die Anzeige dauerhaft „arbeitet" behauptet.

8:40 Eingaben still verändern, ohne es sichtbar zu machen — damit unterlaufen Sie das Vertrauen in Ihr eigenes Werkzeug. Und Fehler nur als Benachrichtigung zeigen, statt sie zurückzumelden; dann verschwindet die Information, sobald der Hinweis weg ist. Alle vier sind Fragen des guten Geschmacks — und der wird hier zur Sicherheitsfrage.

Permission Checks integrieren

9:01 Jetzt das Kapitel, auf das wir seit Modul drei zusteuern: Ihre eigenen Hausregeln, technisch durchgesetzt. Das ist die Stelle, an der die bewusste Weglassung der Popups zu Ihrem Vorteil wird. Über das Werkzeugaufruf-Ereignis lässt sich ein Aufruf prüfen und blockieren: Eine Rückgabe mit Blockier-Kennzeichen und Begründung verhindert die Ausführung.

9:22 Damit bauen Sie genau die Nachfragen, die der Kern nicht mitbringt — aber nur für die Fälle, die Sie für relevant halten. Der Unterschied zum eingebauten Bestätigungsdialog ist entscheidend: Ihre Prüfung feuert selten und ist dann bedeutungsvoll. Eine Nachfrage, die einmal pro Woche kommt, liest man. Eine, die fünfzig Mal am Tag kommt, nicht.

9:43 Die Regeln greifen unabhängig davon, wer die Sitzung startet — das ist der Teamvorteil. Prüfungen sind Code, also versionierbar und reviewbar; Ihre Sicherheitsregeln durchlaufen denselben Qualitätsprozess wie Ihr Produktcode. Es gibt außerdem ein Ereignis für Werkzeugergebnisse, mit dem sich Ausgaben verändern lassen — mächtig, aber mit Bedacht zu nutzen.

10:05 Und der Satz zur Ehrlichkeit gehört dazu: Der Check läuft im selben Prozess. Er ersetzt keine Isolation, er ergänzt sie. Worauf es hier ankommt, ist die Prüflogik in der Mitte. Sie greifen den Befehl ab, vergleichen ihn mit einem Muster — hier zwei klassische Verdachtsfälle: das rekursive Löschen und das Ausführen eines heruntergeladenen Skripts — und fragen dann nach.

10:27 Bei Ablehnung blockiert die Rückgabe die Ausführung samt Begründung. Die Fußnote gibt den wichtigsten Praxishinweis: Muster eng fassen. Eine zu breite Regel blockiert Ihre eigene Arbeit, und dann schalten Sie die Erweiterung nach zwei Tagen wieder ab. In dieser Übung setzen Sie eine projektspezifische Sicherheitsregel als Hook um.

10:47 Das Erfolgskriterium ist zweiseitig und dadurch anspruchsvoll: Der definierte Fall wird nachweislich blockiert, und drei normale Arbeitsschritte laufen unbehindert durch. Genau diese Balance ist die Kunst — nicht das Blockieren selbst. Wer mag, nimmt die Stretch-Variante und macht die Begründung im Verlauf sichtbar. Dann sehen auch Kolleginnen und Kollegen, warum etwas nicht passiert ist, statt an einen Fehler zu glauben.

Projektwerkzeuge für den Agenten zugänglich machen

11:12 Jetzt eine Anwendung, die in gewachsenen Projekten viel bringt: Ihre eigenen Skripte als Werkzeuge verfügbar machen — mit enger Schnittstelle statt freier Shell. Generatoren, Deploy-Skripte, Datenmigrationen — all das lässt sich als Werkzeug kapseln: mit typisierten Parametern, klarer Beschreibung und definierter Rückgabe, statt es über freie Shell-Kommandos anzusprechen.

11:34 Der Vergleich: Sie geben nicht den Generalschlüssel heraus, sondern einen Schlüssel für genau diese Tür. Der Agent kann die Operation ausführen, aber nur in der Form, die Sie vorgesehen haben. Das ist gleichzeitig sicherer und zuverlässiger — zwei Ziele, die selten zusammenfallen. Die Schnittstelle wird eng: Nur erlaubte Werte sind möglich, alles andere lehnt das Schema ab.

11:57 Der Aufruf ist im Verlauf klar erkennbar, also nachvollziehbar — bei einem freien Shell-Aufruf müssten Sie die Kommandozeile lesen und interpretieren. Fehlerbehandlung passiert im Werkzeug statt im Prompt, wo sie ohnehin nicht verlässlich funktioniert. Und Sie können Ergebnisse aufbereiten und kürzen, bevor sie in den Kontext gehen. Das ist ein unterschätzter Vorteil: Sie kontrollieren, was Kontextbudget kostet.

12:21 Der rote Faden: Schnittstelle definieren, Werte begrenzen, Ausgabe kürzen, testen, einführen. Sie schreiben Skript und Parameter auf. Dann legen Sie die erlaubten Werte fest — und alles, was nicht ins Schema gehört, gehört nicht in die Schnittstelle. Dann registrieren Sie das Werkzeug. Die Ausgabe kürzen Sie auf das, was der Agent wirklich braucht. Und Sie testen erst mit der Startoption, bevor Sie projektlokal einführen.

12:48 Die Fußnote fasst den Gewinn zusammen: Gekapselte Werkzeuge sind sicherer als offene Shell-Aufrufe.

Extensions sicher konzipieren

12:54 Jetzt das Kapitel, das ich für unverzichtbar halte, wenn Sie selbst Erweiterungen schreiben. Denn ab hier sind Sie nicht mehr Anwender eines Risikos, sondern Verursacher. Erweiterungen laufen mit den Rechten des Pi-Prozesses und können beliebigen Code ausführen. Sicheres Design heißt deshalb vier Dinge: enge Zuständigkeit, keine Geheimnisse im Code, keine stillen Netzzugriffe, nachvollziehbares Verhalten.

13:18 Das ist derselbe Maßstab, den Sie an eine Bibliothek in Ihrem Produktcode anlegen würden — mit dem Unterschied, dass diese hier Ihre Entwicklungsumgebung bewohnt und Zugriff auf Ihre Zugänge hat. Der Maßstab darf also gern etwas strenger sein. Fremde Erweiterungen vor der Nutzung lesen — es ist nur TypeScript, und meist sind es unter hundert Zeilen.

13:39 Projektlokale Erweiterungen greifen erst nach Projektvertrauen, was Ihnen einen Moment zum Nachdenken verschafft. Zugangsdaten gehören in die Umgebung oder in die Auth-Datei, nie ins Modul — Sie erinnern sich an die Kommando-Variante für Schlüssel aus Modul zwei. Und der letzte Satz gilt auch intern: Wer viel darf, muss viel geprüft werden. Auch im eigenen Team.

14:01 Vier Fehler beim eigenen Entwurf. Eine Erweiterung mit Netzzugriff schreiben, ohne den Zweck zu dokumentieren — beim nächsten Review weiß niemand, ob das so sein soll. Werkzeugergebnisse still verändern und damit Prüfungen entwerten; das ist technisch möglich und deshalb besonders heikel. Eine Erweiterung global aktivieren, die nur ein Projekt braucht.

14:21 Und Fehler schlucken statt sie sichtbar zurückzugeben — dann arbeitet der Agent mit einer falschen Annahme weiter und niemand merkt, woher sie kam.

Pi mit Pi erweitern und konfigurieren

14:30 Zum Abschluss eine hübsche Volte: Erweiterungen, Skills und Vorlagen sind normale Dateien in Ihrem Projekt. Also genau die Art Arbeit, die Pi selbst erledigen kann. Der Agent kann sein eigenes Werkzeug ausbauen: Gerüst erzeugen, Ereignisse nachlesen, Werkzeug registrieren, testen, dokumentieren. Und er hat dabei einen Vorteil, den kein Fremdanbieter hat — er kennt das Projekt, in dem die Erweiterung wirken soll.

14:56 Der Vergleich: der Schreiner, der sich seine Vorrichtung selbst baut, weil er weiß, welche Werkstücke er ständig in der Hand hält. Ein schöner Moment im Seminar — und gleichzeitig einer, bei dem die Abnahmeregeln aus Modul vier besonders wichtig sind. Die Programmierschnittstelle ist online dokumentiert und damit zitierfähig — Sie können den Agenten auf die Doku-Seite verweisen, statt ihn raten zu lassen.

15:21 Der Neuladen-Befehl macht die Rückkopplung schnell: ändern, laden, prüfen. Der Agent kennt das Projekt, in dem die Erweiterung wirkt. Und der letzte Punkt ist der, den ich nicht weglassen will: Prüfen bleibt Ihre Aufgabe — auch bei Code, der Pi selbst betrifft. Gerade dort, denn dieser Code läuft mit vollen Rechten in jeder Sitzung.

15:41 Der rote Faden: Ziel, Gerüst, Test, Grenzfälle, Review. Sie halten Ziel und Auslöser in einem Satz fest — dieselbe Disziplin wie bei Skills. Dann lassen Sie das Gerüst nach Doku-Muster erzeugen. Mit der Test-Startoption laden Sie es und prüfen an einem echten Fall. Dann ergänzen Sie Grenzfälle: Fehler, Abbruch, leere Eingabe — genau die Fälle, die ein Modell gern optimistisch übergeht. Und am Ende steht Review und projektlokale Einführung.

16:10 Ab hier ist Pi Ihr Werkzeug — und Ihr Werkstück.

Der Kern bleibt klein, weil Sie erweitern

16:14 Drei Sätze zum Mitnehmen. Eine Erweiterung ist ein TypeScript-Modul mit Ereignissen, Werkzeugen und Kommandos — mehr Struktur brauchen Sie nicht. Berechtigungsprüfungen entstehen über das Werkzeugaufruf-Ereignis; das sind Ihre Hausregeln, technisch durchgesetzt und sparsam eingesetzt. Und volle Rechte bedeuten enge Zuständigkeit und lesbaren Code.

16:34 Im letzten inhaltlichen Modul geht es um etwas, das wir bisher nur gestreift haben: Sessions — und den Baum, der Pi von den meisten anderen Werkzeugen unterscheidet.