CGS IT Solutions GmbH — Claude Code Training · Modul 10 · v0.1.0

Modul 10

Team-Workflows & Konsolidierung

Tag 3 · ca. 60 Minuten · Abschlussmodul

Lernziel Modul 10

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

Drei Verben, eine Grundthese: Agenten-Konfiguration ist Code — und wird behandelt wie Code.

Inhalt

Konfiguration im Repo

Skills, Commands, Rules & Workflow-Definitionen versioniert

Plugins als Bündel

Ein Paket statt zwölf Copy-Paste-Dateien

Prompt- & Workflow-Bibliotheken

Wiederverwendbar statt jedes Mal neu formuliert

Weiterentwicklung als Team-Asset

Jede Lehre landet im Repo, nicht im Kopf

Konsolidierung über Teams

Was vereinheitlichen, was bewusst lokal lassen

cgsit-claude-scaffold

Ein fertiges Startpaket als Beispiel

CLAUDE.md Pitfalls im Team

Die sozialen, nicht die technischen

Slop Creep

Qualitätsverfall durch ungeprüften AI-Output

Cognitive Debt

Kompetenzverlust durch Delegation

Respectful PRs

Tempo beim Autor, Kosten beim Reviewer

Skills, Commands, Rules & Workflow-Definitionen im Repo

Die Frage, an der Rollouts scheitern

Nach ein paar Wochen hat jede:r im Team eigene Skills, eigene Commands, eigene Regeln gebaut. Die Frage ist nur: wo liegen sie?

Auf dem Einzelrechner

Jede:r hat einen anderen Agenten. Ergebnisse sind nicht vergleichbar, Verbesserungen nicht teilbar.

Wer geht, nimmt sein Setup mit. Wer neu kommt, fängt bei null an.

Kein Review, keine Historie, kein „warum steht das da".

Im Repo

Alle arbeiten mit derselben Konfiguration — automatisch, beim git pull.

Änderungen laufen durch Review wie jede andere Änderung.

Die Historie erklärt die Regeln: git log statt Flurfunk.

Agenten-Konfiguration, die nicht im Repo liegt, ist Privatwissen mit Werkzeugcharakter — genau das, was wir seit Modul 1 vermeiden wollen.

Was geteilt wird — und was nicht

ArtefaktEbeneWarum
CLAUDE.mdRepo, versioniertProjektwissen — für alle gleich
.claude/rules/Repo, versioniertKonventionen sind Team-Entscheidungen
.claude/skills/Repo, versioniertWiederholbare Abläufe des Projekts
.claude/commands/Repo, versioniertEinstiegspunkte in die Abläufe
.claude/agents/Repo, versioniertReview-Standards des Teams
Permissions (Team-Teil)Repo, versioniertVerbote sind nicht verhandelbar (Modul 9)
Permissions (persönlicher Teil)lokal, .gitignoreindividuelle Bequemlichkeit
Zugänge, Tokens, Keysnie im RepoSecrets bleiben Secrets
Persönliche Notizen, Scratchlokalinteressiert das Team nicht
Faustregel: Würde ein neuer Kollege es brauchen? Dann ins Repo. Ist es Geschmack oder Geheimnis? Dann lokal.

Beleg aus einem echten Repo

Das Projekt cgsit-finance trägt seine gesamte Agenten-Konfiguration im Repository:


.claude/
  rules/      java-conventions.md  angular-conventions.md  api-rules.md
              testing-rules.md     database-rules.md       migration-safety.md
              quarkus-backend.md   money-fx.md             ui-theming.md
  skills/     build/  test/  commit/  ship/  deploy/  tag/  rfcs/
              test-generator/  architecture-reviewer/  ux-reviewer/
              doc-initializer/
  agents/     code-reviewer.md  researcher.md  test-engineer.md
  commands/   create-rfc.md  plan-feature.md  init-docs.md  review.md
  settings.json
Alles davon ist versioniert, reviewbar und per PR änderbar. Nichts davon liegt auf einem einzelnen Laptop.

Weiterentwicklung per PR — wie Code

1Auslöser. Der Agent macht denselben Fehler zum zweiten Mal, oder ein Review deckt eine ungeschriebene Konvention auf.
2Branch. Wie bei jeder Änderung — nicht direkt auf main.
3Änderung klein halten. Eine Regel, ein Skill-Schritt. Nicht „Rules aufgeräumt" mit 400 geänderten Zeilen.
Review durch einen Menschen. Eine Regel ist eine Team-Entscheidung, kein Vorschlag. Gate
5Merge. Ab jetzt arbeiten alle damit — ohne dass jemand etwas installieren muss.
Der PR ist die Stelle, an der aus „mir ist aufgefallen" ein Team-Asset wird.

Jede Regel hat einen Auslöser

In einem gepflegten Repo erzählt die Historie der Konfiguration, warum das Team so arbeitet, wie es arbeitet:


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)
Muster Jeder dieser Commits ist ein Fehlschlag, der nicht wieder passieren soll. Die Konfiguration wächst nicht durch Planung, sondern durch Lehren. Wer keine Historie hat, lernt jede Lehre mehrfach.

Plugins als teilbares Bündel

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 muss achtmal nachgezogen werden — wird sie nicht.

Bündeln

Ein Plugin fasst zusammengehörige Skills, Commands, Agents und Hooks zu einem installierbaren Paket.

Eine Quelle, eine Version, ein Update-Weg.

Mechanik und Verteilweg von Plugins (Paketformat, Marketplace-Anbindung, Installationsbefehle) sind versionsabhängig und bewusst nicht auf dieser Folie. Vor dem Kurs gegen die offizielle Dokumentation prüfen und live zeigen. In cgsit-finance sind aktuell keine Plugins im Einsatz — das Repo teilt über .claude/ und das Scaffold. — geprüft am 2026-07-21

Reusable Prompt- & Workflow-Bibliotheken

Der zweite wiederverwendbare Rohstoff sind die Formulierungen selbst: Prompts, die sich bewährt haben, und Abläufe, die reproduzierbar zum Ziel führen.

Prompt-Bibliothek

Bewährte Prompts als Datei im Repo — nicht als Screenshot im Chat.

Workflow-Definitionen

Der Phasen-Ablauf aus Modul 5 als Skill, nicht als Wiki-Seite.

Templates

RFC-, Review- und Handoff-Vorlagen mit fixer Struktur.

Auffindbarkeit

Ein Ort, klare Namen. Was niemand findet, benutzt niemand.

Der Unterschied zwischen Bibliothek und Friedhof ist die Pflege: Was seit einem Jahr niemand benutzt hat, wird gelöscht — nicht archiviert.

cgsit-claude-scaffold als Beispiel

Ein Startpaket für neue Projekte: die Ablagestruktur, die Basis-Rules, die Standard-Skills und die Doku-Templates — fertig, aber leer.


cgsit-claude-scaffold/
  CLAUDE.md            schlank: Konventionen + Verweise auf docs/
  .claude/
    rules/             java-conventions, api-rules, testing-rules, database-rules
    agents/            code-reviewer, researcher, test-engineer
    skills/            rfcs, commit, tag, test-generator, architecture-reviewer,
                       doc-initializer
    commands/          create-rfc, plan-feature, init-docs, review
    settings.json      Permissions / Allowlists
  docs/                product_overview, architecture, tech_stack, testing,
                       development_guide, rfcs/TEMPLATE.md
  tasks/lessons.md     Korrekturen aus vorherigen Sessions
Das Scaffold ist die gemeinsame Grundlinie: jedes neue Projekt startet auf demselben Stand statt bei null.

Wie das Scaffold benutzt wird

1Übernehmen. .claude/, docs/, tasks/ und CLAUDE.md ins neue Projekt kopieren.
2Füllen. Der Agent interviewt das Team und füllt die Doku-Templates — im Scaffold als Command /init-docs hinterlegt.
3Anpassen. Rules und Skills auf den Stack des Projekts ziehen. Das Scaffold ist ein Startpunkt, kein Gesetz.
4Zurückspielen. Was sich in mehreren Projekten bewährt, wandert per PR ins Scaffold zurück.
Schritt 4 ist der, der meistens fehlt. Ohne Rückfluss ist das Scaffold nach einem Jahr der schlechteste Stand aller Projekte.

Konsolidierung über mehrere Teams

Was vereinheitlichen — was bewusst lokal lassen

Vereinheitlichen

Sicherheit & Compliance: Verbote, Secrets-Handhabung, was nie automatisch laufen darf (Modul 9).

Struktur: wo Rules, Skills und Doku liegen — damit man sich in fremden Repos zurechtfindet.

Qualitäts-Gates: Review-Pflicht, grüne CI vor Merge.

Lokal lassen

Stack-Konventionen: Java-Regeln helfen dem Frontend-Team nicht.

Domänenwissen: gehört zum Produkt, nicht zur Organisation.

Arbeitsstil im Team: Branch-Namen, Commit-Format, Ticket-Anbindung.

Konsolidieren heißt weniger vereinheitlichen als man denkt. Erzwungene Einheitlichkeit erzeugt Regeln, die alle umgehen — und damit eine Konfiguration, der niemand mehr glaubt.

Ein gangbarer Konsolidierungs-Pfad

1Inventur. Was existiert in welchem Team? Meist überraschend viel — und dreimal dasselbe.
2Duplikate zusammenführen. Drei ähnliche Commit-Skills werden einer. Der beste gewinnt, nicht der älteste.
3Grundlinie definieren. Struktur, Sicherheitsregeln, Gates — ins Scaffold bzw. ins gemeinsame Bündel.
4Eigentümerschaft klären. Ein Name pro geteiltem Artefakt. Ohne Eigentümer verrottet es.
5Rückfluss etablieren. Beitrag per PR, Review durch die Eigentümer, sichtbare Historie.
Ohne Schritt 4 ist die geteilte Konfiguration nach einem halben Jahr ein Altbestand, den niemand anfasst.

CLAUDE.md Pitfalls im Team

Modul 7 hatte die technischen Fallstricke — zu lang, zu vage, veraltet. Hier kommen die sozialen:

Jeder schreibt rein, keiner löscht

Die Datei wächst monoton. Nach einem Jahr liest sie niemand mehr zu Ende — der Agent auch nicht wirklich.

Regeln, die nie jemand entschieden hat

Ein Satz, den einer nachts eingetragen hat, gilt seitdem als Standard. Gefragt wurde niemand.

Konventionen, die nur einer lebt

Steht drin, macht keiner. Der Agent hält sich daran — und produziert Code, der zum Rest nicht passt.

Austragungsort für Grundsatzdiskussionen

Der Streit über Architekturstil wird im PR auf die Datei ausgelagert, statt einmal entschieden zu werden.

Widersprüche zwischen den Ebenen

Repo sagt A, Team-Grundlinie sagt B. Der Agent folgt einem von beiden — und niemand weiß vorher, welchem.

Wunschzettel statt Beschreibung

Es steht drin, wie gearbeitet werden sollte, nicht wie gearbeitet wird. Der Agent glaubt es.

Gegenmittel — die Datei behandeln wie Code

Jede Regel braucht einen Auslöser. Kein „wäre gut", sondern ein konkreter Fall. Idealerweise im Commit erklärt.
Löschen ist ein legitimer PR. Regeln, die niemand lebt, gehören raus — nicht weichgespült, sondern gelöscht.
Entscheidungen woanders treffen. Grundsatzfragen klärt das Team, nicht der PR-Kommentar. In die Datei kommt das Ergebnis.
Ebenen sauber trennen. Organisationsweite Grundlinie ≠ Repo-Wissen. Bei Konflikt gewinnt das Spezifischere — und das muss man wissen.
Regelmäßig durchgehen. Ein fixer Termin pro Quartal reicht. Ohne Termin passiert es nie.
Eine CLAUDE.md, die alles enthält, steuert nichts. Weglassen ist die eigentliche Arbeit.

Der Preis: was Teams langfristig verlieren können

„Slop Creep"

Schleichender Qualitätsverfall, wenn AI-Output ungeprüft ins Repo sickert. Kein einzelner Fehler — eine Drift.

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

Niemand hat sie geschrieben, niemand liest sie — aber alle vertrauen ihr.

Wachsende Uneinheitlichkeit

Fünf Stile im selben Modul, weil jeder Lauf plausibel anders entschieden hat.

Das Tückische: jeder einzelne Beitrag sieht in Ordnung aus. Sichtbar wird es erst in der Summe — und dann ist es teuer.

Gegenmittel gegen Slop Creep

1Review bleibt Pflicht. Auch — gerade — wenn der Diff schön aussieht. Schönheit ist bei generiertem Code kein Signal.
Gates statt Vorsätze. Build, Tests, Lint, Security-Scan in der CI (Modul 9). Was nicht automatisch prüft, prüft auf Dauer niemand.
3Tests gegen die Anforderung prüfen, nicht gegen die Implementierung. Ein Test, der nur bestätigt, was der Code tut, ist Dekoration.
4Duplikate aktiv suchen. „Gibt es das schon?" ist eine gute Frage an den Agenten — vor der Implementierung, nicht danach.
Der Mensch unterschreibt den Commit. Wer merged, haftet inhaltlich — unabhängig davon, wer die Zeilen getippt hat.
„Das hat der Agent so gemacht" ist keine Begründung. Es ist ein Eingeständnis, dass niemand hingesehen hat.

„Cognitive Debt"

Kompetenzverlust durch Delegation. Wer nur noch abnimmt, versteht das System irgendwann nicht mehr.

Mehr delegieren
Weniger selbst verstehen
Abnahme wird oberflächlicher
Fehler fallen später auf
… also noch mehr delegieren
Wer das System nicht mehr versteht, kann auch nicht mehr beurteilen, ob die Abnahme richtig war. Das ist die gefährlichste Rückkopplung im ganzen Kurs.

Gegenmittel — ehrlich betrachtet

Manches bewusst selbst machen

Nicht aus Nostalgie: Verständnis entsteht beim Tun. Kandidaten sind die Kernbereiche, für die man geradesteht.

Reviews ernst nehmen

Ein gelesener Diff ist Lernen. Ein durchgewinkter Diff ist Zinszahlung auf Schulden.

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 PR nicht erklären kann, hat ihn nicht verstanden — unabhängig davon, ob er funktioniert.

Kein Gegenmittel ist kostenlos. Alle vier kosten genau die Zeit, die das Werkzeug eingespart hat — ein Teil des Gewinns muss zurückinvestiert werden.

Respectful PRs & Context Switching

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 darf nicht zu Lasten des Teams gehen. Sonst ist er keiner — er ist nur verschoben.

Was einen PR respektvoll macht

1Klein. Ein Thema pro PR. Was in 20 Minuten entstanden ist, darf trotzdem in fünf PRs zerlegt werden.
2Atomar. Refactoring und Feature nie im selben PR — sonst ist der eigentliche Diff im Rauschen unsichtbar (Modul 5).
3Vertikal geschnitten. Eine dünne, lauffähige Scheibe statt „alle Repositories, aber noch nichts läuft" (Modul 5).
4Erklärt. Beschreibung vom Autor, nicht vom Agenten: warum so, welche Alternative verworfen, wo bitte genau hinsehen.
5Vorgeprüft. Tests grün, Selbstreview gelaufen. Der Reviewer ist nicht die erste Instanz, die den Diff liest.
Vertical Slicing und Atomic PRs aus Modul 5 sind nicht nur Technik — sie sind Teamhygiene. Mit einem Agenten werden sie zur Pflicht.

Übung 10 — Workflow-Definition als PR

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 nur mit Daumen hoch.

Verifizierbares Ergebnis: Der PR liegt vor, hat ein Review mit mindestens einem inhaltlichen Kommentar durchlaufen und ist gemergt — oder mit Begründung abgelehnt.

Dauer ca. 25 Minuten · Partnerarbeit

Diskussionsrunde — wie ist es bei euch?

Moderierte Runde. Ihr kommt aus unterschiedlichen Unternehmen — das ist der wertvollste Teil dieses Moduls.

Stand

Wer arbeitet schon agentisch — einzelne, ein Team, die ganze Abteilung?

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

Habt ihr Anzeichen gesehen? Woran habt ihr es gemerkt?

Cognitive Debt

Wo würdet ihr bewusst nicht delegieren? Wie haltet ihr es mit Junioren?

Reviews

Ist eure Review-Kapazität schon der Engpass? Was habt ihr dagegen versucht?

Kursabschluss

Zehn Module, zehn Lernziele — Teil 1

ModulDas könnt ihr jetzt
1 Grundlagen LLM & AgentsVerstehen, warum LLMs stateless und nicht-deterministisch sind, in einer Agent-Schleife arbeiten — und daraus die typischen Einstiegsfehler ableiten.
2 Claude-Code-BaukastenJedes Primitiv benennen, sein Einsatzgebiet erklären und das richtige Werkzeug für den Zweck wählen.
3 Prompting & ContextPrompts strukturieren, Context bewusst kuratieren, Qualitätsverfall bei vollem Fenster erkennen und vermeiden.
4 Praktische ArbeitDen täglichen iterativen Zyklus beherrschen — Review-Loops, Approvals, Session-Management.
5 Agentic SDLCDen Phasen-Workflow von Analyse bis Deploy mit Gates und Artefakten aufsetzen und durchführen.

Zehn Module, zehn Lernziele — Teil 2

ModulDas könnt ihr jetzt
6 Workflow-FrameworksQRSPI, BMAD und OpenSpec nach Philosophie einordnen und begründet eines für einen Projekttyp wählen.
7 Codebase & OrganisationEine Codebase agent-ready machen — navigierbar, verifizierbar, mit sauberen Handoff-Artefakten.
8 Skills, Tools & InfrastrukturSkills, Rules, Commands und Hooks pro Workflow-Phase bauen und das Git-Handling weitgehend autonom gestalten.
9 Testing & AI SecurityTests und Security-Checks als Gates in Workflow und CI einbauen, agentische Review-Loops aufsetzen.
10 Team-WorkflowsSkills, Commands und Rules im Team versionieren, per PR weiterentwickeln und über mehrere Teams konsolidieren.
Die Kursklammer: den Agenten steuern statt ihm zu folgen. Aufgaben zuschneiden, Zwischenergebnisse prüfen, Fehlläufe erkennen und korrigieren.

Ausblick: das Werkzeug ändert sich

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-IDs, Slash-Commands, Plugin-Mechanik, Preise.

Alles, was in diesem Kurs in einem gestempelten Kasten stand.

Konzepte lehren, Details stempeln — das war die Regel für diese Folien und ist die Regel für eure eigene Doku.
Aktuelle Informationen: die offizielle Dokumentation unter docs.claude.com, das CHANGELOG der CLI, claude --help und /help in der Session. Vor jeder Weitergabe an Kolleg:innen gegenprüfen — nicht aus der Erinnerung zitieren. — geprüft am 2026-07-21

Danke — und euer Feedback

Drei Tage, zehn Module, ein Beispielprojekt. Bevor ihr geht:

Was war nützlich?

Was nehmt ihr Montag konkret mit in euer Projekt?

Was blieb unklar?

Wo würdet ihr euch mehr Zeit oder ein anderes Beispiel wünschen?

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 alle. Klein anfangen, sichtbar machen, dann teilen.

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

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.1.0