Packages & Erweiterungen

Pi Packages und zusätzliche Fähigkeiten

0:00 Wir haben im ersten Modul gehört, dass Pi bewusst viel weglässt. Jetzt kommt die andere Seite dieser Medaille: Wie rüsten Sie nach, was Ihnen fehlt? Die Antwort heißt Packages — Bündel aus Erweiterungen, Skills, Prompt-Vorlagen und Farbschemata, verteilt über npm oder Git. Der Leitsatz dieses Moduls lautet: Was Pi weglässt, installieren Sie bewusst — oder eben gar nicht. Denn jedes Package ist Code, der mit den Rechten Ihres Kontos läuft.

0:27 Wir schauen uns deshalb nicht nur an, wie man installiert, sondern vor allem, wie man auswählt.

Fähigkeiten nachrüsten

0:34 Acht Kapitel, und der wichtigste Satz steht schon in der Sprechnotiz zur Agenda: Jedes Package ist Code mit den Rechten Ihres Kontos. Behalten Sie das im Kopf, wenn wir über Webzugriff, Guardrails und Unter-Agenten sprechen. Wir beginnen beim Konzept, gehen dann durch die drei typischen Nachrüstungen und enden mit einem Bewertungsraster und einem eigenen Werkzeugkasten.

0:54 Sie werden merken, dass ich mich mit konkreten Paketempfehlungen zurückhalte — die Auswahl ändert sich schnell, die Kriterien bleiben. Vier Punkte. Erstens die vier Erweiterungsarten und was sie unterscheidet — das ist die Landkarte für alles Weitere. Zweitens die Verwaltung: installieren, auflisten, entfernen, aktualisieren; überraschend wichtig ist dabei der Unterschied zwischen global und projektlokal.

1:19 Drittens die drei klassischen Nachrüstungen, die in jedem Team früher oder später auf dem Tisch liegen. Und viertens die Auswahl selbst — nach Nutzen, nach Rechten und nach Pflegeaufwand. Der Pflegeaufwand ist der Punkt, der am häufigsten unterschätzt wird.

Das Erweiterungskonzept von Pi verstehen

1:35 Fangen wir mit der Landkarte an. Vier Arten von Bausteinen, ein gemeinsamer Verteilweg — und wenn Sie die Unterschiede kennen, wissen Sie bei jedem Bedarf sofort, welche Art Sie eigentlich brauchen. Die Dokumentation sagt es knapp: Packages bündeln Erweiterungen, Skills, Prompt-Vorlagen und Themes, damit man sie über npm oder Git teilen kann.

1:55 Ein Package deklariert seine Inhalte in der Paketdatei — oder Pi erkennt sie automatisch anhand der Ordnernamen. Der Vergleich: eine Werkzeugkiste mit vier Fächern. Im ersten liegen Werkzeuge, im zweiten Arbeitsanleitungen, im dritten Textvorlagen, im vierten die Farbe des Griffs. Nur das erste Fach enthält ausführbaren Code — und genau daran hängt die Risikofrage.

2:19 Erweiterungen bringen Werkzeuge, Kommandos und Prüfungen — sie sind TypeScript und damit die mächtigste, aber auch die risikoreichste Art. Skills bringen Arbeitsanleitungen, die der Agent bei Bedarf lädt; das ist Text, kein Code. Prompt-Vorlagen sind ebenfalls reiner Text und praktisch risikofrei. Und Themes betreffen nur das Aussehen.

2:38 Diese Abstufung ist im Alltag nützlich: Wenn jemand im Team ein Package vorschlägt, ist die erste Frage nicht „was kann es", sondern „welche der vier Arten steckt darin". Worauf es hier ankommt, sind zwei Dinge. Erstens das Schlüsselwort in den Stichwörtern — damit wird ein Paket in der öffentlichen Übersicht sichtbar; das ist gleichzeitig Ihr Suchbegriff, wenn Sie nach Erweiterungen stöbern.

3:02 Zweitens der Deklarationsblock mit vier Einträgen, die genau den vier Arten entsprechen. Wer sich an die Ordnerkonvention hält, kann den Block auch weglassen. Für Sie als Anwender ist vor allem interessant: An dieser Stelle steht schwarz auf weiß, was ein Paket mitbringt. Ein Blick dorthin ersetzt viel Rätselraten.

Sinnvolle Packages auswählen

3:21 Jetzt zur Auswahl. Und ich behaupte: Die vier Fragen aus diesem Kapitel sind wichtiger als jede Paketliste, die ich Ihnen zeigen könnte — weil Listen veralten und Kriterien nicht. Auswahl heißt vier Prüfungen: Welche Fähigkeit fehlt wirklich? Welche Rechte braucht das Paket? Wer pflegt es? Und wie bekomme ich es wieder heraus?

3:41 Installiert wird aus npm, aus einem Git-Repository oder von einem lokalen Pfad. Die vier Fragen sind dieselben, die Sie bei jeder Abhängigkeit stellen sollten — nur mit einem Unterschied: Diese Abhängigkeit läuft nicht in Ihrer Anwendung, sondern in Ihrem Entwicklungswerkzeug, mit Ihren Rechten und Ihren Zugängen. Jede Erweiterung läuft mit den Rechten des Pi-Prozesses — der Satz aus Modul drei gilt hier unverändert. Ungepflegte Pakete werden damit zum Risiko und nicht nur zum Ballast.

4:11 Praktisch angenehm: Sie können projektlokal installieren, dann bleibt die Wirkung auf ein Projekt beschränkt — meine Empfehlung für alles, was Sie ausprobieren. Und es gibt einen Auflistungsbefehl, der jederzeit zeigt, was tatsächlich aktiv ist. Diesen Befehl sollten Sie sich merken; er ist die einzige verlässliche Antwort auf die Frage „was habe ich eigentlich installiert".

4:33 Worauf es hier ankommt, ist der komplette Lebenszyklus in sechs Zeilen: installieren aus drei Quellen, auflisten, entfernen, aktualisieren. Achten Sie auf die dritte Zeile mit der Option für projektlokale Installation — sie ist der Unterschied zwischen „ich probiere das im Projekt" und „ich ändere mein Werkzeug überall".

4:52 Und beachten Sie die Fußnote: Ohne diese Option landet die Änderung in Ihren Benutzereinstellungen. Das ist eine dieser Kleinigkeiten, die man einmal falsch macht und danach nie wieder. Diese Übung hat ein ungewöhnliches Erfolgskriterium: Mindestens eine Ihrer beiden Entscheidungen muss „nicht installieren" lauten. Das ist kein Trick, sondern eine Haltungsschulung. Die Verlockung bei Erweiterungen ist immer dieselbe — es könnte nützlich sein.

5:18 Und aus „könnte nützlich sein" wird über Monate ein Werkzeugkasten, den niemand mehr überblickt. Wer eine begründete Ablehnung formulieren kann, trifft auch bessere Zusagen. Nehmen Sie zwei Pakete, die Sie wirklich interessieren, und arbeiten Sie die vier Fragen durch.

Webzugriffe ergänzen

5:35 Jetzt die erste der drei typischen Nachrüstungen. Vielen fällt erst im Betrieb auf, dass der Agent gar nicht ins Netz kann — und das ist Absicht, keine Lücke. Der Kern gibt dem Modell Datei- und Shell-Werkzeuge, aber keine Web-Recherche. Diese Fähigkeit kommt als Package. In der öffentlichen Übersicht finden sich zum Beispiel eine Erweiterung mit Suche und Seitenabruf über wählbare Anbieter wie Brave, Tavily oder Exa — und eine, die zusätzlich GitHub-Repositories und YouTube-Transkripte erschließt.

6:05 Wichtig zur Einordnung: Diese Beispiele stammen aus der Paketübersicht, nicht aus der offiziellen Dokumentation; die Auswahl ändert sich, das Prinzip bleibt. Warum überhaupt Netzzugriff? Weil aktuelle Dokumentation und Fehlermeldungen außerhalb Ihres Repositories liegen — und weil der Wissensstand eines Modells sonst die harte Grenze bleibt.

6:26 Aber jetzt die Kehrseite, und sie ist wichtig: Fremde Inhalte sind Eingaben. Eine abgerufene Webseite kann Anweisungen enthalten, die für Ihren Agenten gedacht sind. Und der pragmatische vierte Punkt: Oft genügt ein einzelner Abruf über die Shell, den Sie selbst anstoßen — dann haben Sie den Netzzugriff, ohne ihn dauerhaft zu öffnen.

6:46 Vier Fehler rund um den Webzugriff. Recherchierte Aussagen ohne Quelle in den Code übernehmen — genau der Fehler, den wir in Modul eins besprochen haben, nur mit einer zusätzlichen Fehlerquelle. Web-Werkzeuge in unbeaufsichtigten Läufen offen lassen, wo niemand die abgerufenen Inhalte sieht. Die Schlüssel der Suchdienste ins Projekt-Repository schreiben — dieselbe Hygieneregel wie bei den Modell-Zugängen.

7:10 Und der letzte: Netzzugriff aktivieren, obwohl die Aufgabe ihn nicht braucht. Fähigkeiten, die nur „für den Fall" da sind, sind die teuersten.

Guardrails für Agenten einsetzen

7:19 Zweite Nachrüstung, und aus meiner Sicht die interessanteste: Prüfungen, die vor dem Werkzeugaufruf greifen. Hier holen Sie sich genau die Nachfragen zurück, die der Kern absichtlich nicht mitbringt. Guardrails sind Erweiterungen, die Werkzeugaufrufe prüfen, bevor sie laufen. Sie hängen sich an das Werkzeugaufruf-Ereignis und können blockieren: Zugriffe auf Geheimnisse, Schreibzugriffe auf geschützte Pfade, gefährliche Shell-Kommandos.

7:45 In der npm-Registry gibt es dafür fertige Pakete. Der Vergleich: ein Sicherheitsposten am Eingang, der die Liste kennt — er ersetzt nicht das Schloss an der Tür, aber er sieht jeden, der hineinwill. Und weil er als Code vorliegt, können Sie seine Liste selbst schreiben. Der Kern hat bewusst keine Berechtigungs-Popups — hier setzen Sie sie ein, aber gezielt und für Ihre Fälle.

8:09 Die Regeln greifen unabhängig davon, wer die Sitzung startet, was im Team viel wert ist. Und weil Prüfungen Code sind, laufen sie durch Ihr Review wie jede andere Regel. Ein Satz zur Ehrlichkeit gehört dazu: Für echte Isolation bleibt der Container unverzichtbar. Ein Guardrail läuft im selben Prozess — es ist eine Hausregel, keine Mauer.

8:29 Beides zusammen ergibt ein brauchbares Schutzniveau. Das Prinzip dieser Tabelle ist Staffelung — jede Ebene hat eine Wirkung und eine Grenze. Die Werkzeugliste nimmt Fähigkeiten ganz weg, lässt aber die erlaubten frei. Das Guardrail prüft jeden Aufruf, läuft aber im selben Prozess und ist damit grundsätzlich beeinflussbar.

8:49 Der Container sperrt den Prozess ein, lässt aber die eingebundenen Pfade offen. Lesen Sie die rechte Spalte als Erinnerung: Jede Ebene allein ist umgehbar. Erst die Kombination ergibt Schutz — und das ist derselbe Gedanke wie „Defense in Depth" in der klassischen Sicherheitsarchitektur.

Subagents in komplexeren Aufgaben nutzen

9:07 Dritte Nachrüstung: Unter-Agenten. Sie sind das prominenteste Beispiel für die Weglassungen im Kern — und ich möchte, dass Sie vorher eine Frage stellen: Reicht nicht einfaches Zerlegen? Unter-Agenten gehören zu den Funktionen, die das Projekt ausdrücklich nicht einbaut. Wer sie braucht, installiert ein Paket aus der Übersicht — dort finden sich Subagent-Kerne, die eigene Agenten samt Programmierschnittstelle und Lebenszyklus-Ereignissen bereitstellen.

9:34 Das Bild dazu: Sie stellen für ein Projekt Zeitarbeitskräfte ein. Das kann Sinn haben, wenn die Teilaufgaben unabhängig sind. Aber jede zusätzliche Kraft braucht Einweisung, produziert Ergebnisse und will koordiniert werden — und dieser Aufwand entfällt nicht, nur weil die Kräfte Software sind. Sinnvoll sind Unter-Agenten, wo Teilaufgaben wirklich unabhängig und gut abgrenzbar sind — Recherche in mehrere Richtungen zum Beispiel.

10:00 Aber jeder Unter-Agent kostet eigene Tokens und eigene Aufmerksamkeit. In den meisten Fällen reicht die schrittweise Zerlegung aus Modul fünf, und sie ist billiger. Und der Satz, den ich für den wichtigsten halte: Mehr Automatik heißt mehr Ergebnisse, die niemand gelesen hat. Wer die Abnahme aus Modul vier ernst nimmt, wird bei Parallelisierung von selbst vorsichtig.

10:22 In dieser Übung entscheiden Sie bewusst. Sie zerlegen eine Aufgabe in Teilaufgaben, markieren die Abhängigkeiten — und begründen dann, ob echte Parallelität nötig ist. Der Erkenntnisgewinn liegt meist beim Markieren: Sobald man Abhängigkeiten aufzeichnet, schrumpft der wirklich parallelisierbare Anteil erheblich. Wenn Sie danach zum Ergebnis kommen, dass Sie Unter-Agenten brauchen, haben Sie eine gute Begründung. Und wenn nicht, haben Sie sich Installation, Pflege und Token gespart.

10:50 Beides ist ein legitimes Ergebnis.

Erweiterungen kontrolliert in Workflows integrieren

10:53 Angenommen, Sie haben sich für eine Erweiterung entschieden. Dann stellt sich die Frage, wie sie in Ihren Alltag kommt — und da gibt es eine Reihenfolge, die sich bewährt hat. Kontrollierte Integration heißt: erst zum Testen laden, dann projektlokal einführen, und erst bei bewährtem Nutzen global aktivieren — mit einem Eintrag im Projekt, damit das Team dieselbe Umgebung hat.

11:15 Der Vergleich: Sie führen ein neues Werkzeug erst an einem Werkstück ein, dann in einer Werkstatt, dann im ganzen Betrieb. Das ist langsamer als sofort global — und Sie merken Probleme, solange sie noch klein sind. Behandeln Sie eine Erweiterung wie eine Abhängigkeit, nicht wie eine Einstellung. Es gibt eine Startoption, die eine Erweiterung nur für den Test lädt, ohne Dauerwirkung — genau das richtige Werkzeug für den ersten Kontakt.

11:41 Ein Neuladen-Befehl lädt Erweiterungen ohne Sitzungsverlust neu, was die Entwicklungsschleife angenehm kurz macht. Projektlokale Erweiterungen greifen erst nach vergebenem Projektvertrauen; der Mechanismus aus Modul drei arbeitet hier für Sie. Und der letzte Punkt als Warnung: Wer global installiert, ändert das Verhalten in allen Projekten — auch in denen, an die er gerade nicht denkt.

12:03 Der rote Faden: Bedarf, Test, Prüfung, Messung, Entscheidung. Zuerst benennen Sie den Bedarf konkret — „welche Fähigkeit fehlt" ist eine härtere Frage als „was könnte helfen". Dann probieren Sie den Kandidaten testweise oder projektlokal aus. Der dritte Schritt wird gern übersprungen: Rechte und Werkzeugaufrufe der Erweiterung sichten.

12:25 Es ist TypeScript, Sie können es lesen. Dann messen Sie den Nutzen an einer echten Aufgabe. Und am Ende steht eine echte Entscheidung, die auch „entfernen" lauten darf.

Nutzen und Risiken zusätzlicher Agentenfähigkeiten bewerten

12:36 Jetzt fassen wir die Bewertung in ein Raster. Und der Satz, der über diesem Kapitel steht, gilt für jede Software, aber hier besonders: Jede Fähigkeit ist auch eine Angriffsfläche. Jede zusätzliche Fähigkeit erweitert, was der Agent tun kann — und damit auch, was schiefgehen kann. Erweiterungen laufen mit den Rechten des Prozesses und können beliebigen Code ausführen.

12:58 Das ist keine Warnung gegen Erweiterungen, sondern die Grundlage einer nüchternen Abwägung: Nutzen ist konkret und messbar, Risiko ist strukturell und dauerhaft. Beides gegeneinander zu stellen ist genau die Ingenieursentscheidung, die man von einem Team erwarten darf — und die man regelmäßig wiederholen sollte, nicht nur einmal.

13:17 Nutzen können Sie messen: gesparte Schritte, gelöste Aufgaben, weniger manuelle Arbeit. Risiko ist strukturell: Rechte, Netzzugriff, fremder Code, Pflegezustand. Weniger Erweiterungen bedeuten schlicht weniger Überraschungen — und Überraschungen sind in Entwicklungswerkzeugen selten angenehm. Und der vierte Punkt ist der pragmatische: Was nur selten hilft, kann man auch manuell erledigen.

13:41 Eine Erweiterung, die dreimal im Jahr Zeit spart, kostet mehr Aufmerksamkeit als sie einbringt. Die Logik dieser Tabelle steckt in der rechten Spalte: Warnsignale. Beim Bedarf ist es der Satz „könnte nützlich sein". Bei den Rechten ist es die Kombination aus Netzzugriff, Shell und Schreibrecht — die Summe ist mehr als die Teile.

14:01 Bei der Pflege ist es eine unklare Änderungshistorie; bei einem Werkzeug mit vollen Rechten würde ich das als Ausschlusskriterium behandeln. Und beim Rückbau ist es Handarbeit. Wenn Sie eine Erweiterung nicht mit einem Befehl entfernen können, haben Sie sich langfristig gebunden.

Einen eigenen Werkzeugkasten für typische Projekte zusammenstellen

14:18 Zum Abschluss machen wir aus Einzelentscheidungen ein System. Zwei Werkzeugkästen genügen den meisten Teams — und der wichtigste Teil daran ist die Dokumentation der Auswahl. Ein Werkzeugkasten ist eine bewusst kleine, dokumentierte Auswahl je Projekttyp: global das Persönliche, projektlokal das Fachliche, jeweils mit einer Zeile Begründung im Projekt.

14:39 Der Vergleich: die Tasche eines Handwerkers, der weiß, welche Aufträge er annimmt. Sie enthält nicht alles, was es gibt, sondern das, was zu seiner Arbeit passt — und sie ist leicht genug, dass er sie mitnimmt. Die Zeile Begründung ist übrigens kein Papierkram: Sie ist die einzige Chance, in sechs Monaten noch zu wissen, warum etwas installiert ist.

15:00 Gleiche Projekte verdienen gleiche Ausstattung — das reduziert Reibung, wenn Menschen zwischen Projekten wechseln. Eine dokumentierte Auswahl lässt sich im Team diskutieren; eine gewachsene nicht, weil niemand ihren Stand kennt. Neue Projekte starten schneller mit erprobter Basis. Und ein Punkt, der leicht übersehen wird: Was fehlt, fällt erst auf, wenn die Basis benannt ist.

15:22 Solange jeder etwas anderes installiert hat, hält man Lücken für persönliche Konfigurationsprobleme. Der rote Faden: von den Aufgaben zur Ausstattung, nicht umgekehrt. Sie benennen Projekttypen — Web-Anwendung, Bibliothek, fremdes Projekt. Je Typ notieren Sie die drei häufigsten Aufgaben. Und erst dann suchen Sie Erweiterungen, und zwar nur dafür: Bedarf vor Angebot. Die Auswahl wandert mit Begründung ins Projekt.

15:50 Und der fünfte Schritt ist der, der aufräumt: nach einem Monat prüfen, was nie genutzt wurde. Diese Erweiterungen entfernen Sie — nicht dulden, entfernen. Sonst haben Sie in einem Jahr wieder das Sammelsurium.

Nachrüsten mit Maß

16:04 Drei Sätze zum Mitnehmen. Packages bündeln Erweiterungen, Skills, Prompt-Vorlagen und Themes — und nur die erste Art enthält ausführbaren Code. Webzugriff, Guardrails und Unter-Agenten sind Nachrüstungen, keine Voreinstellungen; das bedeutet, dass Sie sie bewusst wählen. Und jede Fähigkeit kostet Rechte, Pflege und Aufmerksamkeit.

16:24 Im nächsten Modul gehen wir eine Stufe tiefer — statt fremde Pakete zu installieren, schreiben wir eigene Skills: Arbeitsanleitungen, die Ihr Projektwissen wiederverwendbar machen.