oss-prep

Préparation open source

Une passe de pré-lancement pour un dépôt sur le point de devenir public. Un script effectue les vérifications mécaniques ; vous lisez le projet, jugez ce que le script ne peut pas juger, faites un rapport, puis ne remplissez que ce que l'utilisateur choisit.

L'ordre est important car une erreur ne peut pas être annulée : une fois qu'un dépôt est public, tout son historique a été vu. Les identifiants divulgués et les données personnelles passent en premier ; le texte standard vient en dernier.

1. Scanner

Exécutez le scanner fourni depuis la racine du dépôt (Node 20 ou plus récent, sans dépendances, lecture seule) :

node <skill-dir>/scripts/scan.mjs <repo-dir>

Il affiche du JSON : summary compte les résultats d'échec par niveau, et chaque résultat a un id, un level (block, warn, info), un status (pass, fail, skip) et evidence. Ajoutez --no-history pour un très grand historique uniquement si l'utilisateur accepte de sauter cette partie, et dites qu'elle a été sautée. Si gitleaks est installé, exécutez également gitleaks git <repo-dir> --redact --no-banner et fusionnez ses résultats ; il connaît beaucoup plus de formats de jetons.

Les règles de secret du scanner sont des motifs, attendez-vous donc à des faux positifs (corps de test, exemples de documentation) et ne supposez pas qu'il a tout attrapé. Examinez chaque résultat vous-même avant de le signaler. Une ligne peut être marquée comme intentionnelle avec un commentaire oss-prep: allow.

2. Lire et juger

Consultez references/checklist.md pour savoir ce que signifie chaque vérification, comment distinguer un vrai problème d'un bruit, et les vérifications que vous seul pouvez effectuer. En résumé, au-delà des résultats du script :

• Ce que l'historique et les fichiers révèlent. Ouvrez chaque résultat de secret et chaque fichier sensible dans l'historique (git show <commit>:<path>). Recherchez les vrais noms, e-mails, numéros de téléphone, adresses, données clients ou financières, noms d'hôte internes, et captures d'écran avec des données privées dans la documentation ou les corps de test.
• Cohérence de la licence. Le texte LICENSE, package.json, le frontmatter de SKILL.md, le README et tout en-tête par fichier doivent être cohérents. Notez le code tiers inclus, les polices ou images et si leurs licences autorisent la redistribution.
• README pour un inconnu. Quelqu'un arrivant via une recherche doit apprendre ce que c'est, le voir (une capture d'écran ou un lien de démo), l'installer et l'exécuter, et trouver la licence, sans contexte privé.
• Des choses qui ne fonctionnaient que pour l'auteur. Chemins locaux codés en dur, valeurs .env dont le projet a besoin mais qu'il ne documente pas, scripts qui supposent la machine de l'auteur.

3. Rapport

Rédigez le rapport dans la langue de l'utilisateur, sous cette forme :

# État de préparation open source : <dépôt>

**Verdict :** <Prêt / Prêt après les éléments bloquants / Pas prêt>, une phrase expliquant pourquoi.

## Bloquant (à corriger avant de rendre public)
- ❌ <titre> : <ce qui a été trouvé, avec fichier:ligne ou commit> → <la correction>

## Devrait être corrigé
- ⚠️ ...

## Accessoire
- 💡 ...

## Déjà en place
- ✅ <une ligne chacun, groupés>

## Nécessite votre action sur GitHub
<paramètres que l'utilisateur modifie lui-même, avec la commande gh exacte ou le chemin des paramètres>

Mettez l'élément le plus grave en premier. Soyez précis : « src/config.ts:12 contient une clé OpenAI, également dans le commit a1b2c3d » plutôt que « secrets trouvés ». Dites ce que vous n'avez pas vérifié (pas de gh, historique ignoré, fichiers binaires).

Demandez ensuite quels éléments remplir. Proposez l'ensemble évident comme valeur par défaut (« tous les fichiers manquants »), et listez chaque choix pour que l'utilisateur puisse sélectionner.

4. Remplir ce que l'utilisateur a choisi

Utilisez les modèles dans assets/templates/ comme point de départ et adaptez-les à ce projet ; lisez d'abord references/fixing.md. En résumé :

• Écrivez des fichiers, ne publiez jamais. Créez ou modifiez des fichiers dans l'arbre de travail uniquement. Ne commitez pas, ne poussez pas, ne modifiez pas la visibilité ou les paramètres du dépôt, et ne créez pas de versions sauf si l'utilisateur le demande explicitement.
• Adaptez au projet. Utilisez ses vraies commandes, version de Node, gestionnaire de paquets, licence et voie de contact ; écrivez dans la langue du README (les deux, si le README est bilingue). Omettez les sections qui ne s'appliquent pas plutôt que de livrer des espaces réservés.
• Ne choisissez jamais une licence pour l'utilisateur. S'il n'y en a pas, expliquez les choix courants en une phrase chacun (MIT, Apache-2.0, GPL-3.0, AGPL-3.0, double licence) et demandez. Copiez exactement le texte officiel de la licence ; ne paraphrasez pas et ne le retapez pas de mémoire.
• Les secrets dans l'historique ne sont pas corrigés en supprimant le fichier. L'identifiant doit être révoqué et remplacé en premier ; c'est le travail de l'utilisateur dans la console du fournisseur. Réécrire l'historique (git filter-repo) ou publier un nouveau dépôt sont ses décisions ; expliquez les deux et ne faites rien sans un oui clair.
• Les paramètres GitHub appartiennent à l'utilisateur. Donnez les commandes gh exactes ou les chemins de paramètres depuis la référence ; exécutez-les seulement si l'utilisateur le demande.

Terminez en exécutant à nouveau le scanner et en montrant quels résultats ont changé, ainsi que ce qui reste à faire pour l'utilisateur.