knowledge-work-plugins: elf Rollenpakete für Claude Cowork und Claude Code
Open-Source-Repository mit Plugins, die in erster Linie für Wissensarbeiter zur Verwendung in Claude Cowork gedacht sind.
Auf einen Blick
- Was ist das?
- Anthropics Repository anthropics/knowledge-work-plugins liefert elf dateibasierte Plugins, die Claude über Skills, Slash-Befehle und MCP-Konnektoren auf eine Jobfunktion zuschneiden.
- Für wen ist es gedacht?
- Geeignet ist das Repository für Teams, deren Werkzeuglandschaft bereits zu den aufgeführten Konnektoren passt und die wiederkehrende Abläufe einmal beschreiben wollen, statt sie in jedem Prompt zu wiederholen. Weniger geeignet ist es für Unternehmen mit stark individueller Infrastruktur, denn dann beginnt die Arbeit an .mcp.json ohnehin von vorn.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Warum anthropics/knowledge-work-plugins elf Rollenpakete bündelt
Cowork funktioniert laut README so, dass Nutzer ein Ziel setzen und Claude fertige Arbeitsergebnisse liefert. knowledge-work-plugins legt darüber eine Beschreibungsschicht. Statt dem Modell in jeder Sitzung erneut zu erklären, welche Werkzeuge das Unternehmen nutzt und wie ein Vorgang abläuft, steht diese Beschreibung als Datei im Repository. Der Nutzen liegt damit in Wiederholbarkeit, nicht in einer neuen Modellfähigkeit.
Jedes der elf Pakete bündelt laut README vier Bestandteile: Skills für Domänenwissen, Slash-Befehle für explizit ausgelöste Abläufe, Konnektoren zu externen Werkzeugen über MCP-Server sowie Sub-Agenten. Das Repository ist in der GitHub-Metadaten als Python eingeordnet, besteht inhaltlich nach README-Angabe aber ausschließlich aus Markdown und JSON, ohne Code und ohne Build-Schritt.
Zum Zeitpunkt der Materialsammlung weist GitHub 23.719 Sterne, 2.863 Forks und 101 offene Issues aus. Standard-Branch ist main, das Projekt ist nicht archiviert. Über Stabilität, Latenz oder Trefferqualität macht das README keine Angaben.
Die Marketplace-Tabelle von productivity bis cowork-plugin-management
Die README-Tabelle ordnet jedem Plugin eine Aufgabe und eine Liste von Konnektoren zu. productivity verwaltet Aufgaben, Kalender, tägliche Abläufe und persönlichen Kontext, angebunden an Slack, Notion, Asana, Linear, Jira, Monday, ClickUp und Microsoft 365. sales recherchiert Interessenten, bereitet Anrufe vor, prüft die Pipeline und baut Wettbewerbs-Battlecards, mit HubSpot, Close, Clay, ZoomInfo und Fireflies.
customer-support triagiert Tickets, entwirft Antworten, verpackt Eskalationen und überführt gelöste Fälle in Wissensdatenbank-Artikel. product-management schreibt Spezifikationen, plant Roadmaps und verdichtet Nutzerforschung. marketing plant Kampagnen und setzt Markenstimme durch, mit Canva, Ahrefs, SimilarWeb und Klaviyo. legal prüft Verträge und sortiert NDAs vor. finance bereitet Journaleinträge vor, gleicht Konten ab und begleitet Abschluss sowie Audit.
data schreibt SQL, rechnet Statistik, baut Dashboards und validiert Ergebnisse vor der Weitergabe, angebunden an Snowflake, Databricks, BigQuery, Definite und Hex. enterprise-search fragt E-Mail, Chat, Dokumente und Wikis mit einer einzigen Abfrage ab. bio-research ist der ungewöhnlichste Eintrag und verbindet PubMed, bioRxiv, ChEMBL, Open Targets und Benchling für präklinische Forschung. cowork-plugin-management führt keine Konnektoren, es erzeugt und verändert die übrigen Pakete.
Installation per claude plugin marketplace add anthropics/knowledge-work-plugins
Für Cowork verweist die README auf den Katalog unter claude.com/plugins. Für Claude Code nennt sie zwei konkrete Befehle. Zuerst wird der Marketplace registriert mit claude plugin marketplace add anthropics/knowledge-work-plugins, danach folgt die Auswahl eines Pakets, etwa claude plugin install sales@knowledge-work-plugins.
Nach der Installation greifen Skills laut README automatisch, sobald das Thema passt, während Slash-Befehle in der Sitzung bereitstehen. Genannt werden /sales:call-prep, /data:write-query, /finance:reconciliation und /product-management:write-spec. Genau diese Trennung trägt den Unterschied zu einem langen Prompt: Der Befehl erzwingt einen Ablauf, der Skill wird vom Modell bei passendem Kontext gezogen.
Welche Befehle ein installiertes Paket tatsächlich mitbringt, steht nicht zentral im README, sondern im jeweiligen commands/-Verzeichnis. Wer wissen will, was /data:write-query auslöst, findet die Definition unter knowledge-work-plugins/data/commands/.
Aufbau eines Plugins: plugin.json, .mcp.json, commands/ und skills/
Alle Pakete folgen demselben Verzeichnisbaum. .claude-plugin/plugin.json trägt das Manifest. .mcp.json hält die Werkzeugverbindungen. commands/ sammelt die Slash-Befehle, skills/ das Domänenwissen, auf das Claude ohne Aufforderung zurückgreift. Weil alles aus Dateien besteht, entfallen laut README Infrastruktur und Build-Schritt, ein Fork mit geänderter Markdown-Datei und ein Pull Request sind der vollständige Beitragsweg.
Für Anpassungen nennt die README vier Hebel. Konnektoren werden durch Bearbeiten von .mcp.json ausgetauscht. Firmenbegriffe, Organisationsstruktur und Prozesse wandern in die Skill-Dateien. Abläufe werden in den Skill-Anweisungen so umgeschrieben, wie das Team wirklich arbeitet. Neue Rollen entstehen über cowork-plugin-management oder durch Nachbauen der Verzeichnisstruktur.
Das Repository steht unter Apache-2.0. Für die hier beschriebene Nutzung heißt das konkret: Die Skill- und Konnektor-Dateien dürfen kopiert, umgeschrieben und innerbetrieblich weitergegeben werden, auch in geschlossenen internen Plugins. Der Lizenztext enthält nach README-Lage keine Aussage zu Sicherheit, Support oder Gewährleistung, eine Haftung für falsch abgeglichene Konten oder fehlerhaft geprüfte Verträge übernimmt niemand.
Grenzen des dateibasierten Ansatzes bei knowledge-work-plugins
Die Grenzen liegen in genau dieser Einfachheit. Ein Skill ist Text, den ein Modell liest, und damit eine Empfehlung statt einer Garantie. Die README beschreibt das Auslösen als relevantabhängig, nicht als erzwungen; bei knapper Kontextlänge kann ein Skill unberücksichtigt bleiben.
Die Konnektoren sind zudem nur Verdrahtungen. Ob HubSpot, Snowflake oder Benchling tatsächlich erreichbar sind, hängt an MCP-Servern und Zugangsdaten, die das Repository nicht mitliefert. Ohne laufenden MCP-Server bleibt aus einem Paket ein Bündel Textbausteine.
Besonders vorsichtig zu lesen sind die stark regulierten Rollen. finance nennt Abstimmung, Abschluss und Auditbegleitung, ohne Freigabestufen, Vier-Augen-Prinzip oder Prüfpfade zu definieren. legal listet Vertragsprüfung, Compliance und Risikobewertung, ersetzt aber keine Rechtsberatung. bio-research bindet Forschungsdatenbanken an, ohne Angaben zur Validierung von Treffern. Zu all diesen Punkten macht das README keine belastbaren Aussagen, entsprechende Angaben fehlen in der Dokumentation.
Alternative zum Marketplace: eigener skills/-Ordner statt anthropics/knowledge-work-plugins
Wer keine der elf Rollen braucht, kommt mit einem eigenen skills/-Verzeichnis im Projekt ebenfalls ans Ziel. Der Unterschied liegt in Aufwand und Reichweite. Ein selbst geschriebener Skill deckt einen einzigen Ablauf ab, ist in kurzer Zeit geschrieben und bleibt ohne Werkzeuganbindung, solange keine zusätzliche MCP-Konfiguration ergänzt wird.
knowledge-work-plugins liefert stattdessen elf fertig verdrahtete Rollen samt Sub-Agenten und Befehlssammlung. Der Preis dafür ist die Passung: Die eigene Werkzeuglandschaft muss zu den aufgeführten Anbindungen passen, sonst ist ein großer Teil der Dateien unbrauchbar. Ein Team mit Slack, Notion und Jira findet in sales und customer-support weitgehend passende Verdrahtung. Ein Team mit selbst gehosteter Wissensdatenbank beginnt ohnehin bei .mcp.json.
Ein sinnvoller Einstieg ist deshalb ein Vergleich im Kleinen. Dazu wird sales@knowledge-work-plugins installiert und ein Befehl aus sales/commands/ gegen einen selbst geschriebenen Skill mit derselben Aufgabe gestellt. Wer danach sehen will, ob die Anbindung trägt, öffnet .mcp.json des installierten Pakets und prüft, ob die dort geforderten MCP-Server mit den im Unternehmen tatsächlich vorhandenen Konten übereinstimmen.
Redaktionelles Fazit
Geeignet ist das Repository für Teams, deren Werkzeuglandschaft bereits zu den aufgeführten Konnektoren passt und die wiederkehrende Abläufe einmal beschreiben wollen, statt sie in jedem Prompt zu wiederholen. Weniger geeignet ist es für Unternehmen mit stark individueller Infrastruktur, denn dann beginnt die Arbeit an .mcp.json ohnehin von vorn. Wer einsteigt, sollte zuerst das Verzeichnis eines einzigen Plugins öffnen, etwa sales mit seinem .mcp.json, und prüfen, ob die dort eingetragenen MCP-Server mit den tatsächlich genutzten Konten übereinstimmen. Für regulierte Abläufe in finance oder legal fehlen im README Angaben zu Freigabestufen und Prüfpfaden, diese müssen vor einem Einsatz intern ergänzt werden.
Community-Notizen