Compétence Pipeline Open-Source
Open-source n'importe quel projet en toute sécurité via un pipeline en 3 étapes : Fork (supprimer les secrets) → Sanitize (vérifier la propreté) → Package (CLAUDE.md + setup.sh + README).
Quand activer
- L'utilisateur dit "rendre ce projet open-source" ou "le rendre public"
- L'utilisateur souhaite préparer un dépôt privé pour une publication publique
- L'utilisateur doit supprimer des secrets avant de pousser sur GitHub
- L'utilisateur invoque
/opensource fork,/opensource verifyou/opensource package
Commandes
| Commande | Action |
|---|---|
/opensource fork PROJET | Pipeline complet : fork + sanitize + package |
/opensource verify PROJET | Exécuter le sanitizer sur un dépôt existant |
/opensource package PROJET | Générer CLAUDE.md + setup.sh + README |
/opensource list | Afficher tous les projets en préparation |
/opensource status PROJET | Afficher les rapports d'un projet en préparation |
Protocole
/opensource fork PROJET
Pipeline complet — le flux de travail principal.
Étape 1 : Rassembler les paramètres
Résoudre le chemin du projet. Si PROJET contient /, le traiter comme un chemin (absolu ou relatif). Sinon vérifier : le répertoire de travail courant, $HOME/PROJET, puis demander à l'utilisateur.
SOURCE_PATH="<chemin absolu résolu>"
STAGING_PATH="$HOME/opensource-staging/${NOM_PROJET}"
Demander à l'utilisateur :
- "Quel projet ?" (si non trouvé)
- "Licence ? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
- "Organisation ou nom d'utilisateur GitHub ?" (par défaut : détecter via
gh api user -q .login) - "Nom du dépôt GitHub ?" (par défaut : nom du projet)
- "Description pour le README ?" (analyser le projet pour suggestion)
Étape 2 : Créer le répertoire de préparation
mkdir -p $HOME/opensource-staging/
Étape 3 : Exécuter l'agent Forker
Lancer l'agent opensource-forker :
Agent(
description="Fork {PROJET} pour open-source",
subagent_type="opensource-forker",
prompt="""
Fork le projet pour une publication open-source.
Source : {SOURCE_PATH}
Cible : {STAGING_PATH}
Licence : {licence_choisie}
Suivre le protocole complet de fork :
1. Copier les fichiers (exclure .git, node_modules, __pycache__, .venv)
2. Supprimer tous les secrets et informations d'identification
3. Remplacer les références internes par des espaces réservés
4. Générer .env.example
5. Nettoyer l'historique git
6. Générer FORK_REPORT.md dans {STAGING_PATH}/FORK_REPORT.md
"""
)
Attendre la fin. Lire {STAGING_PATH}/FORK_REPORT.md.
Étape 4 : Exécuter l'agent Sanitizer
Lancer l'agent opensource-sanitizer :
Agent(
description="Vérifier la sanitisation de {PROJET}",
subagent_type="opensource-sanitizer",
prompt="""
Vérifier la sanitisation du fork open-source.
Projet : {STAGING_PATH}
Source (pour référence) : {SOURCE_PATH}
Exécuter TOUTES les catégories de scan :
1. Scan des secrets (CRITIQUE)
2. Scan des PII (CRITIQUE)
3. Scan des références internes (CRITIQUE)
4. Vérification des fichiers dangereux (CRITIQUE)
5. Complétude de la configuration (AVERTISSEMENT)
6. Audit de l'historique git
Générer SANITIZATION_REPORT.md dans {STAGING_PATH}/ avec verdict PASS/FAIL.
"""
)
Attendre la fin. Lire {STAGING_PATH}/SANITIZATION_REPORT.md.
Si ÉCHEC : Présenter les résultats à l'utilisateur. Demander : "Corriger ces problèmes et relancer le scan, ou abandonner ?"
- Si corriger : Appliquer les corrections, relancer le sanitizer (maximum 3 tentatives — après 3 ÉCHEC, présenter tous les résultats et demander à l'utilisateur de corriger manuellement)
- Si abandonner : Nettoyer le répertoire de préparation
Si RÉUSSI ou RÉUSSI AVEC AVERTISSEMENTS : Passer à l'Étape 5.
Étape 5 : Exécuter l'agent Packager
Lancer l'agent opensource-packager :
Agent(
description="Empaqueter {PROJET} pour open-source",
subagent_type="opensource-packager",
prompt="""
Générer l'empaquetage open-source pour le projet.
Projet : {STAGING_PATH}
Licence : {licence_choisie}
Nom du projet : {NOM_PROJET}
Description : {description}
Dépôt GitHub : {depot_github}
Générer :
1. CLAUDE.md (commandes, architecture, fichiers clés)
2. setup.sh (bootstrap en une commande, rendre exécutable)
3. README.md (ou améliorer l'existant)
4. LICENCE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
"""
)
Étape 6 : Révision finale
Présenter à l'utilisateur :
Fork Open-Source Prêt : {NOM_PROJET}
Emplacement : {STAGING_PATH}
Licence : {licence}
Fichiers générés :
- CLAUDE.md
- setup.sh (exécutable)
- README.md
- LICENCE
- CONTRIBUTING.md
- .env.example ({N} variables)
Sanitisation : {verdict_sanitisation}
Prochaines étapes :
1. Réviser : cd {STAGING_PATH}
2. Créer le dépôt : gh repo create {org_github}/{depot_github} --public
3. Pousser : git remote add origin ... && git push -u origin main
Procéder à la création GitHub ? (oui/non/réviser d'abord)
Étape 7 : Publication GitHub (sur approbation de l'utilisateur)
cd "{STAGING_PATH}"
gh repo create "{org_github}/{depot_github}" --public --source=. --push --description "{description}"
/opensource verify PROJET
Exécuter le sanitizer indépendamment. Résoudre le chemin : si PROJET contient /, le traiter comme un chemin. Sinon vérifier $HOME/opensource-staging/PROJET, puis $HOME/PROJET, puis le répertoire courant.
Agent(
subagent_type="opensource-sanitizer",
prompt="Vérifier la sanitisation de : {chemin_resolu}. Exécuter les 6 catégories de scan et générer SANITIZATION_REPORT.md."
)
/opensource package PROJET
Exécuter le packager indépendamment. Demander "Licence ?" et "Description ?", puis :
Agent(
subagent_type="opensource-packager",
prompt="Empaqueter : {chemin_resolu} ..."
)
/opensource list
ls -d $HOME/opensource-staging/*/
Afficher chaque projet avec l'avancement du pipeline (présence de FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md).
/opensource status PROJET
cat $HOME/opensource-staging/${PROJET}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJET}/FORK_REPORT.md
Structure de préparation
$HOME/opensource-staging/
mon-projet/
FORK_REPORT.md # De l'agent forker
SANITIZATION_REPORT.md # De l'agent sanitizer
CLAUDE.md # De l'agent packager
setup.sh # De l'agent packager
README.md # De l'agent packager
.env.example # De l'agent forker
... # Fichiers du projet nettoyés
Anti-patrons
- Ne jamais pousser sur GitHub sans approbation de l'utilisateur
- Ne jamais sauter le sanitizer — c'est la porte de sécurité
- Ne jamais continuer après un ÉCHEC du sanitizer sans corriger tous les problèmes critiques
- Ne jamais laisser
.env,*.pemoucredentials.jsondans le répertoire de préparation
Bonnes pratiques
- Toujours exécuter le pipeline complet (fork → sanitize → package) pour les nouvelles versions
- Le répertoire de préparation persiste jusqu'à nettoyage explicite — l'utiliser pour réviser
- Relancer le sanitizer après toute correction manuelle avant publication
- Paramétrer les secrets plutôt que de les supprimer — préserver la fonctionnalité du projet
Compétences connexes
Voir security-review pour les motifs de détection de secrets utilisés par le sanitizer.