# Contribuer > Préparer une contribution propre et adoptable à un repo dont tu n'es PAS mainteneur, de bout en bout : resync du fork, branche courte, respect des règles immuables et des conventions du projet, garde de validation (tests/lint/build), puis PR petite et prête à relire. Utilise ce skill quand tu commences à coder une feature ou un fix sur le repo de quelqu'un d'autre. Pendant « contributeur » du skill review-contrib (côté relecteur). Version exécutable d'un bon CONTRIBUTING.md. - Skill: `lbachelotcapitalb/contribuer` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add lbachelotcapitalb/contribuer` - Raw SKILL.md: https://api.skillmd.com/api/skills/lbachelotcapitalb/contribuer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: lbachelotcapitalb (https://skillmd.com/u/lbachelotcapitalb) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/lbachelotcapitalb/contribuer --- # contribuer — faire une PR adoptée en minutes Tu contribues à un repo dont **tu n'es pas le mainteneur**. Pars du principe que `main` = **production** (souvent déployée automatiquement) : tu n'y touches **jamais** directement — tu proposes via une **PR**, le mainteneur relit et merge. L'objectif n'est pas seulement que ça marche, c'est que ce soit **adoptable sans friction** : petit, conforme aux règles du projet, vert. > C'est le miroir du skill [[review-contrib]] (côté relecteur) : ce que le relecteur va vérifier, > fais-le toi-même **avant** d'ouvrir la PR. ## Version — à contrôler une fois, au chargement Ce skill est **versionné** : le numéro vit dans `VERSION` (à côté de ce fichier), l'historique dans `CHANGELOG.md`. Le numéro n'est **jamais recopié ici** — deux copies d'un même numéro divergent en silence. Au premier tour, lance une fois, depuis le dossier de base annoncé à l'invocation : ```bash bash /scripts/check-update.sh ``` Une requête, 3 s au plus, aucun effet de bord, jamais bloquant. Ce que tu fais de sa sortie : | Sortie | Ce que tu en fais | |---|---| | `à jour (x.y.z)` | rien — ne l'annonce pas, c'est du bruit | | `NOUVELLE VERSION …` | **dis-le en une ligne** (lien du changelog + commande de mise à jour), puis **continue** : la contribution en cours prime, on ne se met pas à jour au milieu | | `indisponible` / `en avance` | rien, et ne retente pas | Ne le relance pas aux tours suivants : le skill reste chargé, le numéro ne bougera pas d'ici la fin de la session. ## 0. D'abord : lire le projet et te mettre à jour Avant toute ligne de code, **découvre les règles du repo** — ne les devine pas : ```bash # les docs qui dictent les conventions (lis ce qui existe) ls CONTRIBUTING.md CLAUDE.md AGENTS.md README.md docs/ 2>/dev/null ``` Puis branche-toi sur une base à jour depuis l'upstream (le repo d'origine, pas ton fork) : ```bash git remote add upstream https://github.com//.git # une seule fois git fetch upstream git checkout -b feat/ upstream/main # branche COURTE, dédiée # installe + lance en local selon le repo (npm install && npm run dev, make, etc.) ``` **Une PR = une intention.** Une seule fonctionnalité ou un seul fix par branche — c'est ce qui réduit les conflits et accélère la relecture. ## 1. Repérer les règles immuables — et ne JAMAIS les franchir Tout repo sérieux a des **invariants** qu'on ne casse pas (sinon perte de données, rupture de compat, build cassé). Ils sont en général écrits dans `CONTRIBUTING.md` / `CLAUDE.md` / `AGENTS.md`. Cherche notamment : | Type d'invariant | À quoi faire attention | |---|---| | **Clé de stockage / format persisté** | Ne jamais renommer une clé (localStorage/IndexedDB/DB) ni changer un format sérialisé sans migration. | | **Version de schéma / migration** | N'incrémenter qu'en cas de rupture, **avec** la migration qui va avec. | | **Actions destructives** | Respecter le garde-fou du repo (snapshot/undo avant, confirmation explicite plutôt qu'un dialogue natif). | | **Budget de bundle / perf** | Une grosse dépendance doit être code-splitée, ou refusée. Vérifie l'impact. | | **Données auto-générées** | Doivent rester idempotentes / régénérables (marqueur de source, id de lien) — pas de doublons. | Si le repo liste ses propres règles, **ce sont elles qui priment** sur cette grille générique. ## 2. Épouser les conventions du projet Le code doit se lire comme le code autour. Avant d'écrire : - **Lis un fichier voisin** et imite sa structure (mono-fichier vs modules, où vivent les constantes, comment sont nommés les helpers). - **Réutilise les helpers existants** plutôt que d'en réécrire (formatage des montants/dates, parsing, accès au state). - **Respecte la locale et le formatage** du projet (séparateurs décimaux, dates, i18n). - **Pas de valeurs en dur** là où le repo centralise (constantes, config, taux). ## 3. La garde — avant la PR Lance la **commande de validation du repo** et exige du **100 % vert**. Cherche-la dans le `package.json` / `Makefile` / la CI : ```bash npm run audit # ex. : tests + lint + build (adapte au repo : npm test, make check, etc.) ``` Tu touches une logique sensible (calcul, persistance, sécurité) ? **Ajoute un test** sur le même modèle que les tests existants. Un correctif sans test de non-régression est plus dur à adopter. ## 4. Auto-audit puis PR Avant d'ouvrir, relis-toi comme le ferait le mainteneur : - [ ] Validation **verte** ; règles immuables intactes ; conventions respectées. - [ ] Diff **petit** et ciblé ; aucun secret ; pas de `console.log`/debug oublié ; branche rebasée sur `upstream/main`. - [ ] Le commit explique **quoi & pourquoi**, pas seulement « fix ». ```bash git push -u origin feat/ gh pr create --repo / --base main ``` Remplis le template de PR du repo (quoi & pourquoi, comment tester, checklist). **Petit + vert + conforme = mergé vite.** Une grosse PR fourre-tout qui touche aux invariants se fait renvoyer. ## 5. Ce que tu ne fais pas Quatre gestes qui font renvoyer une contribution, quelle que soit sa qualité : - ❌ **Pousser sur `main`.** C'est la production, et ce n'est pas ton rôle — même si tu en as les droits par accident. - ❌ **Une PR géante multi-sujets.** Elle ne se relit pas, donc elle ne se merge pas ; elle se découpe. - ❌ **Ajouter une grosse dépendance sans la justifier.** Dis dans la PR pourquoi elle est nécessaire et ce qu'elle coûte au bundle. - ❌ **Committer un secret** — clé, `.env`, jeton, PII, y compris dans un test ou un message de commit. Ça ne se rattrape pas d'un commit de retrait : un secret parti dans un dépôt est à considérer comme compromis, donc à roter.