Que fait LaunchPad — Idée → Plan validé → Contexte de codage ?
Cette compétence reproduit le pipeline LaunchPadAI sans son backend. Vous jouez chaque agent spécialisé à tour de rôle, écrivez chaque livrable sur disque et alimentez les sorties précédentes dans les suivantes. La valeur du pipeline repose sur trois éléments — gardez-les tous les trois, même lorsque vous abrégez :
- Cadrage spécialisé. Chaque étape a un rôle distinct avec un biais spécifique (le Challengeur d'Hypothèses est sceptique ; le Cartographe d'Opportunités regarde les substituts). Écrire chaque étape séparément, dans son rôle, produit un travail plus précis qu'un seul passage générique « analyse cette idée ».
- Ancrage factuel. Les étapes de recherche utilisent la recherche web et citent les URL. Des concurrents, chiffres de marché ou levées de fonds inventés détruisent la valeur de l'ensemble du plan, car chaque phase aval les hérite. Si la recherche est indisponible ou ne renvoie rien d'utile, dites-le et qualifiez les chiffres d'estimations.
- Continuité contextuelle. Chaque phase lit les documents finaux des phases précédentes. Le PRD doit refléter les personas et les risques identifiés dans la Validation ; l'architecture doit implémenter le périmètre MVP du PRD, pas une application générique.
Phases
| # | Phase | Étapes (→ = dépend de) | Document(s) final(s) | Référence |
|---|---|---|---|---|
| 0 | Découverte | problème → hypothèses → opportunité → brief | BRIEF.md | references/discovery.md |
| 1 | Validation | marché, concurrents, faisabilité, personas (indépendants) → synthèse → benchmark | VALIDATION_REPORT.md, BENCHMARK.md, benchmark.json | references/validation.md |
| 2 | PRD | exigences, user stories (indépendants) → priorisation, flux UX → PRD | PRD.md | references/prd.md |
| 3 | Contexte de codage | architecture, schéma (indépendants) → tâches, fichier de règles → package | CODING_CONTEXT.md + fichier de règles | references/coding-context.md |
Ne lisez que le fichier de référence de la phase que vous exécutez — chacun contient le rôle et le cahier des charges de chaque étape de cette phase.
Pour commencer
- Collectez les entrées du projet. Vous avez besoin de : nom du projet, idée brute (quelques phrases suffisent), et éventuellement domaine, public cible et expérience du fondateur (le benchmark note l'adéquation fondateur-marché — sans expérience, notez prudemment et expliquez pourquoi). Demandez une fois ce qui manque et est important ; n'interrogez pas.
- Décidez du périmètre. Par défaut : exécutez Phase 0 → 1, puis faites une pause. Si l'utilisateur a demandé une phase spécifique (« rédige juste un PRD »), commencez-y — mais vérifiez d'abord l'existence des documents de phase antérieure. S'ils n'existent pas, soit exécutez une version compressée des phases antérieures manquantes (dites-le), soit poursuivez avec la seule idée et signalez dans la sortie quelles entrées ont été supposées plutôt que recherchées.
- Créez l'espace de travail dans le répertoire courant (sauf si l'utilisateur en nomme un autre) :
launchpad/<slug-du-projet/>/
00-decouverte/ problem.md assumptions.md opportunity.md BRIEF.md
01-validation/ market-size.md competitors.md feasibility.md personas.md
VALIDATION_REPORT.md benchmark.json BENCHMARK.md
02-prd/ requirements.md user-stories.md prioritization.md ux-flows.md PRD.md
03-contexte-codage/ architecture.md schema.md tasks.md CLAUDE.md|.cursorrules CODING_CONTEXT.md
project.md name, idea, domain, audience, founder background, feedback log
Écrivez project.md en premier. Si un espace de travail pour ce projet existe déjà, réutilisez-le — lisez ce qui s'y trouve et continuez plutôt que de repartir de zéro.
Exécution d'une étape
Le prompt de chaque étape est conceptuellement :
Projet : <nom> Idée : <idée brute> Domaine / Public (si connu)
--- Contexte de phase antérieure --- documents finaux des phases précédentes (voir ci-dessous)
--- Sorties d'étape précédente --- sorties des étapes dont celle-ci dépend
--- Retour utilisateur --- si réexécution après retour
--- Votre tâche --- rôle + cahier des charges du fichier de référence
Contexte de phase antérieure (remplace la récupération pgvector de la plateforme) :
- La Validation lit
BRIEF.md. - Le PRD lit
BRIEF.md,VALIDATION_REPORT.md,BENCHMARK.md, etpersonas.md. - Le Contexte de codage lit
PRD.mdetfeasibility.md, ainsi queBRIEF.mdpour le périmètre.
Chaque fichier de sortie commence par un en-tête de métadonnées, puis l'analyse complète :
> **Titre :** <la conclusion la plus importante, sous forme d'une phrase complète et spécifique — le « et alors ? », pas le sujet>
>
> **Points clés**
> - <conclusion la plus importante>
> - <deuxième>
> - <troisième> (max 5)
Les documents de synthèse finaux (BRIEF.md, VALIDATION_REPORT.md, PRD.md, CODING_CONTEXT.md) ajoutent également un tableau de bord de 3 à 5 indicateurs dans cet en-tête :
> | Indicateur | Valeur | |
> |---|---|---|
> | Sévérité du problème | 8/10 | 🟢 |
> | Densité concurrentielle | Élevée | 🔴 |
(🟢 fort/positif, 🟡 modéré/incertain, 🔴 faible/préoccupant.) L'en-tête existe pour qu'un lecteur parcourant 20 documents obtienne la conclusion de chacun en cinq secondes.
Étapes de recherche (marquées 🔎 dans les références) : effectuez plusieurs recherches web ciblées — pas une seule requête générique — par ex. noms de concurrents + tarifs, « <problème> reddit », rapports de marché avec années. Citez en ligne comme [1] avec une liste ## Sources d'URL à la fin.
Parallélisme. Les étapes marquées indépendantes peuvent être exécutées comme des sous-agents parallèles si l'outil Agent est disponible — donnez à chaque sous-agent les entrées du projet, les chemins des fichiers de contexte de phase antérieure, sa section du fichier de référence et le chemin de sortie. Sinon, exécutez-les séquentiellement vous-même. Dans les deux cas, les étapes de synthèse ne s'exécutent qu'une fois leurs entrées existantes, et elles lisent les fichiers complets, pas des résumés.
Le score de référence
Après VALIDATION_REPORT.md, écrivez benchmark.json (schéma dans references/validation.md), puis exécutez :
python3 <chemin-compétence>/scripts/benchmark_score.py launchpad/<slug>/01-validation/benchmark.json "<Nom du projet>"
Il recalcule overall_score avec les poids fixes (ainsi les scores sont comparables entre projets et non approximatifs), réécrit le JSON et écrit BENCHMARK.md à côté. Soyez calibré : la plupart des idées se situent entre 4 et 6, au 40e–65e percentile. Un benchmark où tout est 8+ est un signe d'enthousiasme excessif, pas d'analyse.
Entre les phases
Après chaque phase, arrêtez-vous et donnez à l'utilisateur un court résumé dans le chat : le titre du document final, le tableau de bord, le verdict (Validation) et les 2–3 éléments les plus susceptibles de lui faire changer d'avis. Demandez ensuite s'il souhaite continuer, réviser ou s'arrêter. Ne traversez pas les quatre phases sans qu'on vous le demande — un verdict « À repenser » doit être un véritable point de décision, et l'utilisateur peut vouloir pivoter l'idée avant qu'un PRD ne soit rédigé autour d'elle.
Si l'utilisateur donne un retour sur une phase, ajoutez-le au journal des retours dans project.md, réexécutez uniquement les étapes concernées ainsi que l'étape de synthèse de la phase avec le retour en contexte, et écrasez ces fichiers.
Terminer
Lorsque le Contexte de codage est terminé, dites à l'utilisateur quels fichiers copier dans son nouveau dépôt : CODING_CONTEXT.md et le fichier de règles (CLAUDE.md pour Claude Code, .cursorrules pour Cursor, AGENTS.md pour d'autres agents — demandez quel outil il utilise si ce n'est pas clair ; par défaut, CLAUDE.md), ainsi que tasks.md comme backlog de construction.