BMad Method – Rollen und Skills

BMad Method – Rollen und Skills

0:00 Bis hierher haben wir über Artefakte gesprochen. Jetzt wird es konkret: Wie kommen die eigentlich zustande, ohne dass jeder im Team seine eigene Vorlage pflegt? Die BMad Method ist eine Antwort darauf, und sie ist in diesem Seminar das durchgehende Praxisbeispiel — nicht, weil sie alternativlos wäre, sondern weil sie den ganzen Weg von der Idee bis zum Review abdeckt und man daran gut sehen kann, wie so ein Prozess im Projekt landet.

0:25 Wichtig für die kommenden Minuten: Wir schauen auf das Prinzip. Namen und Details ändern sich, das Muster dahinter bleibt.

BMad Method – Rollen und Skills

0:32 Vier Abschnitte. Zuerst der Aufbau: Was passiert eigentlich bei der Installation, und wo landen die Sachen? Dann die Rollen — und die für die Praxis wichtige Unterscheidung zwischen einer Rolle, einem Skill und einem Subagenten. Danach die Skills selbst, wobei wir uns auf die konzentrieren, die man wirklich braucht. Und zum Schluss installieren Sie selbst und sehen nach, was entstanden ist.

Aufbau und Funktionsweise

0:55 Beginnen wir mit der einfachsten und oft übersprungenen Frage: Was liegt nach der Installation eigentlich im Projekt, und wer liest das? Diese Frage klingt banal, entscheidet aber darüber, ob die Methode im Team ankommt oder nur bei der Person, die sie eingerichtet hat. Denn was im Projekt liegt, gilt für alle — und was nur im Kopf liegt, gilt für einen.

1:15 Der entscheidende Punkt steckt in einem unscheinbaren Wort: im Projekt. Die Methode kommt nicht als Handbuch, das jemand gelesen haben müsste, sondern als benannte Arbeitsabläufe, die im Repository liegen. Der Vergleich, der mir dazu einfällt, ist die Werkstatt: Es macht einen Unterschied, ob die Anleitung im Ordner im Büro steht oder ob das Werkzeug an der Wand hängt, beschriftet, für jeden griffbereit.

1:39 Dazu kommt ein Verzeichnis mit gemeinsamer Konfiguration. Aufgerufen werden die Abläufe übrigens im Coding Agent, nicht auf der Kommandozeile — das verwirrt am Anfang regelmäßig. Sie sehen hier zwei verschiedene Welten in einem Block, und das ist Absicht. Die ersten beiden Zeilen laufen in der Shell — ein Installer, der Sie durch Module und Werkzeugwahl führt.

2:00 Die Zeile darunter läuft nicht in der Shell, sondern im Coding Agent selbst; sie ist der Einstiegspunkt, wenn man nicht weiß, welcher Ablauf jetzt der richtige wäre. Achten Sie auf die Fußzeile: uv, der Python-Paketmanager, ist keine Empfehlung, sondern Voraussetzung für genau die Abläufe, die Sie am häufigsten brauchen werden.

2:18 Wer ihn überspringt, wundert sich später über Abbrüche an unerwarteter Stelle. Diese Tabelle sieht nach einem Detail aus, kostet aber regelmäßig eine Viertelstunde Fehlersuche. Verschiedene Werkzeuge lesen verschiedene Verzeichnisse. Landen die Abläufe am falschen Ort, passiert nichts Dramatisches — sie sind einfach unsichtbar, ohne Fehlermeldung.

2:40 Das ist die unangenehmste Art von Fehler, weil nichts kaputtgeht. Merken Sie sich deshalb: Der Ort entscheidet, welches Werkzeug die Abläufe sieht. Er entscheidet nicht, was sie tun. Wenn Sie im Team verschiedene Werkzeuge einsetzen, ist das eine Frage, die Sie einmal klären und dann festhalten. Der eigentliche Gewinn liegt nicht in den Abläufen selbst, sondern darin, dass sie versioniert sind.

3:03 Damit gilt für alle im Team dasselbe — nicht nur für die zwei Leute, die ihre Prompts über die Jahre verfeinert haben. Der Einstieg braucht keinen persönlichen Fundus mehr, sondern einen Namen. Das senkt die Hürde für alle anderen erheblich. Und weil die Installation den Bestand erkennt, lässt sich später nachrüsten, ohne den Kern anzufassen.

3:23 Das klingt technisch, ist aber der Unterschied zwischen einem Werkzeug, das ein Team benutzt, und einem, das eine Person benutzt. Die ersten beiden Punkte haben wir gerade gestreift, sie sind reine Einrichtungsfallen. Interessanter ist der dritte: Wer alle Module installiert, hat plötzlich Dutzende Abläufe und sucht zwischen ihnen.

3:43 Weniger ist hier tatsächlich mehr, weil nur bekannte Abläufe benutzt werden. Der vierte Punkt ist der, der im Seminarraum die meisten Nachfragen erzeugt: Greenfield-Anleitungen auf eine bestehende Codebasis anzuwenden, führt zuverlässig in die Irre. Für Bestandscode gelten andere Startschritte — dazu kommen wir im Modul über Brownfield noch ausführlich.

Zentrale Rollen

4:03 Kommen wir zu den Rollen. Sie sind der Teil, über den am meisten geschrieben wird — und der am häufigsten missverstanden wird. Das liegt daran, dass sie anschaulich sind: Ein Architekt und eine Produktmanagerin kann man sich vorstellen, einen Arbeitsablauf weniger. Genau deshalb lohnt es sich, hier genauer hinzusehen — und die Rolle von zwei anderen Dingen abzugrenzen.

4:25 Der Unterschied zwischen Rolle und Skill lässt sich an einer Beratung erklären. Ein Formular ist ein Ablauf: Sie füllen es aus, geben es ab, es ist erledigt. Ein Gespräch mit einer Beraterin ist etwas anderes — sie bleibt im Raum, fragt zurück, antwortet aus ihrer Perspektive. Beides hat seinen Platz, aber es sind verschiedene Dinge.

4:45 Eine Rolle ist die Beraterin: eine benannte Identität mit Zuständigkeit, die im Gespräch aktiv bleibt. Ein Skill ist das Formular. Und der Subagent ist wieder etwas Drittes, nämlich schlicht ein zweiter Kontext, in dem gearbeitet wird. Diese fünf Zuständigkeiten werden Ihnen bekannt vorkommen, denn es sind die Rollen, die in jedem Softwareprojekt vorkommen — nur dass sie hier als Persona aufrufbar sind.

5:09 Der Nutzen liegt weniger in der Antwort selbst als in der Perspektive: Ein Architekt fragt anders nach als ein Product Manager, und manchmal will man genau diese andere Frage hören. Wichtig ist die Fußzeile: Die Rollen bündeln Zuständigkeit, sie ersetzen sie nicht. Wenn die Architektin im Team eine Entscheidung trifft, dann trifft sie diese Entscheidung — und nicht die Persona, die man vorher befragt hat.

5:32 Warum lohnt sich diese Begriffsarbeit? Weil sie bestimmt, wo Sie bei einem Problem suchen. Wenn ein Ergebnis fehlt, war es ein Skill, und Sie schauen in seine Ausgabe. Wenn eine Einschätzung schräg war, war es eine Rolle, und Sie schauen auf die Frage, die Sie gestellt haben. Wenn der Hauptkontext vollgelaufen ist, hätte ein Subagent geholfen.

5:53 Rollen helfen bei Diskussionen, Skills bei wiederholbarer Arbeit, Subagents beim Kontext. Wer die drei vermischt, sucht am falschen Ende — und das kostet mehr Zeit als jede Begriffsdiskussion. Der erste Punkt ist der wichtigste dieses Kapitels: Rollenspiel ersetzt keine Spezifikation. Eine Persona kann sehr überzeugend klingen und trotzdem nichts festhalten.

6:14 Der zweite Punkt ist subtiler — wenn Sie mehrere Rollen gleichzeitig befragen, bekommen Sie oft Konsens statt Widerspruch, und Konsens ist genau das, wofür Sie sie nicht gebraucht hätten. Der dritte betrifft die Sprache im Team: Sobald man die Persona zitiert, als hätte sie entschieden, verschiebt sich unbemerkt die Verantwortung.

6:32 Entschieden hat immer ein Mensch, auch wenn der Vorschlag von woanders kam.

Wichtige Skills

6:37 Jetzt zu den Abläufen selbst. Es gibt viele davon — die gute Nachricht ist, dass Sie sich nur eine Handvoll merken müssen. Die Auswahl folgt dabei keiner Geschmacksfrage, sondern der Kette, die wir im ersten Modul gezeichnet haben. Wer die Kette kennt, kennt auch die Abläufe, die man täglich braucht — und kann den Rest getrost liegen lassen, bis eine konkrete Not danach verlangt.

6:59 Die Kernskills bilden genau die Kette ab, die wir im ersten Modul gezeichnet haben: Kontext setzen, spezifizieren, bauen, prüfen, testen. Das ist kein Zufall, sondern der ganze Gedanke — die Methode gießt den Prozess in aufrufbare Form. Daneben gibt es Abläufe für Recherche, Ideenprüfung und Anpassung. Die brauchen Sie selten, aber wenn Sie sie brauchen, dann gezielt.

7:22 Mein Rat für den Einstieg: Lernen Sie die Kette, ignorieren Sie den Rest, und holen Sie ihn erst, wenn eine konkrete Not danach verlangt. Lesen Sie diese Tabelle bitte in der rechten Spalte. Nicht die Namen sind das Interessante, sondern was jeweils übrig bleibt: ein Kontextblock, eine Spezifikation, geordnete Stories, ein Commit mit Tests, eine Befundliste.

7:45 Wenn Sie später ein anderes Werkzeug einsetzen, werden die Namen andere sein — die Ergebnisse werden dieselben sein. Und noch ein Hinweis, den Sie in der Fußzeile finden: Dieser Stand ist von September 2026. Diese Namen ändern sich schneller als Foliensätze. Prüfen Sie sie vor dem Einsatz gegen die aktuelle Dokumentation, nicht gegen Ihre Notizen.

8:07 Vier Abläufe decken den Alltag ab: Kontext, Spec, Build, Review. Das ist keine Bescheidenheit, sondern eine Beobachtung — alles Weitere sollte durch eine konkrete Not gerechtfertigt sein und nicht durch den Wunsch nach Vollständigkeit. Der praktische Grund dahinter ist banal: Nur wenige Abläufe bleiben im Team wirklich bekannt. Ein Katalog mit dreißig Einträgen wird nach zwei Wochen nicht mehr geöffnet.

8:30 Und für den Fall, dass man doch einmal nicht weiterweiß, gibt es einen Hilfsskill, der den nächsten Schritt empfiehlt. Auswendiglernen ist also ausdrücklich nicht nötig. Der erste Punkt beschreibt ein Muster, das ich häufig sehe: Abläufe werden aufgerufen, weil sie da sind, und erzeugen Artefakte, die niemand liest. Das ist teurer als gar kein Prozess, weil es zusätzlich den Eindruck von Sorgfalt erzeugt.

8:55 Der zweite Punkt ist eine Grundregel dieses Seminars: Ein Ablauf bereitet eine Entscheidung vor, er ersetzt sie nicht. Der dritte betrifft die Halbwertszeit von Notizen. Und der vierte ist eine Erfahrung aus Projekten: Wer den Kontext-Schritt überspringt, bezahlt das in jeder einzelnen späteren Sitzung — in kleinen Beträgen, die sich summieren.

Installation im Projekt

9:15 Genug Theorie. Im letzten Kapitel installieren Sie selbst — und wichtiger noch: Sie sehen nach, was dabei entstanden ist. Das ist keine Fleißaufgabe. Ein Werkzeug, das Dateien in Ihrem Repository anlegt und liest, sollten Sie einmal gesehen haben, bevor Sie ihm Aufträge geben. Zehn Minuten Neugier ersparen später die Frage, woher eine Datei eigentlich kommt.

9:39 Es gibt eine Angewohnheit, die uns allen vertraut ist: Ein Werkzeug installieren und sofort benutzen, ohne nachzusehen, was es angelegt hat. Bei einem Werkzeug, das Dateien in Ihrem Repository erzeugt und liest, ist das keine gute Idee. Die Installation ist erst dann verstanden, wenn Sie die Verzeichnisse gesehen haben: die Abläufe mit ihren Beschreibungen, die gemeinsame Konfiguration und die Orte, an denen später Ausgaben landen.

10:03 Das dauert zehn Minuten und erspart Ihnen später die Frage, woher eine Datei eigentlich kommt. Der rote Faden dieser fünf Schritte ist Neugier statt Ergebnis. Sie installieren, Sie lesen die Beschreibungen quer, Sie schauen in die Konfiguration — und ändern dort ausdrücklich nichts. Dann fragen Sie den Hilfsskill nach einer Empfehlung und spielen einen kleinen, umkehrbaren Auftrag durch. Beachten Sie die Fußzeile: Der erste Lauf dient dem Vertrautwerden.

10:30 Wenn dabei ein brauchbares Ergebnis herauskommt, ist das ein Nebeneffekt. Wer beim ersten Lauf gleich etwas Wichtiges baut, lernt weniger und riskiert mehr. Ihre Aufgabe: Installieren Sie in das vorbereitete Repository und untersuchen Sie anschließend, was entstanden ist. Benennen Sie das Skill-Verzeichnis, die Konfiguration und die Ausgabeorte — und erklären Sie einem Nachbarn den Unterschied zwischen einem Skill und einer Rolle.

10:56 Ein Hinweis, der die Übung lohnender macht: Notieren Sie am Ende, welche Abläufe Sie in Ihrem Team vermutlich nie aufrufen werden. Diese Liste ist genauso wertvoll wie die andere, denn nicht installierte Module muss niemand kennen, pflegen oder erklären. Was bleibt aus diesem Modul? Die Methode liegt als Abläufe im Projekt, nicht als Anleitung im Wiki — das ist der eigentliche Unterschied zu früheren Prozessversuchen.

11:20 Rolle, Skill und Subagent unterscheiden sich in Lebensdauer und Zweck, und diese Unterscheidung spart Ihnen Fehlersuche. Vier Skills decken den Alltag ab. Und was installiert ist, sollte man einmal angesehen haben, bevor man es benutzt. Im nächsten Modul kümmern wir uns um das, was der Agent in jeder Sitzung braucht: den dauerhaften Projektkontext.