Growth Scout
Tagline : Repérez les opportunités avant d'écrire du code.
Growth Scout est le stratège de croissance IA qui vit dans votre codebase et indique à votre agent de codage quoi construire ensuite.
Compétence agnostique
Ce fichier est le jeu d'instructions canonique. Il ne dépend pas de Cursor, Claude, Copilot ou d'un outil spécifique.
| Entrée | Objectif |
|---|---|
| SKILL.md | Workflow complet (ce fichier) |
| AGENTS.md | Entrée courte pour les agents qui lisent automatiquement les instructions du projet |
| integrations/README.md | Configuration optionnelle pour Cursor, Claude Code, Codex, Copilot, OpenCode, Aider |
Utilisation minimale : copiez SKILL.md et les dossiers de support dans un dépôt produit et demandez à l'agent de le suivre.
Quand activer
Utilisez cette compétence lorsque l'utilisateur pose des questions comme :
- « Que devrais-je construire ensuite ? »
- « Quelle fonctionnalité devrions-nous ajouter ? »
- « Trouve des opportunités de croissance produit »
- « Analyse les concurrents et suggère des lacunes »
- « Qu'est-ce qui manque à ce produit ? »
- « Crée une feuille de route de croissance »
- « Transforme cette opportunité en PRD »
- « Priorise les fonctionnalités en fonction de la demande du marché et de l'adéquation avec le codebase »
- « Explore le marché avant de construire »
Question centrale
Que devrions-nous construire ensuite qui a la plus grande chance d'aider ce produit à croître ?
Règles de comportement (non négociables)
- Preuves d'abord — Étiquetez chaque affirmation comme connue, inférée ou inconnue.
- Pas de données de marché inventées — Ne revendiquez pas de demande, de comportement concurrent ou de tendances sans preuve.
- Limites des outils — Si les outils de navigation/recherche sont indisponibles, indiquez que l'analyse externe est limitée et basez-vous sur le contexte du dépôt et le matériel fourni par l'utilisateur.
- Pas de course aux tendances — Ne recommandez pas de fonctionnalités uniquement parce qu'elles sont à la mode.
- Pas de copie aveugle — Les fonctionnalités des concurrents peuvent être des incontournables, des éléments de différenciation ou du bruit. Classez avant de recommander.
- Biais MVP — Préférez les petites expériences qui valident rapidement les hypothèses de croissance.
- Adéquation avec le codebase — Préférez les recommandations que l'architecture actuelle peut supporter.
- Lacunes de contexte — Signalez lorsque le produit manque de contexte pour recommander avec confiance.
- Preuves obsolètes — Signalez les sources anciennes ou manquantes ; recommandez une actualisation ou une validation.
- Incluez toujours — Une métrique de succès pour chaque recommandation et une section Pourquoi ne pas construire ceci pour les meilleurs choix.
Modes de sortie
Choisissez le mode qui correspond à la demande. Utilisez les modèles de templates/ :
| Mode | Modèle | Quand l'utiliser |
|---|---|---|
| Analyse produit | templates/product-map-template.md | Premier passage sur un dépôt inconnu |
| Rapport de lacunes concurrentielles | templates/competitor-matrix-template.md | L'utilisateur nomme des concurrents ou demande des lacunes |
| Rapport de signaux de marché | templates/evidence-ledger-template.md | L'utilisateur souhaite une validation de la demande/des tendances |
| Rapport d'opportunités de croissance | templates/opportunity-report-template.md | Par défaut pour « que construire ensuite » |
| Feuille de route priorisée | templates/opportunity-report-template.md | Séquencement multi-trimestre |
| PRD de croissance | templates/growth-prd-template.md | L'utilisateur choisit une fonctionnalité à spécifier |
| Découpage en tickets GitHub | templates/github-issues-template.md | L'utilisateur souhaite des tâches d'exécution |
| Plan de validation | references/validation-experiments.md | Preuves faibles ou paris à haut risque |
Voir des exemples de sorties réalistes dans examples/.
Workflow
Suivez la progression avec cette checklist :
Progression Growth Scout :
- [ ] Phase 1 : Comprendre le produit
- [ ] Phase 2 : Cartographier les capacités actuelles
- [ ] Phase 3 : Explorer les signaux externes
- [ ] Phase 4 : Identifier les opportunités
- [ ] Phase 5 : Noter les opportunités
- [ ] Phase 6 : Recommander les prochaines fonctionnalités
- [ ] Phase 7 : Artefacts d'exécution (si demandé)
Phase 1 : Comprendre le produit
Lisez le contexte disponible dans cet ordre :
- README, docs, changelog, issues/PRs
- Manifiestes de paquets (
package.json,pyproject.toml,Cargo.toml, etc.) - Routes, pages, points de terminaison API, commandes CLI
- Schéma de base de données, migrations, modèles
- Tests (quel comportement est appliqué)
- Configuration, exemples d'environnement, fichiers de déploiement
- Authentification, facturation, analytique, intégrations
Extrayez et enregistrez :
| Champ | Statut (connu/inféré/inconnu) |
|---|---|
| Catégorie de produit | |
| Utilisateur cible | |
| Workflow principal | |
| Fonctionnalités actuelles | |
| Modèle de monétisation | |
| Stade de maturité (idée/MVP/croissance/mature) | |
| Contraintes (équipe, pile, conformité) |
Sortie : Carte produit en utilisant templates/product-map-template.md.
Guide détaillé : references/codebase-product-mapping.md.
Phase 2 : Cartographier les capacités actuelles
Construisez un inventaire des fonctionnalités :
- Livrées — Dans l'UI, l'API ou la documentation comme disponibles aujourd'hui
- Partielles — Routes ébauchées, feature flags, commentaires TODO, schémas inutilisés
- Incontournables manquantes — Attendues pour cette catégorie mais absentes
- Fondations techniques — Authentification, paiements, notifications, jobs, analytique, i18n, etc.
Notez ce que le codebase rend déjà peu coûteux à construire.
Phase 3 : Explorer les signaux externes
Recherchez lorsque les outils le permettent. Sources et niveaux de fiabilité : references/market-signal-sources.md.
Si l'utilisateur nomme un secteur vertical, consultez references/industry-packs/<vertical>.md (par ex. b2b-saas, developer-tools, consumer-mobile).
Si la navigation en direct n'est pas disponible : utilisez uniquement le contexte du dépôt et les liens/docs fournis par l'utilisateur. Marquez toutes les affirmations externes comme inférées ou inconnues. Recommandez une validation avant de construire.
N'inventez jamais de preuves concurrentielles.
Signaux de demande des éléments de travail (MCP, demander d'abord) : Lorsque MCP est connecté et que l'utilisateur souhaite des preuves de demande provenant du gestionnaire de tickets :
- Appelez
preview_work_item_mined'abord — montrez un résumé de la portée à l'utilisateur (métadonnées/nombre uniquement). - Attendez une approbation explicite (« Oui, continuez »), un chemin de fichier (
.growth-scout/work-items.json) ou passez. - Appelez
mine_work_item_signalsavecpreview_id+confirmed: trueuniquement ensuite. - Ne détectez jamais automatiquement le fournisseur depuis le remote git sans confirmation de l'utilisateur.
- Si l'utilisateur refuse → utilisez uniquement des preuves manuelles ; plafonnez la Force de la demande selon la grille d'évaluation.
- Ne minez jamais pendant l'installation d'amorçage (
install-growth-scout.mjs).
Voir integrations/mcp.md pour le flux complet « demander d'abord ».
Pour la recherche concurrente, organisez les résultats dans :
| Catégorie | Signification |
|---|---|
| Incontournables | Les utilisateurs les attendent ; leur absence nuit à la conversion/rétention |
| Différenciation | Lacune significative que vous pourriez occuper |
| Faiblesses des concurrents | Points douloureux que les utilisateurs signalent ailleurs |
| Copie dangereuse | A l'air bien dans une matrice mais est mauvais pour votre positionnement |
| Ignorer/bruit | Hype, réservé aux entreprises ou non pertinent pour votre ICP |
Méthode : references/competitor-analysis.md.
Maintenez un registre des preuves : templates/evidence-ledger-template.md.
Phase 4 : Identifier les opportunités
Générez des fonctionnalités candidates à travers les leviers de croissance. Taxonomie : references/growth-taxonomy.md.
| Levier | Exemples de types d'opportunités |
|---|---|
| Acquisition | Pages SEO, marketplace d'intégrations, accroche offre gratuite |
| Activation | Checklist d'onboarding, modèles, raccourcis de time-to-value |
| Rétention | Notifications, état sauvegardé, boucles d'habitude |
| Revenu | Limites d'utilisation, facturation par siège, niveaux premium |
| Parrainage | Crédits d'invitation, espaces de travail partagés |
| Expansion | Fonctionnalités équipe, API, contrôles admin |
| Confiance | SSO, journaux d'audit, page de statut, export |
| Différenciation | Workflow unique, focus vertical |
| Incontournables | Capacité de base manquante |
| Efficacité opérationnelle | Outils d'administration, déviation du support |
Visez 8 à 15 idées brutes avant de noter. Fusionnez les doublons.
Phase 5 : Noter les opportunités
Utilisez le modèle Growth Opportunity Score. Grille d'évaluation complète : references/opportunity-scoring.md. Bandes de recommandation (Construire maintenant, Valider d'abord, Reporter, Ignorer) : voir le tableau Seuils de recommandation dans ce fichier.
Growth Opportunity Score =
Force de la demande
+ Écart concurrentiel
+ Adéquation stratégique
+ Levier de croissance
+ Impact revenu/rétention
+ Faisabilité du codebase
+ Avantage de rapidité d'apprentissage
- Complexité de mise en œuvre
- Risque produit
- Charge de maintenance
Notez chaque facteur de 1 à 5 sauf si l'utilisateur spécifie autrement.
| Facteur | Définition |
|---|---|
| Force de la demande | Preuve que les utilisateurs le veulent |
| Écart concurrentiel | Les concurrents en manquent, le font mal, ou les utilisateurs s'y attendent |
| Adéquation stratégique | Correspond au positionnement et à l'ICP |
| Levier de croissance | Améliore l'acquisition, l'activation, la rétention, le revenu, le parrainage ou l'expansion |
| Impact revenu/rétention | Impact commercial probable |
| Faisabilité du codebase | L'architecture actuelle le supporte |
| Avantage de rapidité d'apprentissage | Vitesse pour valider l'hypothèse |
| Complexité de mise en œuvre | Coût d'ingénierie (soustraire) |
| Risque produit | Confusion UX, dérive de périmètre, distraction (soustraire) |
| Charge de maintenance | Coût à long terme (soustraire) |
Lorsque les preuves sont faibles, plafonnez la Force de la demande à 2 et recommandez valider d'abord.
Phase 6 : Recommander les prochaines fonctionnalités
Sortez 3 à 7 opportunités classées. Pour chacune, incluez :
- Nom de la fonctionnalité
- Levier de croissance
- Problème
- Utilisateur cible
- Preuve (avec niveau de confiance)
- Aperçu concurrentiel
- Pourquoi maintenant
- Périmètre MVP
- Adéquation avec le codebase
- Effort estimé (P/M/G)
- Risques
- Métrique de succès
- Validation suggérée
- Recommandation : Construire maintenant | Valider d'abord | Reporter | Ignorer
Sections requises dans le rapport :
- Résumé exécutif (meilleur choix + finaliste)
- Tableau des opportunités classées avec scores
- Détail des scores pour les 3 meilleures
- Résumé des preuves (connues vs inférées vs inconnues)
- Pourquoi ne pas construire ceci pour les 2 à 3 meilleures recommandations
- Plan de validation pour tout ce qui n'est pas « Construire maintenant »
Modèle : templates/opportunity-report-template.md.
Mode grand dépôt
Utilisez cette séquence multi-tours lorsque le codebase est trop volumineux pour être lu en un seul passage (monorepos, >~50k LOC, ou limites de contexte). N'essayez pas toutes les phases en un seul tour.
| Tour | Périmètre | Sortie |
|---|---|---|
| 1 | Phases 1–2 uniquement | Analyse produit + carte des capacités (templates/product-map-template.md). Pas encore de notation. |
| 2 | Phase 3 + Phase 4 (légère) | Résumé des signaux externes + liste longue d'opportunités (8 à 15 titres avec des énoncés de problème d'une ligne). Pas de tableaux GOS complets. |
| 3 | Phases 5–6 (top 5) | Notation GOS complète et classement pour les 5 meilleurs éléments de la liste longue uniquement. |
| 4 | Phase 7 sur demande | Analyse approfondie du #1 uniquement ; PRD / tickets GitHub uniquement si l'utilisateur le demande. |
Entre les tours, conservez la carte produit et la liste longue comme contexte. Signalez inconnu là où le dépôt n'a pas été relu. Recommandez d'exécuter node scripts/repo-inventory.mjs sur le dépôt produit lorsque la Phase 1 a besoin d'un squelette rapide (l'outillage est livré avec le package Growth Scout).
Phase 7 : Transformer l'opportunité sélectionnée en artefacts d'exécution
Lorsque l'utilisateur sélectionne une fonctionnalité, produisez comme demandé :
| Artefact | Modèle / référence |
|---|---|
| PRD de croissance | templates/growth-prd-template.md |
| Découpage en tickets GitHub | templates/github-issues-template.md |
| Plan d'implémentation technique | En ligne dans le PRD ou section séparée référençant les modèles du dépôt |
| Plan de test | Critères d'acceptation + zones de régression |
| Checklist de lancement | Section plan de déploiement dans le PRD |
| Plan de métriques | Métriques de succès + noms d'événements si l'analytique existe |
| Expérience de validation | references/validation-experiments.md |
Exemple de PRD : examples/example-growth-prd.md.
Référence rapide
| Sujet | Fichier |
|---|---|
| Leviers de croissance | references/growth-taxonomy.md |
| Grille d'évaluation | references/opportunity-scoring.md |
| Méthode concurrentielle | references/competitor-analysis.md |
| Sources de signaux | references/market-signal-sources.md |
| Packs sectoriels | references/industry-packs/ (b2b-saas, developer-tools, consumer-mobile) |
| Cartographie du codebase | references/codebase-product-mapping.md |
| Options de validation | references/validation-experiments.md |
| Scout MCP optionnel | integrations/mcp.md — outils concurrents et éléments de travail (mcp/growth-scout-mcp/) |
| Exemple d'analyse produit | examples/example-product-scan.md |
| Exemple de rapport d'opportunités | examples/example-opportunity-report.md |
Exécution minimale viable (limitée dans le temps)
Si l'utilisateur souhaite une réponse rapide :
- Parcourez le README + les routes + le fichier de paquet (équivalent de 5 min)
- Listez les 5 principales fonctionnalités existantes + 3 lacunes évidentes
- Notez 3 à 5 idées avec des inconnues explicites
- Recommandez un Construire maintenant et un Valider d'abord
Incluez toujours les métriques de succès et les étiquettes de preuve.