DEV Community

Cover image for Wie man über 300 KI-Spezialisten in Claude Code und Cursor installiert
Emre Demir
Emre Demir

Posted on Originally published at apidog.com

Wie man über 300 KI-Spezialisten in Claude Code und Cursor installiert

agency-agents: Was KI-Agenten-Personas leisten – und was nicht

Kurz gesagt: agency-agents ist die größte kuratierte Sammlung von KI-Agenten-Personas auf GitHub – mit 149.312 Sternen am 1. September 2026. Das Repository enthält mehr als 300 Agenten-Definitionsdateien in rund 20 Kategorien und installiert sie mit einem Befehl in Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Windsurf, Aider und viele weitere Tools. Es liefert jedoch ein Rahmenwerk, keine neuen Fähigkeiten: Personas verändern die Arbeitsweise eines Agenten, geben ihm aber keine unbekannten Fakten und bleiben nicht über Sitzungen hinweg erhalten.

Apidog heute ausprobieren

agency-agents

Dieser Artikel ist ein vertiefter Blick auf ein Tool aus unserer Zusammenfassung der fünf Open-Source-KI-Agenten-Tools, die 2026 eine Installation wert sind.

Ihr Codierungsagent ist standardmäßig ein hilfreicher Generalist. Bitten Sie ihn, einen Authentifizierungsablauf zu überprüfen, erhalten Sie oft vernünftige, aber vergessliche Ratschläge. Geben Sie dieselbe Aufgabe einem Sicherheitsprüfer mit Bedrohungsmodell und Checkliste, fallen die Ergebnisse deutlich strukturierter aus.

Diese Lücke füllt agency-agents. Das Projekt begann als Reddit-Thread über Agentenspezialisierung und wuchs zu einer Sammlung, deren vollständige Installation mindestens eine beliebte Agentenlaufzeit an ihre Grenzen bringt. Entscheidend ist, was tatsächlich installiert wird, wie Sie nur die benötigten Teile auswählen und welche Grenzen eine Persona-Bibliothek hat.

Was Sie tatsächlich installieren

Jeder Agent ist eine Markdown-Datei – kein einzeiliger System-Prompt und kein Plugin mit eigenem Code. Eine Datei beschreibt:

  • Identität und Persönlichkeit
  • Kernmission
  • Arbeitsprozess
  • technische Ergebnisse mit Beispielen
  • Erfolgskennzahlen

Am 1. September 2026 enthielt der Repository-Baum 312 Markdown-Dateien in 20 übergeordneten Kategorieordnern. Ohne examples/ bleiben 306 Dateien:

Abteilung Agenten-Dateien
engineering 59
specialized 58
marketing 36
game-development 21
integrations 18
strategy 16
gis 13
security 12
design 10
sales 9
testing 9
paid-media 7
project-management 7
academic 6
spatial-computing 6
support 6
finance 5
product 5
healthcare 3

Die README wirbt weiterhin mit „über 230 Agenten“ und ist damit veraltet.

Die Engineering-Abteilung ist für die meisten Entwickler der beste Einstieg. Die Rollen sind spezifischer, als man es von einer Prompt-Sammlung erwarten würde. Neben Frontend Developer und Backend Architect gibt es unter anderem:

  • einen Network Engineer für Cisco IOS-XE, Juniper Junos und Palo Alto PAN-OS
  • einen Embedded Firmware Engineer für ESP32-, STM32- und Nordic-Ziele
  • einen Incident Response Commander für Post-Mortems und Rufbereitschaft
  • einen Codebase Onboarding Engineer, der ein Repository schreibgeschützt erkundet und Fakten nennt, statt Änderungen vorzuschlagen

Gerade die schreibgeschützte Persona zeigt das Prinzip gut: Ein Agent mit explizitem Bearbeitungsverbot ist ein anderes Werkzeug als ein Standardagent – und kostet nur eine Datei.

Installation ohne die Umgebung zu überladen

Das Repository enthält Konvertierungs- und Installationsskripte. Der interaktive Installationsweg erkennt vorhandene Tools und fragt nach der gewünschten Auswahl:

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh
Enter fullscreen mode Exit fullscreen mode

In der Praxis ist es sinnvoller, ein bestimmtes Tool und nur einige Abteilungen zu installieren:

# alles in Claude Code
./scripts/install.sh --tool claude-code

# nur zwei Abteilungen
./scripts/install.sh --tool claude-code --division engineering,security

# nur benannte Agenten
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

# prüfen, was existiert, bevor man sich festlegt
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run
Enter fullscreen mode Exit fullscreen mode

Unterstützte Ziele sind unter anderem Claude Code, Cursor, Codex, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Aider, Kimi Code, Hermes, Antigravity, Osaurus und Mistral Vibe.

Zusätzlich gibt es eine native Desktop-App unter agencyagents.app für macOS, Linux und Windows. Sie durchsucht die Sammlung, installiert Agenten per Klick und aktualisiert sich automatisch. Ein Homebrew Cask ist ebenfalls verfügbar.

Agenten in agency-agents

Warum eine Auswahl wichtig ist

OpenCode registriert derzeit nur etwa 119 Agenten und verwirft den Rest stillschweigend. Das Repository dokumentiert dies als Workaround für einen Upstream-Bug. Mit --division bleiben Sie unter dem Limit; der Installer warnt, wenn eine Auswahl es überschreiten würde.

Stilles Abschneiden ist besonders problematisch: Der gewünschte Agent fehlt, ohne dass Sie es bemerken.

Auch ohne diesen Fehlerfall sind 300 Personas keine gute Standardeinstellung. Eine Liste, die Sie sich nicht merken können, wird kaum verwendet. Installieren Sie zunächst die ein oder zwei Abteilungen, die zu Ihrer täglichen Arbeit passen. Lesen Sie vier oder fünf Dateien vollständig und entfernen Sie Rollen, die nicht zu Ihrer tatsächlichen Arbeitsweise passen.

Was eine Persona ändert – und was nicht

Eine Persona legt fest:

  • wonach der Agent sucht
  • welches Format er erzeugt
  • wann er eine Aufgabe als erledigt betrachtet

Das ist wichtiger, als es klingt. Viele schlechte Agenten-Ergebnisse entstehen nicht, weil das Modell grundsätzlich falsch liegt, sondern weil es auf die falsche Form der Antwort optimiert.

Eine Persona kann jedoch keine Informationen liefern, die das Modell nicht besitzt. Diese Grenze zeigt sich besonders deutlich bei APIs.

Bitten Sie den Backend Architect, einen Client für Ihren internen Abrechnungsdienst zu schreiben. Er wird wahrscheinlich sauberen, idiomatischen Code für eine erfundene Antwortstruktur erzeugen. Er kann nicht wissen, dass Ihr Dienst bei einer wiederholten Idempotenzschlüssel-Anfrage einen 409-Fehler mit einem anderen Fehler-Envelope zurückgibt oder dass der Paginierungs-Cursor undurchsichtig statt ein Offset ist.

Die Persona organisiert den Code besser. Sie macht ihn nicht automatisch korrekt.

Dasselbe gilt für die Testabteilung. Eine QA-Persona schreibt gründliche Tests gegen ihr eigenes mentales Modell der API. Diese Tests können erfolgreich durchlaufen und trotzdem nichts über das reale Verhalten beweisen. Mehr dazu:

Die Spezifikation ist die Quelle der Wahrheit

Geben Sie dem Agenten den Vertrag, statt von der Persona eine Kompensation zu erwarten.

Wenn Ihre API in Apidog entworfen wurde, ist die OpenAPI-Spezifikation die Quelle der Wahrheit:

  • reale Schemata
  • reale Statuscodes
  • reale Fehler-Envelopes
  • erforderliche Header
  • Paginierungsregeln

Der Agent liest diese Informationen, statt sie aus Aufrufstellen zu rekonstruieren. Mocks können aus derselben Spezifikation generiert werden – einschließlich Fehlerzweigen, die eine Persona niemals zuverlässig erraten würde. Eine Testsuite kann in CI lautstark fehlschlagen, sobald Implementierung und Spezifikation auseinanderlaufen.

Das nützliche mentale Modell lautet:

Die Persona entscheidet, wie der Agent arbeitet.

Die Spezifikation entscheidet, was wahr ist.

Weiterführend:

Wenn Sie eine Live-Spezifikation in den Kontext Ihres Agenten einbinden möchten, laden Sie Apidog herunter und verweisen Sie es auf Ihr bestehendes Projekt.

Die zweite Grenze: Eine Persona ist kein Team

Die Sammlung vermittelt die Idee einer vollständigen Agentur. Praktisch aktivieren Sie eine Persona in einer Sitzung, erledigen eine Aufgabe und beginnen am nächsten Tag erneut. Es gibt keine persistente Aufgabenverteilung, keine Historie früherer Ergebnisse und keine Möglichkeit für Teammitglieder, die Arbeit zu verfolgen.

Neun Abteilungen beschreiben Rollen, die eigentlich nur innerhalb einer Organisation sinnvoll sind. Das Installationsskript selbst kennt jedoch keine Organisation.

Wenn die Idee über eine einzelne Terminalsitzung hinaus Bestand haben soll, fehlt eine Aufgabenmanagement-Ebene. Sharkly ist genau dafür ausgelegt:

  • Ein Agent ist eine gespeicherte Konfiguration, kein Prompt, den Sie jedes Mal neu eingeben. Sie enthält Anweisungen, Laufzeitumgebung, Fähigkeiten, Repositories und Umgebung.
  • Eine Crew besteht aus einem führenden Agenten sowie weiteren Agenten und Personen. Der Anführer liest den Aufgabenkontext, entscheidet, wen er einbezieht, und führt die Ergebnisse an einem Ort zusammen.
  • Arbeit wird zugewiesen, nicht nur aufgerufen. Aufgaben existieren in einem Bereich, Projekt und Sprint und können mit Jira synchronisiert werden.
  • Die Ausführung erfolgt auf Ihrer Infrastruktur: Laptop, Server oder Container. Ihre vorhandenen Claude-Code- oder Codex-Abonnements erledigen die Arbeit.
  • Fortschritt, Tool-Aufrufe und Ergebnisse werden zur Aufgabe gestreamt. Agentenausgaben erscheinen als Kommentare, auf die Sie antworten können. Eine Aufgabe im Backlog startet keinen Lauf automatisch.

Kurz gesagt: agency-agents liefert die Stellenbeschreibungen; Sharkly bietet den Ort, an dem diese Rollen Aufgaben übernehmen, ausgeführt und überprüft werden. Nutzen Sie das Repository als Bibliothek von Rollendefinitionen, um persistente Agenten zu initialisieren.

Agenten-Workflow

Eigene Personas schreiben

Das Beständigste, was agency-agents bietet, ist ein gutes Format. Nach dem Lesen einiger Dateien dauert es ungefähr 15 Minuten, eine Persona für den eigenen Stack zu schreiben. Eine hausspezifische Persona ist fast immer wertvoller als eine generische.

Die stärksten Dateien folgen meist dieser Struktur:

  • Identität und Stimme: Wer ist der Agent und wie kommuniziert er? Das verhindert, dass er bei langen Aufgaben in den generischen Assistentenmodus zurückfällt.
  • Kernmission: Ein Satz darüber, was Erfolg bedeutet. Der Codebase Onboarding Engineer soll beispielsweise schreibgeschützt erkunden, Codepfade verfolgen und Fakten nennen – nichts vorschlagen.
  • Arbeitsprozess: Geordnete, überprüfbare Schritte. Eine Persona mit einem siebenstufigen Prüfprozess liefert konsistentere Ergebnisse als eine ohne Prozessvorgaben.
  • Lieferobjekte: Konkrete Artefakte mit Format. Schreiben Sie „eine Markdown-Tabelle mit Schweregrad, Dateipfad und Zeilennummer“ statt nur „einen Bericht“.
  • Erfolgskennzahlen: Woran erkennt der Agent, dass er fertig ist?

Eine hausinterne Persona für API-Arbeiten könnte so aussehen:

# API-Vertragsprüfer

## Mission
Verifizieren, dass neue oder geänderte Endpunkte der OpenAPI-Spezifikation in diesem
Repository entsprechen, bevor sie zur Überprüfung gelangen. Melden Sie Abweichungen.
Bearbeiten Sie keinen Code.

## Prozess
1. Lesen Sie die Spezifikation für jeden Endpunkt, der vom aktuellen Diff betroffen ist.
2. Vergleichen Sie für jeden den Handler mit der Spezifikation: Statuscodes,
   Antwortschema, Fehler-Envelope, erforderliche Header, Paginierungsstil.
3. Führen Sie die Vertragstests aus. Protokollieren Sie Fehler wortgetreu.
4. Überprüfen Sie, ob neue Endpunkte zur Spezifikation hinzugefügt wurden, nicht nur zum Router.
5. Kennzeichnen Sie jedes Antwortfeld, das im Code vorhanden, aber in der Spezifikation fehlt.

## Lieferobjekte
Eine Tabelle: Endpunkt, Methode, Abweichungstyp, Spezifikationszeile, Codezeile, Schweregrad.
Keine Prosa-Zusammenfassung. Keine vorgeschlagenen Korrekturen, es sei denn, Sie werden dazu aufgefordert.

## Erledigt, wenn
Jeder Endpunkt im Diff erscheint in der Tabelle mit einem Urteil, und die
Ausgabe des Vertragstests wird als Beweis mitgeliefert.
Enter fullscreen mode Exit fullscreen mode

Diese kurze Datei ist für ein Backend-Team nützlicher als eine generische Engineering-Persona, weil sie die eigene Spezifikation, die eigenen Tests und die Definition von „erledigt“ benennt. Besonders wichtig ist die Anweisung, Beweise statt Meinungen zu liefern.

Das Muster funktioniert ebenso für Incident Response, Migrationen, Abhängigkeits-Upgrades und Onboarding. Übernehmen Sie die Struktur, bewahren Sie die Prozessdisziplin und ersetzen Sie den generischen Inhalt durch Ihre Konventionen. Wenn die Ausgabe an einen Menschen oder einen anderen Agenten übergeben werden muss, ist ein klarer Formatvertrag entscheidend. Siehe auch Agentenübergabe und Kontextweitergabe.

Sind 149.312 Sterne aussagekräftig?

149.312 Sterne sind bemerkenswert, sollten aber nicht mit tatsächlicher Nutzung verwechselt werden. Persona-Repositories sammeln Sterne schnell, weil sie leicht verständlich, einfach zu teilen und kostenlos auszuprobieren sind. Ein Stern bedeutet, dass jemand die Idee gut fand – nicht, dass diese Person das Repository noch verwendet.

Glaubwürdig wird das Projekt eher durch seine Arbeit als durch die Sternzahl:

  • echte Beitragsgeschichte seit Oktober 2025
  • MIT-Lizenz
  • dokumentierte Grenzen, einschließlich der OpenCode-Obergrenze
  • Agentendateien mit konkreten Domäneninhalten statt generischem Rollen-Fluff

Öffnen Sie drei Dateien in einer Abteilung, die Sie gut kennen. Wenn die Frontend-Developer-Datei Dinge beschreibt, die ein guter Frontend Developer tatsächlich sagen würde, ist das ein gutes Zeichen. Wenn sie nur wie eine Stellenanzeige klingt, können Sie das Repository überspringen.

So ziehen Sie praktischen Nutzen daraus

Ein bewährter Ablauf:

  1. Eine Abteilung installieren: Für die meisten Leser ist engineering der beste Anfang.
  2. Die Dateien lesen: Lesen Sie vier oder fünf Dateien vollständig und achten Sie auf die Prozessabschnitte.
  3. Die Personas anpassen: Ergänzen Sie Ihren Stack, Ihre Konventionen und Ihre Definition von „erledigt“.
  4. Echte Eingaben verwenden: Ein Sicherheitsprüfer mit Ihrer OpenAPI-Spezifikation findet Vertragsprobleme. Ohne Spezifikation erstellt er vor allem eine Checkliste.
  5. Bewährte Personas persistieren: Eine Persona, die Sie zweimal pro Woche verwenden, sollte zu einem gespeicherten Agenten in einem Aufgabenmanagementsystem werden – nicht nur zu einer Datei, die zwischen Rechnern kopiert wird.

Dieser letzte Schritt entscheidet oft darüber, ob Teams die Methode skalieren oder stillschweigend aufgeben.

FAQ

Funktioniert agency-agents mit Cursor und Codex oder nur mit Claude Code?

Mit allen genannten Tools. convert.sh erzeugt Integrationsdateien pro Tool, während install.sh --tool auf ein bestimmtes Ziel ausgerichtet ist. Unterstützt werden unter anderem Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Copilot, Windsurf, Aider und Kimi Code.

Wenn Sie Agenten-Clients für API-Arbeiten vergleichen, lesen Sie unseren Blick auf API-Clients in Cursor und Copilot.

Sollte ich alle 300 Agenten installieren?

Nein. OpenCode registriert nur etwa 119 Agenten und verwirft den Rest stillschweigend. Bei anderen Tools ist die vollständige Installation zwar technisch möglich, aber die meisten Rollen werden Sie nie verwenden. Installieren Sie nach Abteilung.

Machen Personas den Agenten intelligenter?

Sie machen ihn besser ausgerichtet. Die faktische Genauigkeit – etwa beim Verhalten Ihrer API – steigt dadurch nicht automatisch. Dafür brauchen Sie eine echte Spezifikation. Die Hintergründe finden Sie in Braucht man im Zeitalter der KI-Agenten noch ein API-Tool?.

Ist es sicher, das Installationsskript auszuführen?

Das Skript schreibt Agenten-Definitionsdateien in die Konfigurationsverzeichnisse Ihres Tools. Das ist sein Zweck. Das Projekt ist MIT-lizenziert und vollständig einsehbar. Mit --dry-run sehen Sie vorab, welche Änderungen vorgenommen würden. Führen Sie diesen Modus zuerst aus. Weitere Hinweise finden Sie unter KI-Agenten-Schutzmaßnahmen.

Was ist der Unterschied zu einem Agenten-Framework?

agency-agents liefert Markdown-Dateien, die das Verhalten eines bestehenden Agenten verändern. Wenn mehrere Personas gleichzeitig ausgeführt werden sollen, ist Orca näher an diesem Ziel. Frameworks wie Strands oder AgentKit bieten Laufzeit-Orchestrierung im Code. agency-agents liefert die Rollendefinitionen. Das sind unterschiedliche Ebenen.

Zusammenfassung

agency-agents setzt eine einfache Idee gut um: Ein Agent arbeitet besser, wenn er weiß, welche Rolle er spielt. Installieren Sie eine passende Abteilung, lesen und bearbeiten Sie die Dateien und investieren Sie etwa 20 Minuten in die Anpassung an Ihr Team.

Seien Sie zugleich ehrlich über die zwei Dinge, die das Repository nicht löst:

  1. Personas kennen Ihre API nicht. Dafür benötigen Sie eine reale Quelle der Wahrheit wie eine OpenAPI-Spezifikation in Apidog.
  2. Personas bilden kein persistentes Team. Dafür brauchen Sie Aufgabenmanagement und gemeinsame Nachvollziehbarkeit wie bei Sharkly.

Eine Persona-Bibliothek ist ein guter Anfang. Sie ist weder eine Organisation noch eine Quelle der Wahrheit.

Top comments (0)