collab-proof
von alirezarezvanicollab-proof hilft Claude Code-Nutzern, KI-gestützte Coding-Sessions in belastbare Kollaborationsnachweise zu überführen. Dabei trennt der Skill Entwicklerentscheidungen, Beiträge von Claude, verworfene Alternativen und Nachweisartefakte für Retrospektiven, Portfolios, Recruiting und Knowledge Capture.
Dieser Skill erreicht 78/100 Punkte und ist damit ein solider Kandidat für Verzeichnisnutzer, die nach Coding-Sessions strukturierte Nachweise zur Zusammenarbeit von Mensch und KI benötigen. Das Repository bietet echte Workflow-Substanz, klare Trigger-Phrasen, Entscheidungsraster und unterstützende Begründungen. Die Nutzung wird jedoch etwas dadurch eingeschränkt, dass Installationshinweise fehlen und der Skill auf manuelle Prompt-Ausführung statt auf mitgelieferte Scripts setzt.
- Sehr gut auslösbar: Das Frontmatter nennt explizite Trigger wie `/collab-proof`, session retrospective, AI contribution analysis, collaboration evidence und „what did Claude do“.
- Operativ gehaltvoll: SKILL.md enthält einen Workflow zur Signalerkennung, beginnend mit `git log --oneline -10` und `git diff --stat HEAD~3..HEAD`, dazu HIGH/MEDIUM-Klassifizierungsregeln und Overrides für Bugfixes.
- Guter Kontext für die Installationsentscheidung: Vier Referenzdateien erklären die Gründe hinter dem Skill für Portfolio, Session-Dokumentation, ADR und manipulationsresistente Nachweise.
- Im Skill-Verzeichnis gibt es keinen Installationsbefehl und kein README. Nutzerinnen und Nutzer des Verzeichnisses brauchen daher möglicherweise Vorwissen, um Claude skills aus diesem Repo zu installieren.
- Der Workflow wirkt prompt-nativ und enthält keine Scripts oder Automatisierung. Agents müssen git-Befehle manuell ausführen, Nachweise klassifizieren und Artefakte erzeugen, was zu Schwankungen führen kann.
Überblick über den collab-proof skill
Wofür collab-proof gedacht ist
collab-proof ist ein Claude skill, der eine KI-unterstützte Coding-Session in verwertbare Nachweise für Zusammenarbeit verwandelt: was entschieden wurde, welchen Beitrag Claude geleistet hat, warum Alternativen verworfen wurden und welche Artefakte das belegen. Der collab-proof skill eignet sich besonders für Entwicklerinnen und Entwickler, die Claude Code nutzen und bessere Session-Retrospektiven, Portfolio-Nachweise, Belege für Bewerbungsprozesse oder dauerhaft nutzbare Knowledge Capture nach relevanter Engineering-Arbeit erstellen möchten.
Statt nur eine generische Zusammenfassung zu erzeugen, arbeitet der collab-proof skill mit einem mehrstufigen Workflow: Er erkennt, wie aussagekräftig die Session ist, klassifiziert die Arbeitsabsicht, bewertet den Kollaborationsrahmen und entscheidet anschließend, welche Dokumentationsartefakte sich lohnen.
Für welche Nutzer und Aufgaben collab-proof am besten passt
Nutze collab-proof, wenn du Fragen beantworten musst wie:
- „Was hat Claude hier tatsächlich beigetragen?“
- „Welche Entscheidungen kamen von mir und welche wurden von der KI vorgeschlagen?“
- „Kann ich diese Arbeit in einem Portfolio zeigen, ohne zu viel zu behaupten?“
- „Welche Begründungen gingen verloren, wenn das Chat-Transkript verschwände?“
Besonders nützlich ist der Skill nach Bug-Diagnosen, Architekturentscheidungen, Feature-Implementierungen, Refactorings und Diskussionen über Design-Tradeoffs. Weniger sinnvoll ist er bei sehr kleinen Änderungen, reinen Formatierungs-Commits, Dependency-Bumps oder Sessions, in denen keine nennenswerte Begründung stattgefunden hat.
Was collab-proof unterscheidet
Der wichtigste Unterschied ist die kalibrierte Zuschreibung von Beiträgen. collab-proof fasst nicht nur zusammen, „was sich geändert hat“, sondern trennt Entwicklerintention, Vorschläge von Claude, übernommene Ideen, verworfene Alternativen und Root-Cause-Überlegungen. Das Quellmaterial enthält außerdem Hinweise für manipulationserschwerende Nachweise mit Git notes und SHA-256-Hashes. Das ist wichtig, wenn die Dokumentation einem bestimmten Commit zugeordnet werden soll.
Für Knowledge Capture ist collab-proof am stärksten, wenn die Session Entscheidungen, Diagnosen, Alternativen oder Begründungen enthält, die aus dem finalen Diff allein nicht ersichtlich wären.
So nutzt du den collab-proof skill
Installationskontext für collab-proof
Installiere den Skill aus dem Repository mit:
npx skills add alirezarezvani/claude-skills --skill collab-proof
Der Skill liegt unter:
engineering/collab-proof/skills/collab-proof
Sieh dir nach der Installation zuerst SKILL.md an und lies danach die Referenzdateien, die das Evidenzmodell erklären:
references/ai-collaboration-evidence.mdreferences/developer-portfolio-proof.mdreferences/session-documentation-patterns.mdreferences/tamper-evident-proof.md
Im Skill-Ordner gibt es keine Helper-Skripte. Rechne daher mit einem promptbasierten Workflow statt mit einem Ein-Befehl-Reportgenerator.
Welche Eingaben der Skill braucht
Für eine gute Nutzung von collab-proof solltest du mehr liefern als eine vage Anfrage. Der Skill funktioniert am besten mit:
- dem aktuellen Repository-Stand
- aktuellen Commits oder dem relevanten Diff
- einer kurzen Beschreibung des Session-Ziels
- wichtigen Ausschnitten aus der Konversation
- dem Bug, Feature oder der Entscheidung, die dokumentiert werden soll
- der Information, ob die Ausgabe für dich selbst, einen PR, ein Portfolio oder als Bewerbungsnachweis gedacht ist
Der Upstream-Workflow weist Claude an, zuerst git log --oneline -10 und git diff --stat HEAD~3..HEAD auszuführen. Diese Befehle helfen, die Session als High-, Medium- oder Low-Signal einzustufen. Auch ein Bugfix in nur einer Datei kann High-Signal sein, wenn das Transkript Root-Cause-Diagnose und Begründung des Fixes enthält.
Starkes Prompt-Muster
Ein schwacher Prompt wäre:
„Use collab-proof on this project.“
Ein besserer Prompt wäre:
„Use collab-proof for the last session. The goal was to fix the login redirect bug. Please inspect recent commits and diff stats, classify the collaboration signal, identify root cause reasoning, separate my decisions from Claude’s suggestions, and produce portfolio-safe evidence. Emphasize why the chosen fix was better than the rejected middleware approach.“
Das funktioniert besser, weil der Skill eine konkrete Aufgabe, einen klaren Umfang, eine Zielgruppe für die Ausgabe und die zu bewahrenden Entscheidungspunkte erhält.
Empfohlener Workflow für collab-proof
Beginne direkt nach der Session mit einer fokussierten Retrospektive, solange die Begründungen noch frisch sind. Bitte Claude, zuerst das Signal-Level zu bestimmen, bevor finale Artefakte geschrieben werden. Bei einer High-Signal-Session solltest du Decision Records, Session History, ein Worklog und eine portable Proof-Ausgabe anfordern. Bei Medium-Signal kann ein knappes Worklog ausreichen. Bei Low-Signal solltest du Überdokumentation vermeiden.
Für Portfolio- oder Bewerbungszwecke solltest du um vorsichtige Formulierungen bitten. Gute Nachweise sagen eher „Claude identified X; I evaluated and chose Y because Z“ als „AI built the project“.
FAQ zum collab-proof skill
Ist collab-proof nur für Portfolios gedacht?
Nein. Portfolio-Nachweise sind ein wichtiger Anwendungsfall, aber collab-proof für Knowledge Capture ist genauso relevant. Der Skill hilft, Begründungen festzuhalten, die aus der Git-Historie verschwinden: warum ein Bug entstanden ist, warum sich ein Design geändert hat, was die KI bemerkt hat und wo der Entwickler die KI überstimmt hat.
Warum ist collab-proof besser als ein normaler Zusammenfassungs-Prompt?
Ein normaler Zusammenfassungs-Prompt komprimiert eine Session meist auf erledigte Aufgaben. Der collab-proof skill ist stärker strukturiert: Er bewertet die Stärke der Evidenz, unterscheidet menschliche und KI-Beiträge, priorisiert Entscheidungsbegründungen und behandelt nicht jede Coding-Session als gleich wichtig. Dadurch ist die Ausgabe nützlicher für Reviews, Retrospektiven und Arbeitsnachweise.
Können Anfänger diesen Skill nutzen?
Ja, aber Anfänger sollten den ersten Durchlauf einfach halten. Bitte zunächst um ein Worklog und eine Aufschlüsselung der Beiträge, bevor du vollständige Portfolio-Nachweise anforderst. Die schwierigen Teile sind nicht die Installation, sondern genug Kontext bereitzustellen und überzogene Behauptungen darüber zu vermeiden, was die KI geleistet hat.
Wann sollte ich collab-proof nicht verwenden?
Verwende collab-proof nicht für Routine-Commits ohne relevante Begründung, generierten Boilerplate-Code, kosmetische Aufräumarbeiten oder private Transkripte, die du nicht sicher zusammenfassen kannst. Nutze den Skill außerdem nicht als Ersatz für echte Tests, Code Review oder saubere Commit-Hygiene. Er dokumentiert Zusammenarbeit; er validiert keine Korrektheit.
So verbesserst du den collab-proof skill
Eingaben für collab-proof verbessern
Der häufigste Fehler ist zu wenig Kontext. Bessere Ergebnisse bekommst du, wenn du Claude das Session-Ziel, wichtige Gesprächsausschnitte, betroffene Dateien, den Commit-Bereich und die Zielgruppe nennst. Wenn die Ausgabe für Bewerbungen gedacht ist, sag das explizit. Wenn sie für interne Knowledge Capture gedacht ist, bitte um mehr technische Details und weniger Marketing-Politur.
Nützliches Eingabeformat:
- Ziel: was du erreichen wolltest
- Change set: Commits, Dateien oder Diff-Bereich
- Begründung: betrachtete und verworfene Alternativen
- Zuschreibung: was du vorgeschlagen hast, was Claude vorgeschlagen hat, was geändert wurde
- Zielgruppe: private Notizen, PR, README, Recruiter, Portfolio
Zuschreibung und Evidenzqualität feinjustieren
Bitte bei jeder wichtigen Entscheidung um kalibrierte Zuschreibung. Eine starke collab-proof-Ausgabe sollte beide Extreme vermeiden: so zu tun, als hätte der Entwickler alles allein gemacht, oder zu behaupten, Claude habe die Lösung eigenständig gebaut. Fordere Formulierungen an wie „Claude suggested“, „developer selected“, „developer rejected“, „jointly refined“ und „root cause identified from“.
Bei Bugfixes solltest du den Skill ausdrücklich bitten, Ursache, Diagnoseweg und Begründung des Fixes festzuhalten. Die BUG_FIXING-Regel des Repository behandelt einen gut erklärten Ein-Datei-Fix als hochwertigen Nachweis.
Nach der ersten Ausgabe iterieren
Übernimm den ersten generierten Nachweis nicht ungeprüft. Prüfe ihn auf überzogene Aussagen, fehlende Alternativen, unklare Verantwortlichkeiten und nicht belegbare Behauptungen. Bitte dann um eine zweite Fassung:
„Revise this collab-proof output to be more conservative. Remove claims not supported by the diff or transcript. Add a short ‘developer-owned decisions’ section and a ‘Claude-assisted insights’ section.“
Das führt in der Regel zu glaubwürdigerer Dokumentation, als sofort nach einem polierten Artefakt zu fragen.
Bei Bedarf manipulationserschwerende Nachweise ergänzen
Wenn die Evidenz extern geteilt werden könnte, ziehe den Git-notes-Workflow aus references/tamper-evident-proof.md in Betracht. Die Idee ist, die generierte HTML-Proof-Datei zu hashen und den Hash mit git notes an den relevanten Commit anzuhängen. Das macht den Inhalt nicht automatisch wahr, hilft aber zu zeigen, dass ein bestimmtes Proof-Artefakt zu einem bestimmten Code-Stand existiert hat.