Modul 10

Team-Workflows & Konsolidierung

Tag 3 · ca. 70 Minuten

Inhalt

1Konfiguration ins Repo — was geteilt wird, Weiterentwicklung per Pull Request, CLAUDE.md im Team 2Teilen über Projekte hinweg — Plugins, Bibliotheken, das Scaffold, Konsolidierung über Teams 3Der Preis — Slop Creep, Cognitive Debt, Respectful Pull Requests Übung 10 — Workflow-Definition als Pull Request, danach Diskussionsrunde Kursabschluss — zehn Lernziele, Ausblick, Feedback

Lernziel Modul 10

Der Teilnehmer kann Skills, Commands und Rules im Team versionieren, per Pull Request weiterentwickeln und über mehrere Teams konsolidieren.

Versionieren — die Agenten-Konfiguration liegt im Repo, mit Historie und Eigentümer.
Per Pull Request weiterentwickeln — eine neue Rule geht durch dasselbe Review wie Code.
Über Teams konsolidieren — was mehrere Teams gleich machen, wandert in ein gemeinsames Bündel.

Die Agenten-Konfiguration ist Code — alles Weitere in diesem Modul folgt daraus.

Konfiguration ins Repo

Skills, Commands, Rules und Workflow-Definitionen als Team-Asset

Was ins Repo gehört und was nicht

Nach ein paar Wochen hat jede:r eigene Skills, eigene Commands, eigene Regeln gebaut.
Liegen sie lokal, hat jede:r einen anderen Agenten — Ergebnisse sind nicht vergleichbar, Verbesserungen nicht teilbar, und wer geht, nimmt sein Setup mit.

Artefakt	Ebene	Warum
`CLAUDE.md` · `.claude/rules/`	Repo, versioniert	Projektwissen und Konventionen sind Team-Entscheidungen
`.claude/skills/` · `commands/`	Repo, versioniert	wiederholbare Abläufe und ihre Einstiegspunkte
`.claude/agents/`	Repo, versioniert	Review-Standards des Teams
Permissions — Team-Teil	Repo, versioniert	Verbote sind nicht verhandelbar (Modul 9)
Permissions — persönlicher Teil	lokal, `.gitignore`	individuelle Bequemlichkeit
Zugänge, Tokens, Keys	nie im Repo	Secrets bleiben Secrets

Faustregel: Würde ein neuer Kollege es brauchen? Dann ins Repo.
Ist es Geschmack oder Geheimnis? Dann lokal.

Der Beleg: die Historie erzählt das Warum

In einem gepflegten Repo liegt die gesamte Agenten-Konfiguration versioniert — und ihre Commit-Historie ist die Begründungskette des Teams.

                    # cgsit-finance

                    .claude/

                      rules/ 9 Dateien — java, angular, api,

                           testing, database, migration-safety,

                           quarkus, money-fx, ui-theming

                      skills/ 11 — build, test, commit, ship,

                           deploy, tag, rfcs, reviewer …

                      agents/ 3   commands/ 4

                      settings.json

                    docs(rules): Overlay-Audit-Grep auf

                      z-index+absolute erweitern (RFC-236-Lehre)

                    docs(skills): gh run list needs

                      --workflow CI (avoid watching wrong run)

                    tooling(rfc-gate): add PostToolUse

                      evidence-gate hook for RFC status flips

                    docs: zwei Lehren aus RFC-241

                      festschreiben (record-Ctor + stille Defaults)

Das Muster Jeder dieser Commits ist ein Fehlschlag, der nicht wieder passieren soll. Die Konfiguration wächst nicht durch Planung, sondern durch Lehren — und der Weg dorthin ist der normale Code-Weg: Auslöser, Branch, kleine Änderung, Review durch einen Menschen, Merge. Das Review ist Pflicht, weil eine Regel eine Team-Entscheidung ist und kein Vorschlag. Wer keine Historie hat, lernt jede Lehre mehrfach.

Die sozialen Fallstricke der CLAUDE.md

Modul 7 hatte die technischen Fallstricke: zu lang, zu vage, veraltet.
Die sozialen sind hartnäckiger, weil sie niemandem zuzurechnen sind.

Wie die Datei verrottet

Jeder schreibt rein, keiner löscht. Sie wächst monoton — nach einem Jahr liest sie niemand zu Ende. Der Agent auch nicht wirklich.

Regeln, die nie jemand entschieden hat. Ein Satz, den jemand nachts eingetragen hat, gilt seitdem als Standard. Gefragt wurde niemand.

Behandeln wie Code

Jede Regel braucht einen Auslöser — kein „wäre gut", sondern ein konkreter Fall, erklärt im Commit.

Löschen ist ein legitimer Pull Request. Regeln, die niemand lebt, gehören raus — gelöscht, nicht weichgespült.

Entscheidungen woanders treffen. Grundsatzfragen klärt das Team; in die Datei kommt das Ergebnis.

Teilen über Projekte hinweg

Plugins, Bibliotheken, Scaffold — und die Konsolidierung

Plugins statt Kopieren

Ein Repo teilt seine Konfiguration mit sich selbst.
Sobald dieselbe Arbeitsweise in mehreren Repos gebraucht wird, ist Copy-Paste die falsche Antwort.

Kopieren

Zwölf Dateien in acht Repos. Nach drei Monaten acht Varianten.

Eine Verbesserung müsste achtmal nachgezogen werden — wird sie nicht.

Bündeln

Ein Plugin fasst zusammengehörige Skills, Commands, Agents und Hooks zu einer installierbaren Einheit mit einer Version.

Dasselbe gilt für die Formulierungen selbst: bewährte Prompts und Vorlagen (RFC, Review, Handoff) als Datei im Repo, nicht als Screenshot im Chat.

Der Engpass ist selten das Bündeln, sondern die Auffindbarkeit: Ein Ort, klare Namen.
Was niemand findet, benutzt niemand — und baut es neu.

Vom Scaffold zur Konsolidierung

cgsit-claude-scaffold ist ein Startpaket für neue Projekte: Ablagestruktur, Basis-Rules, Standard-Skills, Doku-Vorlagen — fertig, aber leer.

1Übernehmen — .claude/, docs/, tasks/ und CLAUDE.md ins neue Projekt.

2Füllen — der Agent interviewt das Team und füllt die Doku-Vorlagen.

3Anpassen — Rules und Skills auf den Stack ziehen. Ein Startpunkt, kein Gesetz.

4Zurückspielen — was sich in mehreren Projekten bewährt, wandert per Pull Request zurück.

Über mehrere Teams: der harte Kern zentral, der Rest föderal.

Vereinheitlichen — Sicherheit und Verbote, die Ablagestruktur (damit man sich in fremden Repos zurechtfindet), die Qualitäts-Gates.
Lokal lassen — Stack-Konventionen und Domänenwissen. Java-Regeln helfen dem Frontend-Team nicht.
Eigentümerschaft klären — ein Name pro geteiltem Artefakt. Ohne Eigentümer verrottet es.

so gemeint

Scaffold

Projekt A

Projekt B

Projekt C

was sich bewährt, kommt per Pull Request zurück

so läuft es

Scaffold
von damals

Projekt A

Projekt B

Projekt C

kein Rückweg — nach einem Jahr ist die Quelle die schlechteste Konfiguration im Haus

Schritt 4 ist der, der meistens fehlt

Der Preis

Was Teams langfristig verlieren können

„Slop Creep"

Schleichender Qualitätsverfall, wenn ungeprüfter Agenten-Output ins Repo sickert.
Kein einzelner Fehler — eine Drift, die niemand datieren kann.

Woran man es erkennt

Plausibler, redundanter Code — funktioniert, ist aber die vierte Variante derselben Sache an einer neuen Stelle.

Tests, die nichts prüfen — grün, hohe Abdeckung, keine Aussage: Assertions gegen das eigene Ergebnis.

Doku ohne Autor und ohne Leser.

Was dagegen hilft

Schönheit ist kein Signal. Bei generiertem Code sagt ein sauber aussehender Diff nichts über seine Richtigkeit.

„Gibt es das schon?" — die wirksamste Frage, und zwar vor der Implementierung, nicht im Review.

Gates statt Vorsätze (Modul 9). Was nicht automatisch prüft, prüft auf Dauer niemand.

ein Bug

Commit

einer ist falsch — man kann ihn datieren, benennen, beheben

Slop Creep

Commit

keiner ist falsch — der Stand ist es. Kein Datum, kein Schuldiger

je dunkler, desto mehr ungeprüfter Output steckt darin

„Cognitive Debt"

Kompetenzverlust durch Delegation. Wer nur noch abnimmt, versteht das System irgendwann nicht mehr — und merkt es zuletzt.

Mehr delegieren

Weniger selbst
verstehen

Abnahme wird
oberflächlicher

Fehler fallen
später auf

… also noch
mehr delegieren

Manches bewusst selbst machen — nicht aus Nostalgie: Verständnis entsteht beim Tun. Kandidaten sind die Bereiche, für die ihr geradesteht.
Junioren nicht dem Agenten überlassen — wer nie selbst gesucht hat, kann später nicht beurteilen. Onboarding ist Menschenarbeit.
Erklären können als Kriterium — wer den eigenen Pull Request nicht erklären kann, hat ihn nicht verstanden.

Respectful Pull Requests

Ein Werkzeug, das den Autor schneller macht, verschiebt Aufwand — es beseitigt ihn nicht.

Beim Autor

2000 Zeilen, generiert in 20 Minuten. Fühlt sich nach einem außergewöhnlich produktiven Vormittag an.

Beim Reviewer

2000 Zeilen fremde Logik, zwei Stunden konzentriertes Lesen — aus einem anderen Kontext heraus, mit eigener Arbeit auf dem Tisch.

Der Geschwindigkeitsgewinn beim Autor ist ein Kostenanstieg beim Reviewer.
Ein Pull Request, der in 20 Minuten entstanden ist, darf trotzdem in fünf zerlegt werden — und die Beschreibung kommt vom Menschen, nicht vom Agenten.

Übung 10 — Workflow-Definition als Pull Request

Aufgabe

Nehmt eine Workflow-Definition, die ihr in den letzten beiden Tagen gebaut habt — einen Skill, einen Command oder eine Rule — und bringt sie als Pull Request in das Repo seminar-api ein.

Pflichtbestandteile: Beschreibung vom Menschen (warum diese Regel, welcher konkrete Auslöser), kleiner Diff, ein Thema. Anschließend reviewt ihr paarweise gegenseitig — mit Kommentaren, nicht mit „passt".

Verifizierbares Ergebnis: Ein gemergter Pull Request, dessen Beschreibung einen datierten Auslöser nennt — und mindestens ein Review-Kommentar, der eine Rückfrage stellt statt zuzustimmen.

Dauer ca. 25 Minuten · Paararbeit · danach Auflösung und Diskussion im Plenum

Auflösung und Diskussionsrunde

Der Lerneffekt steckt im Review, nicht im Pull Request.
Zwei Dinge werden dabei erfahrbar, und beide sind unbequem.

Eine Regel verständlich zu formulieren ist schwer

Wer beim Lesen zurückfragen muss, hat einen Auslöser-Text vor sich, der den Vorfall nicht trägt — nicht einen begriffsstutzigen Reviewer.

Fremden generierten Diff zu lesen ist unangenehm

Genau das ist Respectful Pull Requests am eigenen Leib — eine Folie vorher war es noch eine Behauptung.

Moderierte Runde — ihr kommt aus verschiedenen Unternehmen, das ist der wertvollste Teil:

Ablage — liegt eure Konfiguration im Repo oder auf Laptops? Was hindert den Umzug?
Eigentümerschaft — wer entscheidet bei euch, was in die CLAUDE.md kommt und was raus?
Slop Creep und Cognitive Debt — Anzeichen gesehen? Wo würdet ihr bewusst nicht delegieren?

Kursabschluss

Zehn Module, zehn Lernziele

Modul	Das könnt ihr jetzt
1 Grundlagen	Verstehen, warum Modelle zustandslos und nicht-deterministisch sind — und die typischen Einstiegsfehler daraus ableiten.
2 Baukasten	Jedes Primitiv benennen und das richtige Werkzeug für den Zweck wählen.
3 Prompting & Context	Prompts strukturieren, Context kuratieren, Qualitätsverfall bei vollem Fenster erkennen.
4 Praktische Arbeit	Den täglichen Zyklus beherrschen — Review-Loops, Approvals, Session-Management.
5 Agentic SDLC	Den Phasen-Workflow von Analyse bis Deploy mit Gates und Artefakten durchführen.
6 Workflow-Frameworks	QRSPI, BMAD und OpenSpec nach Philosophie einordnen und begründet wählen.
7 Codebase	Eine Codebase agent-ready machen — navigierbar, verifizierbar, mit Handoff-Artefakten.
8 Skills & Infrastruktur	Skills, Rules, Commands und Hooks pro Phase bauen; Git-Handling autonom gestalten.
9 Testing & Security	Tests und Security-Checks als Gates einbauen, agentische Review-Loops aufsetzen.
10 Team-Workflows	Konfiguration versionieren, per Pull Request weiterentwickeln, über Teams konsolidieren.

Die Kursklammer: den Agenten steuern statt ihm zu folgen — Aufgaben zuschneiden, Zwischenergebnisse prüfen, Fehlläufe erkennen und korrigieren.

Was bleibt, was veraltet

Hält

Context ist ein Budget. Permissions sind eine Vertrauensgrenze. Wissen gehört ins Repo. Gates schlagen Vorsätze. Verifizierbare Ergebnisse statt reproduzierbarer Wege.

Veraltet

Flags, Settings-Schlüssel, Hook-Ereignisse, Modell-Kennungen, Slash-Commands, Plugin-Mechanik, Preise. Alles, was in diesem Kurs in einem gestempelten Kasten stand.

Bevor ihr geht — vier Fragen:

Was nehmt ihr Montag konkret mit in euer Projekt?
Was blieb unklar — wo hättet ihr mehr Zeit oder ein anderes Beispiel gebraucht?
Was hat gefehlt? Welche Frage aus eurem Alltag ist offen geblieben?
Tempo — zu schnell, zu langsam, und an welcher Stelle?

Der beste erste Schritt am Montag: ein Repo agent-ready machen — nicht zehn.

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 10 · v0.11.5