contribuerlisted

# 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. ## 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/<owner>/<repo>.git # une seule fois git fetch upstream git checkout -b feat/<sujet> 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 d