knowledge-transfer

Was macht knowledge-transfer?

Projektwissen zwischen Kollegen übertragen: ein kurzes, nicht-technisches Onboarding-Dokument plus die gesammelten KI-Erinnerungen des Projekts, verpackt im Projekt-Repository, damit der Neue orientiert startet und sein KI-Assistent informiert ist.

Verwendung

Claude Code Standalone-Skill:

/knowledge-transfer            # Auto-Erkennung (siehe unten)
/knowledge-transfer export     # Scheidender Kollege: Übergabepaket erstellen
/knowledge-transfer import     # Neuer Kollege: Erinnerungen verifizieren + installieren, Dokument lesen

Claude Code Plugin-Installation:

/knowledge-transfer:knowledge-transfer
/knowledge-transfer:knowledge-transfer export
/knowledge-transfer:knowledge-transfer import

Codex oder ein anderer Agent, der SKILL.md liest:

$knowledge-transfer            # Auto-Erkennung
$knowledge-transfer export     # Scheidender Kollege
$knowledge-transfer import     # Neuer Kollege

Moduserkennung (ohne Argument)

1. Wenn handover/manifest.json im Projektstamm existiert → Importmodus ankündigen.
2. Ansonsten → Exportmodus ankündigen.

Den erkannten Modus in einer Zeile angeben und fortfahren. Der Benutzer kann jederzeit überschreiben.

Verträge

Lesen Sie diese, bevor Sie etwas erstellen:

• references/package-format.md — Paketstruktur und Manifest-Schema
• references/privacy-filter.md — Was exportiert werden darf und was nicht
• references/onboarding-template.md — Struktur, Ton und Länge des Dokuments
• references/agent-memory.md — Wie Erinnerungen in Claude, Codex oder einem anderen Agenten gefunden und installiert werden

---

Exportphase

Wird vom scheidenden Kollegen im Projektstamm ausgeführt.

1. Projekt analysieren

• README lesen, Agenten-Richtliniendateien (CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules/, usw., falls vorhanden), die übergeordnete Struktur, Einstiegspunkte und Hauptkonfigurationsdateien. Für große Codebasen Unteragenten verwenden, anstatt alles inline zu lesen.
• Identifizieren: Was das Projekt tut, die 3–7 Hauptkomponenten und 2–3 durchgängige logische Abläufe, die beschrieben werden sollten.
• Die dominante Sprache des Projekts erkennen (README, Dokumentation, kürzliche Commit-Nachrichten); das Onboarding-Dokument wird in dieser Sprache verfasst. Unklar oder gemischt → Englisch.

2. Erinnerungen lesen

• Die projektbezogenen Erinnerungen des aktuellen Agenten mit Hilfe von references/agent-memory.md lokalisieren.
• Nur Erinnerungen lesen, die auf dieses Projekt oder Repository beschränkt sind. Keine globalen Benutzereinstellungen oder nicht projektbezogene Verläufe exportieren.
• Kein Speicherverzeichnis oder keine Erinnerungen → nur mit dem Dokument fortfahren, memories: {"exported": 0, "excluded": 0} im Manifest setzen und dem Benutzer mitteilen, dass das Paket keine Erinnerungen enthält.

3. Erinnerungen filtern

references/privacy-filter.md streng auf jede Erinnerung anwenden. Die portablen Versionen (umgeschrieben, neutral) und die Ausschlussliste pro Erinnerung mit Gründen erstellen.

4. Paket schreiben

• Wenn handover/ bereits existiert, STOPPEN und vor dem Überschreiben nachfragen.
• handover/ONBOARDING.md gemäß references/onboarding-template.md schreiben.
• Jede beibehaltene Erinnerung als handover/memories/<slug>.md im portablen Format schreiben.
• handover/manifest.json gemäß Schema schreiben (Commit-SHA von git rev-parse HEAD; commit weglassen, wenn kein Git-Repo; author weglassen, wenn die Git-Konfiguration keinen Namen enthält).

5. Abschluss-Checkliste — vor Fertigstellung prüfen

• Das gesamte handover/-Verzeichnis mit grep nach Namen, E-Mail-Adressen und Benutzernamen des Kollegen durchsuchen: null Treffer.
• Keine Erinnerung vom Typ user in handover/memories/.
• ONBOARDING.md ist 600–1000 Wörter (wc -w) und enthält die sechs Vorlagenabschnitte.
• Jede in einer exportierten Erinnerung zitierte Datei / jeder zitierte Pfad existiert im Projekt.
• manifest.json wird geparst und die Zählungen stimmen mit den tatsächlichen Dateien überein.

Dem Benutzer melden: Paketinhalt, Ausschlussliste mit Gründen und vorschlagen, handover/ zum Repository zu committen. Ohne Nachfrage nicht committen.

---

Importphase

Wird vom neuen Kollegen nach dem Klonen im Projektstamm ausgeführt.

1. Paket lesen

• handover/manifest.json, handover/ONBOARDING.md und jede Datei in handover/memories/ lesen.
• handover/ fehlt → anhalten und erklären, dass der scheidende Kollege zuerst /knowledge-transfer export ausführen und das Ergebnis committen muss.
• manifest.version unbekannt → anhalten und mitteilen, dass das Skill zu alt für dieses Paket ist.

2. Jede Erinnerung gegen den aktuellen Code prüfen

• Wenn das Repo ein Git-Repo ist und das Manifest commit enthält, git diff --stat <commit>..HEAD ausführen, um zu sehen, welche Bereiche sich seit dem Export geändert haben.
• Für jede Erinnerung prüfen, ob die Dateien, Pfade und Bezeichner, die sie zitiert, noch existieren (Glob/Grep, keine Annahme). Klassifizieren:
  • gültig — alles stimmt → wie vorhanden installieren;
  • veraltet, offensichtliche Korrektur — z.B. eine zitierte Datei wurde umbenannt und der neue Pfad ist eindeutig (git log --follow oder ein eindeutiger Suchergebnis-Treffer) → Erinnerungstext aktualisieren, dann installieren;
  • veraltet, keine offensichtliche Korrektur — verwerfen, den einzeiligen Grund notieren.

3. Installieren

• Jede akzeptierte Erinnerung über den aktuellen Agentenspeichermechanismus installieren (siehe references/agent-memory.md), den portablen Inhalt intakt lassen und nur den Speicher-Wrapper/Index anpassen, wenn der Zielagent dies erfordert.
• Slug-Kollision mit einer vorhandenen Erinnerung: NICHT überschreiben. Die Kollision melden und den Benutzer fragen, welche behalten werden soll.
• Wenn der Zielspeicher eine Indexdatei hat, pro installierter Erinnerung eine Indexzeile anhängen (falls nicht vorhanden, erstellen). Wenn der aktuelle Agent direkte Speicherschreibvorgänge verbietet, stattdessen das genehmigte Memory-Upgrade-Artefakt erstellen oder präsentieren.

4. Bericht

Dem Benutzer in dieser Reihenfolge präsentieren:

1. Den vollständigen Inhalt von ONBOARDING.md (er ist absichtlich kurz).
2. Die Importzusammenfassung: installiert / aktualisiert / verworfen, jeweils mit einer Begründungszeile.
3. Eine Schlussbemerkung: Technische Fragen können nun auf die importierten Erinnerungen zurückgreifen.

---

Randfälle

Situation	Verhalten
Keine Erinnerungen beim Export	Nur Dokumentenpaket; dies explizit erwähnen.
Das Projekt ist kein Git-Repo	Manifest ohne commit; Importprüfung fällt auf reine Existenzprüfungen zurück.
handover/ existiert beim Export	Vor Überschreiben nachfragen.
handover/ fehlt beim Import	Mit Anweisungen für den scheidenden Kollegen anhalten.
Slug-Kollision beim Import	Niemals überschreiben; anzeigen und nachfragen.
Unbekannte manifest.version	Anhalten; den Benutzer bitten, das Skill zu aktualisieren.