Optimisation de dépôt GitHub

Transformez n'importe quel dépôt GitHub en une page d'atterrissage optimisée pour le SEO et à fort taux de conversion qui génère des étoiles, des abonnés et du trafic. Chaque dépôt que vous touchez doit ressembler à un projet open source du top 100.

Cette compétence a deux modes :

Optimiser — réécrire le README, les métadonnées et la structure d'un dépôt pour une conversion maximale
Conseiller — donner à l'utilisateur une stratégie de croissance d'étoiles en utilisant la base de connaissances ci-dessous

Objectifs (par ordre de priorité)

Étoiles — la principale mesure de preuve sociale sur GitHub
Abonnés — générer du trafic vers les profils sociaux du propriétaire du dépôt
Découvrabilité — être bien classé dans la recherche GitHub, Google et les moteurs de réponses LLM
Trafic — transformer les visiteurs en utilisateurs/abonnés
Crédibilité professionnelle — signaler la qualité par la structure et le soin

Étape 0 : Configuration utilisateur (auto-mise à jour)

Avant d'optimiser, vous devez savoir qui possède ce dépôt. Cette étape s'exécute une fois — ensuite, la configuration est réutilisée.

Vérifier la configuration existante

Recherchez ~/.claude/skills/github-optimization/.config.yml. S'il existe, chargez les valeurs et passez à l'étape 1. Affichez à l'utilisateur ce qui est chargé et demandez si quelque chose a changé.

Si aucune configuration n'existe, détectez + demandez

Détection automatique à partir de la configuration git et de l'API GitHub :
- gh api user — obtient le nom d'utilisateur GitHub authentifié et l'URL du profil
- gh api repos/<propriétaire>/<dépôt> — obtient le propriétaire du dépôt (peut être un org ou un utilisateur)
- git config user.name — obtient le nom d'affichage git local
Demandez à l'utilisateur tout ce que vous ne pouvez pas détecter :
- Nom d'affichage — son vrai nom ou l'attribution préférée (ex : "Jean Dupont")
- Pseudo X/Twitter — pour le badge Suivre (ex : "@jeandupont"). S'il ne le souhaite pas, ignorez-le.
- Entreprise ou organisation — pour l'attribution en pied de page (facultatif)
- URL de l'entreprise — lien pour le nom de l'entreprise (facultatif)
- URL du site web — site personnel ou de l'entreprise (facultatif)
Enregistrez la configuration dans ~/.claude/skills/github-optimization/.config.yml :

# Compétence d'Optimisation GitHub — Configuration Utilisateur
# Ce fichier est généré automatiquement. Modifiez-le à tout moment.
author_name: "Jean Dupont"
author_github: "jeandupont"
x_handle: "jeandupont"          # laissez vide "" pour ignorer le badge Suivre
company_name: "Acme Corp"      # laissez vide "" pour ignorer
company_url: "https://acme.com"
website_url: "https://jeandupont.dev"

Utilisez ces variables tout au long du pipeline :
- {OWNER} — nom d'utilisateur GitHub ou org (à partir de l'URL du dépôt, détecté par dépôt)
- {REPO} — nom du dépôt (détecté par dépôt)
- {AUTHOR_NAME} — depuis la configuration
- {AUTHOR_GITHUB} — depuis la configuration
- {X_HANDLE} — depuis la configuration (peut être vide)
- {COMPANY_NAME} — depuis la configuration (peut être vide)
- {COMPANY_URL} — depuis la configuration (peut être vide)
- {WEBSITE_URL} — depuis la configuration (peut être vide)

Si un champ est vide, omettez complètement cet élément de la sortie. Pas de placeholders vides ni de badges cassés.

Mise à jour de la configuration

Si l'utilisateur dit "mets à jour ma config", "change mon pseudo X" ou similaire, mettez à jour le fichier .config.yml et confirmez le changement.

Le Pipeline d'Optimisation

0. CONFIG       -> Charger ou créer la config utilisateur (s'exécute une fois, se met à jour)
1. AUDIT        -> Lire le README actuel, la description, les sujets, la structure du dépôt
2. KEYWORDS     -> Identifier les termes de recherche cibles pour le domaine de ce dépôt
3. METADATA     -> Optimiser le nom du dépôt, la description (À propos) et les sujets
4. README       -> Réécrire en page d'atterrissage selon le modèle ci-dessous
5. HUMANISE     -> Exécuter la compétence humanise-text sur toute la prose pour supprimer les motifs d'IA
6. EXTRAS       -> Ajouter LICENSE, CONTRIBUTING.md si manquants
7. PUBLISH      -> Commiter, pousser, appliquer gh repo edit pour description/sujets

Chaînage de Compétences

Cette compétence appelle d'autres compétences lors de l'exécution :

humanise-text — Après avoir rédigé le README, invoquez la compétence humanise-text sur toutes les sections en prose. Cela supprime les motifs d'écriture d'IA et rend le texte comme s'il avait été écrit par une vraie personne. Non négociable — chaque README doit passer par là.

Étape 1 : Audit

Lisez l'état actuel :

Contenu et structure du README.md
Description du dépôt (section À propos)
Sujets/étiquettes
Licence
Structure des fichiers
Tous les badges existants

Notez ce qui manque, ce qui est faible, ce qui est bon.

Étape 2 : Recherche de mots-clés

Identifiez 3 à 5 mots-clés cibles que les développeurs rechercheraient pour trouver ce projet. Tenez compte :

Quel problème cela résout-il ?
Quelle technologie utilise-t-il ?
Dans quel domaine se situe-t-il ?

Ces mots-clés doivent apparaître dans : le nom du dépôt (si possible), la description À propos, les en-têtes H1 et H2 du README, et les étiquettes de sujets.

Étape 3 : Optimisation des métadonnées

Description À propos

Idéalement moins de 120 caractères, max 250
Commencez par ce qu'il fait, pas ce qu'il est
Incluez le mot-clé principal naturellement
Format : <Verbe d'action> <quoi> pour <qui/quoi>. <Différenciateur clé>.

Étiquettes de sujets

Sélectionnez 10 à 20 étiquettes dans trois catégories :

Étiquettes de fonction — ce que fait le projet
Étiquettes de pile technique — technologies utilisées
Étiquettes de domaine — domaine ou industrie

Appliquez avec :

gh repo edit {OWNER}/{REPO} --add-topic tag1 --add-topic tag2 ...

Étape 4 : Réécriture du README

Le README est une page d'atterrissage, pas une documentation.

Modèle de README

Adaptez les badges en fonction des informations utilisateur disponibles dans la configuration :

<div align="center">

# <Nom du Projet>

**<Accroche en une ligne — ce qu'il fait en termes simples>**

<br />

[![Star this repo](https://img.shields.io/github/stars/{OWNER}/{REPO}?style=for-the-badge&logo=github&label=%E2%AD%90%20Star%20this%20repo&color=yellow)](https://github.com/{OWNER}/{REPO}/stargazers)

Si {X_HANDLE} est défini, ajoutez à côté du badge étoile :

&nbsp;&nbsp;
[![Follow @{X_HANDLE}](https://img.shields.io/badge/Follow_%40{X_HANDLE}-000000?style=for-the-badge&logo=x&logoColor=white)](https://x.com/{X_HANDLE})

Si {X_HANDLE} est vide, ignorez complètement le badge Suivre.

Continuez ensuite avec les badges de crédibilité :

<br />

[![<Badge 1>](shields-url)](<lien>)
&nbsp;
[![<Badge 2>](shields-url)](<lien>)

---

<Paragraphe d'accroche. Quelle douleur cela résout-il ? Pourquoi quelqu'un devrait-il s'y intéresser ?>

[Installation](#installation) | [Comment ça marche](#comment-ça-marche) | [Fonctionnalités](#fonctionnalités) | [Contribuer](#contribuer)

</div>

Règles pour les badges

Ligne 1 (CTA — grands, proéminents) :

Badge étoile avec compteur en direct — TOUJOURS en premier, style=for-the-badge, jaune
Badge Suivre sur X — UNIQUEMENT si {X_HANDLE} est défini

Ligne 2 (Badges de crédibilité — même taille) :

Tous les badges utilisent style=for-the-badge — ne mélangez jamais les tailles
Choisissez 2 à 4 pertinents : Licence, PRs Bienvenues, langage/framework, statut de build

Ordre des sections

Pourquoi cela existe / Le Problème — 2-3 phrases sur le point douloureux
Avant vs Après (facultatif) — tableau comparatif
Installation / Démarrage rapide — moins de 5 étapes, une commande idéale
Comment ça marche — flux de travail visuel (diagramme ASCII, tableau ou étapes numérotées)
Fonctionnalités / Cas d'utilisation — tableau ou liste à puces, scannable
Ce qu'il y a à l'intérieur / Structure — arborescence des fichiers si pertinent
Configuration / Options (facultatif)
Sécurité (facultatif)
Contribuer — court, accueillant
Licence — une ligne
Pied de page avec CTA — badges étoile + suivre répétés

Modèle de pied de page

Construisez dynamiquement à partir de la configuration :

---

<div align="center">

Ligne d'attribution — construisez à partir des champs de configuration disponibles :

Si auteur + entreprise + site web : Construit par [NOM](GITHUB) chez [ENTREPRISE](URL_ENTREPRISE) | [SITE WEB](URL_SITE_WEB)
Si auteur + entreprise (pas de site web) : Construit par [NOM](GITHUB) chez [ENTREPRISE](URL_ENTREPRISE)
Si auteur + site web (pas d'entreprise) : Construit par [NOM](GITHUB) | [SITE WEB](URL_SITE_WEB)
Si auteur seulement : Construit par [NOM](GITHUB)
Si rien : Construit avec la compétence github-optimization

<br />

**Si cela vous est utile :**

[![Star this repo](star-badge-url)](stargazers-url)

Si {X_HANDLE} existe, ajoutez le badge Suivre ici aussi.

</div>

Règles d'écriture

Non négociables. Elles définissent la voix.

À FAIRE :

Écrire comme un humain qui explique à un ami. Phrases courtes. Voix active.
Commencer chaque section par la valeur, pas par le mécanisme
Utiliser "vous" et "votre" — parlez directement au lecteur
Être spécifique plutôt qu'abstrait
Limiter les paragraphes à 2-3 phrases maximum
Utiliser des tableaux pour les comparaisons

À NE PAS FAIRE :

Utiliser du jargon IA : "exploiter", "optimiser", "autonomiser", "transparentement", "robuste", "de pointe", "révolutionner", "exploiter la puissance de", "améliorer votre flux de travail", "booster"
Commencer les phrases par "Ce projet..." ou "Cet outil..."
Écrire des murs de texte
Utiliser la voix passive
Ajouter des mots de remplissage : "fondamentalement", "essentiellement", "simplement", "juste"
Utiliser des points d'exclamation

SEO dans les en-têtes :

H1 doit contenir le mot-clé principal
Les H2 doivent contenir naturellement des mots-clés secondaires
Écrire d'abord pour les humains, mais être délibéré sur le placement

Étape 5 : Extras

Ajoutez si manquants :

LICENSE — MIT sauf si l'utilisateur spécifie autre chose
CONTRIBUTING.md — court, accueillant, processus en 3 étapes

N'ajoutez PAS sauf si demandé : CODE_OF_CONDUCT.md, SECURITY.md, .github/ISSUE_TEMPLATE/

Étape 6 : Publication

Commitez toutes les modifications avec un message descriptif
Poussez vers le dépôt distant
Mettez à jour les métadonnées du dépôt via gh repo edit
Rapportez à l'utilisateur : ce qui a changé, la nouvelle description, les sujets ajoutés, l'URL en direct

Liste de vérification avant la fin

Base de connaissances sur la croissance des étoiles

Lorsque les utilisateurs demandent "comment obtenir plus d'étoiles ?", "stratégie de lancement", "promouvoir mon dépôt" ou similaire, utilisez cette base de connaissances pour les conseiller. Cette section est du matériel de référence, pas une partie du pipeline d'optimisation.

Classement des canaux (par ROI)

Rang	Tactique	Effort	Étoiles attendues	Risque
1	Lancement groupé (HN + Reddit + X + PH le même jour)	Élevé (1 jour de préparation)	200-2 000+	Aucun
2	Soumissions à des listes Awesome	Faible (PR)	Croissance lente, composée	Aucun
3	Optimisation du README + aperçu social	Moyen (1 heure)	Multiplicateur x3 sur tous les autres efforts	Aucun
4	SEO GitHub (nom, sujets, description)	Faible (30 min)	Découverte passive à long terme	Aucun
5	GIF/Démo vidéo dans le README	Moyen	Conversion considérablement plus élevée	Aucun
6	Créez votre propre liste Awesome	Moyen	Croissance lente + promotion croisée	Aucun
7	Soumissions à des newsletters	Faible (emails)	50-500 par mention	Aucun
8	Tutoriels YouTube	Élevé	Meilleur moteur durable à long terme	Aucun
9	Listicle réciproque sur X	Faible	Dépend du réseau	Aucun
10	Étiquetage Hacktoberfest (octobre)	Faible	50-200 saisonniers	PRs indésirables
11	Construction de communauté Discord	Élevé continu	Rétention/plaidoyer	Aucun
12	Discussions de conférence	Élevé	Faible direct, composé élevé	Aucun

Guide Hacker News

Meilleur moment : Mardi-jeudi, 8-10 h Pacifique. Dimanche 18-21 h Pacifique pour moins de concurrence.

Format du titre : Show HN: [Nom] — [Ce qu'il fait concrètement]

Ce qui fonctionne : Écrire comme un pair, pas comme un marketeur. Pas de jargon. Commencer par le problème. Répondre à chaque commentaire dans la première heure. Poster votre propre premier commentaire substantiel dans les 5 minutes.

Seuils : 8-10 votes authentiques + 2-3 commentaires réfléchis dans les 30 premières minutes pour entrer dans le top 10.

Exigences de compte : 250+ karma avec un historique de commentaires techniques pour de meilleurs résultats. Les nouveaux comptes sont soumis à la modération.

La détection des réseaux est agressive. Ne tweetez jamais "s'il vous plaît, votez pour mon post HN". Utilisez des canaux privés (email, Slack, Discord) pour informer les gens.

Résultats réels :

Lago : #1 pendant 48+ heures, principal moteur pour 1 000 étoiles
Encore : 1 500 étoiles en une semaine à partir d'un seul Show HN
Moyenne : 121 étoiles en 24 heures, 289 en une semaine

Guide Reddit

Gagnez du karma 2+ semaines avant de poster. La règle 90/10 de Reddit : 90 % d'activité authentique, 10 % d'auto-promotion.

Subreddit	Notes
r/SideProject (453K)	Autorise explicitement l'auto-promo
r/programming (6M+)	Anti-promo strict, "comment nous avons construit X" fonctionne
r/selfhosted (500K+)	Convertit extrêmement bien
r/webdev	"Showoff Saturday" uniquement
r/opensource	Amical pour les liens, volume plus faible
r/coolgithubprojects	Spécifiquement pour les dépôts GitHub

Attendu : 50-300 étoiles par publication réussie. Adaptez le message par subreddit.

Guide Product Hunt

Réinitialisation des votes : 12:01 AM PST chaque jour. Votes cachés les 4 premières heures.

Votes pour #1 : 600-800 en semaine, 400-600 le week-end.

Meilleurs jours : Mardi-jeudi.

Attendu : 200-1 000 étoiles pour un top-5 Produit du Jour. #1 peut fournir 500-2 000+.

Calendrier :

4-6 semaines avant : Construisez 200-500 abonnés email
1 semaine avant : Préparez tous les actifs
Jour du lancement : Mise en ligne à 12:01 AM PST, répondez à tout, email blast à 6 AM PST

Guide Twitter/X

Ce qui fonctionne : Les courtes vidéos de démonstration/GIFs surpassent le texte. Les tweets des supporters génèrent plus d'étoiles que les tweets personnels. En semaine le matin heure des États-Unis (9-11h HE).

Attendu : 7 % d'augmentation des étoiles grâce au tweet. Les tweets vidéo viraux peuvent atteindre 1 600 étoiles en 6 heures.

La stratégie de lancement groupé

La méta-stratégie utilisée par tous les dépôts à croissance rapide :

Calendrier	Action	Étoiles attendues
Semaine avant	Soumettre aux newsletters (TLDR, Console.dev, Changelog)	--
Matin du lancement	Poster HN "Show HN" (Mar-Mer, 8-11h HE)	121 en moyenne, jusqu'à 1 500
Après-midi du lancement	Poster Reddit (r/programming, r/selfhosted, sous-domaine)	50-300
Jour du lancement	Tweeter une vidéo de démonstration + faire partager les supporters	50-500+
Jour du lancement	Product Hunt (si vous avez une liste)	200-1 000+

Dernière mise à jour : [Date actuelle]

Demander à votre IA préférée

Aperçu

Documentation