Compétence Pipeline Open-Source
Rendre 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 veut préparer un dépôt privé pour le publier
- L'utilisateur doit supprimer les 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 staging |
/opensource status PROJET | Afficher les rapports d'un projet en staging |
Protocole
/opensource fork PROJET
Pipeline complet — le workflow principal.
Étape 1 : Récupérer 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 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 une suggestion)
Étape 2 : Créer le répertoire de staging
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="""
Forker le projet pour une publication open-source.
Source : {SOURCE_PATH}
Cible : {STAGING_PATH}
Licence : {licence_choisie}
Suivre le protocole complet de forking :
1. Copier les fichiers (exclure .git, node_modules, __pycache__, .venv)
2. Supprimer tous les secrets et identifiants
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 le nettoyage de {PROJET}",
subagent_type="opensource-sanitizer",
prompt="""
Vérifier le nettoyage 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 données personnelles (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.
En cas d'échec (FAIL) : Montrer les résultats à l'utilisateur. Demander : "Corriger ces problèmes et relancer le scan, ou abandonner ?"
- Si correction : Appliquer les corrections, relancer le sanitizer (maximum 3 tentatives — après 3 échecs, présenter tous les résultats et demander à l'utilisateur de corriger manuellement)
- Si abandon : Nettoyer le répertoire de staging
En cas de réussite (PASS) ou PASS AVEC AVERTISSEMENTS : Passer à l'étape 5.
Étape 5 : Exécuter l'agent Packager
Lancer l'agent opensource-packager :
Agent(
description="Conditionner {PROJET} pour open-source",
subagent_type="opensource-packager",
prompt="""
Générer le conditionnement 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, le 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)
Nettoyage : {verdict_nettoyage}
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 (après 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 le nettoyage 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="Conditionner : {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 du staging
$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 staging
Bonnes pratiques
- Toujours exécuter le pipeline complet (fork → sanitize → package) pour les nouvelles versions
- Le répertoire de staging persiste jusqu'à nettoyage explicite — l'utiliser pour la révision
- 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 associées
Voir security-review pour les modèles de détection de secrets utilisés par le sanitizer.