collab-proof

Présentation de collab-proof skill

À quoi sert collab-proof

collab-proof est un Claude skill qui transforme une session de code assistée par l’IA en preuves de collaboration exploitables : ce qui a été décidé, ce que Claude a apporté, pourquoi certaines options ont été écartées et quels artefacts permettent de le démontrer. Il s’adresse surtout aux développeurs qui utilisent Claude Code et veulent de meilleurs bilans de session, des preuves pour un portfolio, des éléments utiles au recrutement ou une Knowledge Capture durable après un travail d’ingénierie significatif.

Plutôt que de produire un résumé générique, collab-proof applique un workflow par couches : détecter la force du signal de la session, classifier l’intention du travail, évaluer le cadre de collaboration, puis décider quels artefacts de documentation méritent d’être générés.

Utilisateurs et cas d’usage les plus adaptés

Utilisez collab-proof lorsque vous devez répondre à des questions comme :

• « Qu’est-ce que Claude a réellement apporté ici ? »
• « Quelles décisions venaient de moi, et lesquelles ont été suggérées par l’IA ? »
• « Puis-je montrer ce travail dans un portfolio sans exagérer ma contribution ? »
• « Quel raisonnement serait perdu si la transcription de la conversation disparaissait ? »

Il est particulièrement utile après un diagnostic de bug, des choix d’architecture, l’implémentation d’une fonctionnalité, un refactoring ou une discussion sur des compromis de conception. Le skill est moins pertinent pour de toutes petites modifications, des commits uniquement liés au formatage, des mises à jour de dépendances ou des sessions où aucun raisonnement notable n’a eu lieu.

Ce qui le distingue

Son principal différenciateur est l’attribution calibrée. collab-proof ne se contente pas de résumer « ce qui a changé » ; il sépare l’intention du développeur, les suggestions de Claude, les idées retenues, les alternatives rejetées et le raisonnement autour de la cause racine. Le contenu source inclut aussi des recommandations pour produire des preuves infalsifiables à l’aide de Git notes et de hachages SHA-256, un point important si vous voulez relier une documentation à un commit précis.

Pour la Knowledge Capture, collab-proof est le plus utile lorsque la session contient des décisions, un diagnostic, des alternatives ou une justification qui ne seraient pas évidents à partir du diff final.

Comment utiliser collab-proof skill

Contexte d’installation de collab-proof

Installez le skill depuis le dépôt avec :

npx skills add alirezarezvani/claude-skills --skill collab-proof

Le skill se trouve ici :

engineering/collab-proof/skills/collab-proof

Après l’installation, commencez par lire SKILL.md, puis consultez les fichiers de référence qui expliquent le modèle de preuve :

• references/ai-collaboration-evidence.md
• references/developer-portfolio-proof.md
• references/session-documentation-patterns.md
• references/tamper-evident-proof.md

Le dossier du skill ne contient pas de scripts d’assistance : attendez-vous donc à un workflow piloté par prompt, et non à un générateur de rapport en une seule commande.

Entrées dont le skill a besoin

Pour bien utiliser collab-proof, fournissez davantage qu’une demande vague. Le skill fonctionne mieux avec :

• L’état actuel du dépôt
• Les commits récents ou le diff pertinent
• Une courte description de l’objectif de la session
• Les extraits importants de la conversation
• Le bug, la fonctionnalité ou la décision à documenter
• La destination du résultat : notes personnelles, PR, portfolio ou preuve pour un recrutement

Le workflow amont demande à Claude d’exécuter d’abord git log --oneline -10 et git diff --stat HEAD~3..HEAD. Ces commandes aident à classer la session en signal fort, moyen ou faible. Une correction de bug dans un seul fichier peut tout de même constituer un signal fort si la transcription contient le diagnostic de la cause racine et la justification du correctif.

Bon modèle de prompt pour collab-proof

Un prompt faible serait :

« Use collab-proof on this project. »

Un prompt plus efficace serait :

« 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. »

Ce second prompt fonctionne mieux parce qu’il donne au skill une mission, un périmètre, un public cible et les points de décision à préserver.

Workflow recommandé

Commencez par une rétrospective ciblée juste après la session, tant que le raisonnement est encore frais. Demandez à Claude d’identifier le niveau de signal avant de rédiger les artefacts finaux. Si la session présente un signal fort, demandez des decision records, un historique de session, un worklog et une sortie de preuve portable. Si le signal est moyen, un worklog concis peut suffire. Si le signal est faible, évitez de surdocumenter.

Pour un portfolio ou un usage lié au recrutement, demandez une formulation prudente. Une bonne preuve dira plutôt « Claude identified X; I evaluated and chose Y because Z » que « AI built the project ».

FAQ sur collab-proof skill

collab-proof sert-il uniquement aux portfolios ?

Non. La preuve pour portfolio est un cas d’usage important, mais collab-proof est tout aussi utile pour la Knowledge Capture. Il aide à conserver les justifications qui disparaissent de l’historique Git : pourquoi un bug est survenu, pourquoi un design a changé, ce que l’IA a remarqué et à quels moments le développeur a choisi de ne pas suivre l’IA.

En quoi est-il meilleur qu’un prompt de résumé classique ?

Un prompt de résumé classique compresse généralement la session en liste de tâches terminées. collab-proof est plus structuré : il évalue la force des preuves, distingue les contributions humaines et IA, donne la priorité aux justifications de décision et évite de traiter toutes les sessions de code comme si elles avaient la même importance. Le résultat est donc plus utile pour les revues, les rétrospectives et la preuve de travail.

Les débutants peuvent-ils utiliser ce skill ?

Oui, mais il vaut mieux commencer simplement. Demandez d’abord un worklog et une répartition des contributions avant de solliciter une preuve complète pour portfolio. Les parties difficiles ne sont pas l’installation, mais le fait de fournir assez de contexte et d’éviter les déclarations exagérées sur ce que l’IA a fait.

Quand ne faut-il pas utiliser collab-proof ?

N’utilisez pas collab-proof pour des commits routiniers sans raisonnement significatif, du boilerplate généré, du nettoyage cosmétique ou des transcriptions privées que vous ne pouvez pas résumer sans risque. Évitez aussi de l’utiliser comme substitut à de vrais tests, à une revue de code ou à une bonne hygiène de commits. Il documente la collaboration ; il ne valide pas la justesse du code.

Comment améliorer collab-proof skill

Améliorer les entrées fournies à collab-proof

Le mode d’échec le plus fréquent est un contexte trop léger. Pour obtenir de meilleurs résultats, donnez à Claude l’objectif de la session, les extraits importants de la conversation, les fichiers concernés, la plage de commits et le lecteur visé. Si le résultat est destiné au recrutement, dites-le. S’il sert à une Knowledge Capture interne, demandez plus de détails techniques et moins de vernis marketing.

Format d’entrée utile :

• Goal: ce que vous cherchiez à accomplir
• Change set: commits, fichiers ou plage de diff
• Reasoning: alternatives envisagées et rejetées
• Attribution: ce que vous avez proposé, ce que Claude a proposé, ce qui a changé
• Audience: notes privées, PR, README, recruteur, portfolio

Ajuster l’attribution et la qualité des preuves

Demandez une attribution calibrée pour chaque décision importante. Une bonne sortie collab-proof doit éviter les deux extrêmes : faire comme si le développeur avait tout fait seul, ou prétendre que Claude a construit la solution de manière autonome. Demandez des formulations comme « Claude suggested », « developer selected », « developer rejected », « jointly refined » et « root cause identified from ».

Pour les corrections de bugs, demandez explicitement au skill de capturer la cause, le chemin de diagnostic et la justification du correctif. La règle BUG_FIXING du dépôt considère une correction bien expliquée dans un seul fichier comme une preuve à forte valeur.

Itérer après la première sortie

N’acceptez pas aveuglément la première preuve générée. Relisez-la pour repérer les exagérations, les alternatives manquantes, les responsabilités floues et les affirmations impossibles à vérifier. Demandez ensuite une seconde passe :

« 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. »

Cela produit généralement une documentation plus crédible que de demander immédiatement un artefact très poli.

Ajouter une preuve infalsifiable si nécessaire

Si la preuve doit être partagée à l’extérieur, envisagez le workflow avec Git notes décrit dans references/tamper-evident-proof.md. L’idée consiste à hacher le fichier HTML de preuve généré, puis à attacher ce hachage au commit concerné avec git notes. Cela ne rend pas automatiquement le contenu vrai, mais aide à montrer qu’un artefact de preuve précis existait pour un état de code précis.