TL;DR en langage simple
- Objectif : déployer rapidement une boîte à outils « growth skills » pour votre dépôt, tirée de l'exemple public : https://github.com/marketingskills/open-source-growth.
- Ce que vous obtenez : audit priorisé, suggestions README, démo exécutable (dossier demo/ + Dockerfile ou config Codespaces), launch-pack/checklist.md et templates de PRs d'écosystème — tous présents comme exemples dans le repo : https://github.com/marketingskills/open-source-growth.
- Démarrage en 3 étapes : cloner le repo, copier la config d'exemple et ajouter 2 secrets (clé API modèle + GitHub PAT), lancer le skill d'audit pour générer audit-report.md. Voir scripts et runners d'exemple dans le dépôt : https://github.com/marketingskills/open-source-growth.
Méthode rapide : privilégiez les 3 premiers items de l'audit, ouvrez des PRs petites (<200 lignes) et exigez une revue humaine. Référence : https://github.com/marketingskills/open-source-growth.
Ce que vous allez construire et pourquoi c'est utile
Vous allez assembler 3–5 "skills" simples depuis l'exemple : repo-audit, README upgrade, demo builder, launch-pack, templates PR. Le dépôt centralise modèles et workflows et sert de source d'exemples pratiques : https://github.com/marketingskills/open-source-growth.
Livrables et impact attendu :
| Livrable | Objectif | Seuil/contrainte pratique | |---|---:|---:| | audit-report.md | Prioriser actions | Traiter 3 premiers items / semaine | | README upgrade PRs | Meilleure découverte | PRs de 1–5 fichiers, <200 lignes | | demo/ + Dockerfile | Essayer le projet localement | Temps d'exécution cible <5 minutes | | launch-pack/checklist.md | Préparer annonce | Préparation 30–60 minutes | | templates PR écosystème | Augmenter visibilité | Throttle 1 PR/jour max |
Pourquoi utile : réduit la friction d'onboarding, produit livrables actionnables et permet itérations contrôlées. Tous les templates et scripts d'exemple sont fournis dans le repo : https://github.com/marketingskills/open-source-growth.
Avant de commencer (temps, cout, prerequis)
Prérequis (vérifiez les fichiers d'exemple dans le repo) : https://github.com/marketingskills/open-source-growth
- Un dépôt GitHub où ouvrir des PRs (public ou interne).
- Un GitHub Personal Access Token (PAT) stocké dans GitHub Secrets.
- Une clé API pour le modèle d'IA, stockée dans GitHub Secrets.
- Copier le projet d'exemple : git clone https://github.com/marketingskills/open-source-growth.git
Estimations et limites :
- Durée d'installation initiale : 2–4 heures.
- Coût indicatif d'exécution : $5–$50 / jour selon le volume d'invocations.
- Taille d'équipe cible de démarrage : 1–3 personnes.
Checklist initiale :
- [ ] Cloner le repo : git clone https://github.com/marketingskills/open-source-growth.git
- [ ] Créer un GitHub PAT et le stocker en secret (limiter les scopes)
- [ ] Ajouter la clé API du modèle dans les secrets
- [ ] Copier skills/example-skills.yaml → skills/skills.yaml et adapter
Sécurité rapide : stocker PAT et clés uniquement dans GitHub Secrets ; limiter scopes et planifier rotation tous les 30–90 jours. Voir exemples et recommandations dans le repo : https://github.com/marketingskills/open-source-growth.
Installation et implementation pas a pas
- Cloner le dépôt et l'inspecter (scripts et exemples inclus) : https://github.com/marketingskills/open-source-growth
git clone https://github.com/marketingskills/open-source-growth.git
cd open-source-growth
ls -la
- Copier la configuration d'exemple et remplir les champs essentiels (model.name, api_key_secret, github.repo, pat_secret) : https://github.com/marketingskills/open-source-growth
cp skills/example-skills.yaml skills/skills.yaml
# puis éditez skills/skills.yaml
Extrait d'exemple à adapter :
# skills/skills.yaml (fragment d'exemple)
model:
name: "votre-model" # champ attendu par les templates
max_tokens: 2048
github:
repo: "votre-org/votre-repo"
pat_secret: "GITHUB_PAT"
- Lancer le skill d'audit pour produire audit-report.md. Le dépôt contient un runner et des scripts d'exemple : https://github.com/marketingskills/open-source-growth
./scripts/run-audit.sh --config skills/skills.yaml --out audit-report.md
# ou
python tools/run_skill.py audit --config skills/skills.yaml --output audit-report.md
-
Lire audit-report.md et traiter les 3 premiers items. Recommandation : PRs petites (1–5 fichiers, <200 lignes) et revue humaine avant merge.
-
Lancer README upgrade puis demo builder ; valider la démo localement ou dans Codespaces (objectif <5 minutes par exécution). Pour automatiser, adaptez .github/workflows/agent-apply.yml fourni dans le repo : https://github.com/marketingskills/open-source-growth.
Problemes frequents et correctifs rapides
- PRs hors-sujet ou trop verbeuses
- Action : resserrer les prompts dans skills/skills.yaml et exiger un label d'approbation humaine.
- Hallucinations du modèle sur du code
- Action : ajouter tests CI bloquants + revue humaine + limiter diffs <200 lignes.
- Erreurs API et limites de débit
- Action : retry/backoff (3 tentatives, backoff 500 ms) et logs. Le repo montre des patterns d'exemple : https://github.com/marketingskills/open-source-growth.
- Trop de petites PRs (bruit)
- Action : regrouper changements, appliquer throttling (1 PR/jour) et valider dans un repo canary.
Exemple JSON de retry à adapter :
{ "retry": { "attempts": 3, "backoff_ms": 500 } }
Checklist de remédiation immédiate :
- [ ] Resserrez les prompts avec exemples explicites
- [ ] Ajoutez checks CI qui bloquent les merges (seuil tests = 95% réussite recommandé)
- [ ] Activez un label d'approbation humaine pour les premières exécutions
- [ ] Testez d'abord dans un repo canary (fenêtre 24–72 heures)
Référence : https://github.com/marketingskills/open-source-growth.
Premier cas d'usage pour une petite equipe
Contexte : un·e fondateur·rice solo ou une petite équipe (1–3 personnes) veut augmenter l'adoption sans alourdir la maintenance. Le repo d'exemple fournit modèles, scripts et workflows : https://github.com/marketingskills/open-source-growth.
Conseils concrets et actionnables pour solo founders / petites équipes (au moins 3 points) :
- Prioriser et limiter le périmètre — Exécutez l'audit et ne traitez que les 3 premiers items la première semaine. Objectif : 3 tâches priorisées, 1–2 PRs par semaine.
- PRs petites + revue humaine — Gardez chaque PR à 1–5 fichiers ou <200 lignes ; exigez qu'une autre personne (ou vous-même après 24–72 heures) valide avant merge.
- Canary et throttling — Testez d'abord dans un repo canary : limiter les runs à ≤10 exécutions/jour pendant la phase d'essai; passez à 10–50 runs sur 1–2 semaines si ça se révèle stable.
- Automatiser les répétitions simples — Utilisez les workflows fournis (.github/workflows) pour exécuter les tâches récurrentes, mais bloquez la fusion automatique tant que les checks CI ne sont pas passés à ≥95%.
- Déléguer et documenter — Documentez le processus dans CONTRIBUTING.md (5–10 minutes de lecture) et définissez un label d'approbation humaine pour les PRs générées.
Checklist opérationnelle pour une petite équipe :
- [ ] Exécuter l'audit et prioriser les 3 premiers items
- [ ] Ouvrir PRs petites et ciblées (1–5 fichiers, <200 lignes)
- [ ] Valider la démo localement ou via Codespaces (objectif <5 minutes)
- [ ] Exécuter canary avec ≤10 runs/jour pendant 7–14 jours
Indicateurs simples à suivre : taux de merge des PRs générées, succès de la démo (exécutions), évolution des étoiles/traffic GitHub. Voir exemples dans le repo : https://github.com/marketingskills/open-source-growth.
Notes techniques (optionnel)
- Le repo attend des champs comme model.name et model.max_tokens (ex. 2048) dans skills/skills.yaml ; adaptez ces valeurs selon votre fournisseur : https://github.com/marketingskills/open-source-growth.
- Secrets : stockez PAT et clés API dans GitHub Secrets ; limitez les scopes au minimum (écriture PR, accès repo) et planifiez rotation tous les 30–90 jours.
- Observabilité : conservez logs des runs ; alertez si >5 erreurs en 1 heure ou si latence API moyenne >500 ms.
Exemples de config à adapter (référence dans le repo) :
model:
name: "votre-model"
max_tokens: 2048
github:
repo: "votre-org/votre-repo"
pat_secret: "GITHUB_PAT"
{ "retry": { "attempts": 3, "backoff_ms": 500 } }
Référence technique : https://github.com/marketingskills/open-source-growth.
Que faire ensuite (checklist production)
Hypotheses / inconnues
- Hypothèse : temps d'installation initial = 2–4 heures.
- Hypothèse : équipe de rollout = 1–3 mainteneurs.
- Hypothèse de tuning initial : model.max_tokens = 2048, retry.attempts = 3, retry.backoff_ms = 500.
- Hypothèse de cadence : 1 PR automatisée par jour (throttle), fenêtre canary = 24–72 heures.
- Hypothèse budgétaire : $5–$50 par jour selon volume.
- Hypothèse tests/merge : seuil de réussite des tests pour merge = 95%.
Risques / mitigations
- Risque : PRs avec code incorrect ou hallucinations.
- Mitigation : tests CI bloquants + revue humaine + limiter diffs <200 lignes.
- Risque : fuite de secrets.
- Mitigation : restreindre scopes du PAT, stocker dans GitHub Secrets, rotation 30–90 jours.
- Risque : volume excessif de PRs (bruit).
- Mitigation : throttling (1 PR/jour), batching, validation dans repo canary (24–72 heures).
Prochaines etapes
- Adapter skills/skills.yaml et .github/workflows/agent-apply.yml à votre dépôt en vous basant sur les exemples du repo : https://github.com/marketingskills/open-source-growth
- Mettre en place politique de revue (label d'approbation) et checks CI bloquants (seuil 95%).
- Lancer exécutions canary (10–50 runs sur 1–2 semaines), collecter métriques (taux de merge, succès demo, erreurs), ajuster thresholds.
- Documenter le processus dans CONTRIBUTING.md pour expliquer comment l'équipe traite les PRs générées par l'agent.
Référence finale : copier et adapter les templates et la checklist depuis https://github.com/marketingskills/open-source-growth.