WorkBuddyGuide: das Praxisbuch hinter workbuddy.homes und sein Beitragsraster

Vier Teile plus Anhang: wie docs/bluebook gegliedert ist

Das Repository AlephAITech/WorkBuddyGuide trägt den Untertitel WorkBuddy-Praxisbuch und stellt sich selbst als Leseheft mit realen Aufgaben vor, nicht als Umschreibung der offiziellen Funktionsdokumentation. Die README legt einen Ablauf fest: erst Installation und erste Aufgabe, dann mobiles Arbeiten, Wissensverwaltung, fachliche Diagnose, Inhaltsautomatisierung und Multi-Agenten-Teams, am Ende der Schritt vom einzelnen Erfolg zum wiederverwendbaren Arbeitssystem.

Die Gliederung steht als Tabelle in der README. Der erste Teil ist ein Handbuch und deckt Download, Installation, Oberfläche, erste Aufgabe, Skill, Konnektoren, API und Automatisierung ab. Der zweite Teil sammelt Fälle aus Büroarbeit, Dateien, Fernzugriff, Nachrichten, Wissen, Besprechungen, Investment, Video, eigenen Medien und GEO. Teil drei behandelt das Bauen eigener Skills, den Entwurf von Multi-Agenten-Systemen und die Verlässlichkeit von Automatisierung. Teil vier ordnet Rollen und Branchen zu, der Anhang hält Befehlsvorlagen und eine Szenarien-Schnellübersicht bereit.

Eine Lücke fällt zwischen Beschreibung und Tabelle auf. MCP wird in der Projektbeschreibung genannt, in der Teile-Tabelle taucht es nicht auf. Dort heißt das entsprechende Element Konnektoren.

Drei Lesarten: Kapitel 1, ein Fall aus Teil zwei, docs/reading-guide.md

Die README schlägt drei Einstiege vor, und die Reihenfolge ist nicht beliebig. Wer WorkBuddy zum ersten Mal benutzt, beginnt bei Kapitel 1 und arbeitet den ersten Teil der Reihe nach durch. Wer schon eine konkrete Aufgabe hat, springt direkt in den passenden Fall des zweiten Teils, führt ihn einmal aus und liest erst danach Teil drei.

Für die Einführung in einem Team empfiehlt die README die Teile drei und vier und verbindet das mit einer Notizpflicht: Berechtigungsgrenzen, Abnahmekriterien und Rückfallverhalten sollen schriftlich festgehalten werden. Das ist für ein Leseheft ungewöhnlich bestimmt und verschiebt den Schwerpunkt von der Bedienung hin zur Absicherung.

Ein längerer Weg ist in docs/reading-guide.md hinterlegt. Die Website unter workbuddy.homes bietet laut README Seitenleiste, Volltextsuche, Inhaltsverzeichnis, Dunkelmodus, Flussdiagramme und eine mobile Ansicht, was gegen das reine Lesen im GitHub-Repository spricht.

Der Fragebogen unter workbuddy.homes/help und seine fünf Pflichtfelder

Wer ein reales Szenario hat und nicht weiß, wie es sich mit WorkBuddy abbilden lässt, kann es über das Formular unter workbuddy.homes/help einreichen. Die README nennt fünf Angaben, die eine Einsendung enthalten soll: das Problem, die bisherige Vorgehensweise, die verwendeten Unterlagen, das erwartete Ergebnis und die Sicherheitsgrenze. Diese Felder sind keine Formalität, sie spiegeln die Angaben, die später auch ein veröffentlichter Fall braucht.

Die Betreuenden lesen und bewerten jede Einsendung und melden sich über die hinterlassene Kontaktmöglichkeit, falls Angaben fehlen. Eine Antwortfrist nennt die README nicht, ebenso wenig eine Zusage auf jede Einsendung. Repräsentative Fragen werden zu einem offenen Fall ausgearbeitet und in der Fallsammlung unter workbuddy.homes/cases veröffentlicht.

Sechs Pflichtangaben pro Fall in docs/cases/submissions

Beiträge folgen einem festen Raster. Vor dem Einreichen sollen Einsendende die Fallsammlung und das Inhaltsverzeichnis durchsuchen, damit kein Szenario doppelt entsteht. Führt ein anderer Skill oder eine andere Methode zum gleichen Ziel, muss der Pull Request den Unterschied benennen.

Jeder Fall braucht sechs Angaben: das Szenario mit der Frage, wer woran gescheitert ist, den verwendeten Skill samt Wirkung, Herkunft, Installation und nötiger Konfiguration, die Aufgabenbeschreibung mit Hinweisen, Schritten oder Automationseinstellungen, den Ablauf mit Schlüsseloperationen, Rechten, Eingabedaten und Sicherheitsgrenze, das Ergebnis belegt durch Bildschirmfotos oder andere Nachweise, sowie die Abnahmekriterien.

Abgelegt werden neue Fälle in einem eigenen Verzeichnis unter docs/cases/submissions, geschrieben nach .github/CASE_TEMPLATE.md und eingereicht über .github/PULL_REQUEST_TEMPLATE/case.md. Nach der Prüfung erscheint der Fall in der linken Navigation der Website; repräsentative Fälle können nach erneuter Reproduktion und redaktioneller Bearbeitung in ein reguläres Kapitel wandern.

Node.js 20 bis 24, npm run docs:build und Cloudflare Pages

Die Website ist ein VitePress-Projekt. Für die lokale Arbeit verlangt die README Node.js 20 bis 24 und empfiehlt Version 22. Vier Befehle werden genannt: npm install und npm run dev für die Entwicklung, npm run docs:build sowie npm run docs:preview für den lokalen Build und dessen Ansicht.

Ausgeliefert wird über Cloudflare Pages, verbunden mit dem main-Zweig dieses Repositorys. Jeder Push auf main löst laut README einen automatischen Build und eine Auslieferung aus, die Einzelheiten stehen in DEPLOYMENT.md. Andere Hosting-Varianten werden nicht erwähnt.

Im Verzeichnisbaum liegen die Inhalte unter docs/bluebook, die Konfiguration in docs/.vitepress, die Gemeinschaftsseiten in docs/community, das Formular in docs/help und statische Mittel in docs/public. Hinzu kommt scripts für Inhaltssynchronisation und Hilfswerkzeuge, deren Aufrufe die README nicht beschreibt.

Python in den Metadaten, Node.js im Build: was offengelassen wird

Die abgerufenen Metadaten weisen Python als Hauptsprache aus, während der gesamte dokumentierte Arbeitsablauf auf Node.js und npm beruht. Die README nennt keine Python-Datei, die aufgeführten Verzeichnisse und Befehle sind durchweg JavaScript-seitig. Für die Einstufung dürfte die Sammlung unter scripts verantwortlich sein, belegen lässt sich das aus dem Material nicht.

Ebenso fehlt ein Zeitanker. Im abgerufenen Datensatz ist kein Datum des letzten Push hinterlegt, und die Release-Liste ist leer. Es gibt damit keine Versionen, auf die sich ein Leser beziehen könnte; Inhalte ändern sich ausschließlich über Commits auf main. Wer eine Passage zitieren will, muss den Commit festhalten.

Die Metadaten nennen 2.516 Sterne, 356 Forks und 16 offene Issues. Solche Zahlen belegen Reichweite, aber nicht, ob ein Kapitel noch zur aktuellen Produktversion passt.

MIT-Lizenz, Haftungsausschluss und die Grenze zur offiziellen Dokumentation

Das Projekt steht unter MIT. Die README formuliert die Bedingungen knapp: Verwenden, Kopieren, Ändern und Weitergeben sind erlaubt, solange der ursprüngliche Urhebervermerk und der Lizenztext erhalten bleiben. Auszüge dürfen also in internen Handbüchern weiterverwendet werden, eine Gewähr für die Richtigkeit der beschriebenen Arbeitsschritte ist damit nicht verbunden.

Deutlicher ist die eigene Einordnung am Ende der README. Das Projekt versteht sich als gemeinschaftlich gepflegte Wissenssammlung, und bei allem Zeitabhängigen, also Funktionen, Oberfläche, Preisen, Verfügbarkeit und Sicherheitsrichtlinien, gelten die offiziellen WorkBuddy-Kanäle als maßgeblich.

Genau dort liegt die Grenze zur Alternative. Die offizielle Produktdokumentation ist verbindlich für die Frage, was ein Produkt kann. Das Praxisbuch liefert stattdessen Aufgabenfolgen, Abnahmekriterien und Rückfallpläne, also das, was eine reine Funktionsliste selten enthält.

Redaktionelles Fazit

Sinnvoll ist WorkBuddyGuide für alle, die WorkBuddy schon nutzen und eine konkrete Aufgabe abbilden wollen; der zweite Teil und die Fälle unter docs/cases/submissions sind dafür der kürzeste Einstieg. Weniger geeignet ist es als verbindliche Funktionsreferenz, denn für Oberfläche, Preise und Sicherheitsrichtlinien verweist die README selbst auf die offiziellen WorkBuddy-Kanäle. Wer das Buch im Team einsetzt, startet mit Node.js 22, npm install und npm run dev, arbeitet einen veröffentlichten Fall bis zu dessen Abnahmekriterien durch und legt erst danach einen eigenen Eintrag unter docs/cases/submissions an.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository