🅱️ Lab-Guide Track B: Skills ändern – Branch, PR, Review

Für: den Restricted-Kreis (Mathias H., Onur Kabadayi, Chris) · Dauer: ca. 60 Minuten

Ziel: Jede Skill-Änderung läuft ab jetzt über Branch → Pull Request → Review – und bei jeder Änderung wird der Versionsstempel (VERSION + Datenquelle) im Skill-Header mitgepflegt. So erreicht jede Verbesserung alle Nutzer, und veraltete Kopien sind sofort erkennbar.

---

🔑 Voraussetzungen (vorab prüfen)

• Schreibzugriff auf das Restricted-Repo in der Org medumi (Rolle „Write" oder höher)
• GitHub CLI angemeldet: gh auth status zeigt deinen Account
• Git-Identität gesetzt (Name + Firmen-E-Mail): git config user.name / git config user.email

Fehlt etwas? Claude hilft: „Prüfe meinen GitHub-Zugang (gh auth status) und meine Git-Identität und führe mich durch die Einrichtung."

Die drei festen Regeln für Skill-Änderungen:

1. 🌿 Nie direkt auf main – jede Änderung startet auf einem Branch und geht per PR rein.
2. 🏷️ Jede Änderung setzt VERSION auf das heutige Datum – ohne Ausnahme.
3. 📦 Kein Export als ZIP – auch nicht „nur schnell für eine Person". Der Link ist der Weg.

---

Phase 1 – Branch erstellen (10 Min)

Namenskonvention: skill/<skill-name>-<jjjjmmtt>-<kurzbeschreibung> Beispiel: skill/kongressplanung-20260817-neue-datenquelle

In Claude Code:

Ich möchte den Skill "<skill-name>" im Restricted-Repo (Org medumi) ändern.
Hole den aktuellen Stand von main und erstelle einen Branch nach dem Muster
skill/<skill-name>-<heutiges Datum>-<kurzbeschreibung>. Beschreibung: <was du vorhast>.

✅ Geschafft, wenn du auf dem neuen Branch bist und main frisch gepullt ist.

---

Phase 2 – Ändern + Header pflegen (15 Min)

Mach deine inhaltliche Änderung – und immer zusammen damit den Header:

---
name: kongressplanung
VERSION: 2026-08-17          ← auf HEUTE setzen, bei jeder Änderung
Datenquelle: <fileId>        ← die Datei-ID, aus der der Skill liest
---

🧨 Die Lektion aus der „FALSCH!!!"-Tabelle: Der Skill liest Datei-IDs, keine Titel. Eine alte Tabelle im Namen als „ALT" zu markieren, erreicht keinen einzigen Skill. Wenn die Datenquelle wechselt, muss die neue fileId in den Header – und per PR auf main. Erst dann ist die Änderung für alle wirksam.

In Claude Code:

Führe im Skill "<skill-name>" folgende Änderung durch: <deine Änderung>.
Setze dabei im Skill-Header VERSION auf das heutige Datum und prüfe,
ob die Datenquelle-Zeile noch auf die richtige fileId zeigt.
Zeig mir am Ende den Diff.

✅ Geschafft, wenn der Diff deine Änderung UND den aktualisierten Header zeigt.

---

Phase 3 – Pull Request erstellen (10 Min)

In Claude Code:

Committe meine Änderungen mit einer aussagekräftigen Message, pushe den Branch
und erstelle einen Pull Request gegen main. Nutze diese PR-Beschreibung:

## Was
<eine Zeile: was ändert sich>

## Warum
<Anlass, z. B. gemeldeter Fehler oder neue Datenquelle>

## Datenquelle geändert?
<ja: alte → neue fileId / nein>

## Getestet
<wie hast du geprüft, dass der Skill noch läuft>

Danach: Review anfordern – eine zweite Person aus dem Restricted-Kreis als Reviewer eintragen (bei GitHub im PR rechts unter „Reviewers", oder kurz in Slack anpingen).

✅ Geschafft, wenn der PR offen ist und ein Reviewer angefragt wurde.

---

Phase 4 – Review & Merge (15 Min)

Übung im Workshop: Tauscht die Rollen – jeder reviewt den PR eines anderen.

Review-Checkliste (als Reviewer):

• VERSION steht auf dem Datum der Änderung
• Datenquelle zeigt auf die richtige, aktuelle fileId (im Zweifel: Datei öffnen und prüfen!)
• Keine Tokens, Passwörter oder personenbezogenen Daten im Diff
• Die Änderung tut, was die PR-Beschreibung sagt (Stichprobe/Testlauf)
• Nichts Unbeabsichtigtes im Diff (z. B. lokale Pfade, Debug-Reste)

Alles grün? → Approve → Merge (Squash empfohlen: eine Änderung = ein Commit auf main). Danach den Branch löschen (GitHub bietet es nach dem Merge an).

✅ Geschafft, wenn dein PR gemerged ist und main deinen neuen Versionsstempel trägt.

---

Phase 5 – Nach dem Merge: die Änderung ankommen lassen (10 Min)

1. main ist jetzt die Wahrheit. Wer den Skill per GitHub bezieht, bekommt beim nächsten Aktualisieren automatisch deinen Stand.
2. Org-geteilte Version aktualisieren: Wenn der Skill auch als org-geteilter Skill in Claude bzw. (in Kürze) über die Server-Anwendung verteilt wird, dort die neue Version veröffentlichen – sonst laufen die Kanäle auseinander. [Prozess/Verantwortlichen eintragen]
3. Bei relevanten Änderungen (neue Datenquelle, geändertes Verhalten): kurze Notiz in #ai_prozessverbesserungen_und_automatisierungen – eine Zeile reicht: „ aktualisiert auf VERSION 2026-08-17: . Bitte einmal aktualisieren."

---

Abschluss-Check

• Branch nach Konvention erstellt
• Änderung + Header (VERSION, Datenquelle) in einem Commit
• PR mit vollständiger Beschreibung erstellt
• Fremden PR nach Checkliste reviewt
• Merge + Branch aufgeräumt + Ansage (falls nötig)

Merksatz für den Kreis: Kein Merge ohne Stempel. Kein Stempel ohne Merge.