Avant de Construire

Faites un pré-mortem compact avant l'implémentation. L'objectif n'est pas de bloquer la construction ; c'est d'identifier l'hypothèse à plus haut risque, l'étape de validation la plus minime, et la portée de développement qui devrait être reportée jusqu'à ce que les preuves s'améliorent.

Quand l'utiliser

Utilisez cette skill quand un utilisateur demande de construire ou de déployer :

• Un nouveau produit, MVP, prototype, landing page, app SaaS, marketplace, site de contenu, workflow agent, ou outil interne
• Une feature majeure avec une adoption, revenus, retention, confiance, ou impact de distribution peu clairs
• Un asset de lancement public où un positionnement faible pourrait gaspiller l'effort de développement ou de promotion

Ignorez cette skill quand la tâche est un correctif d'implémentation étroit, une refonte, une réparation de test, une mise à jour de dépendance, ou un changement déjà validé avec des critères d'acceptation clairs.

Checklist des Risques

Passez en revue l'idée selon ces risques :

• Demande : Y a-t-il une preuve qu'un acheteur ou utilisateur spécifique veut cela urgemment ?
• Positionnement : L'utilisateur cible peut-il comprendre ce que c'est et pourquoi cela importe en une phrase ?
• Monétisation : Y a-t-il un chemin crédible vers le paiement, le budget, ou la valeur stratégique ?
• Retention : Y a-t-il une raison pour que les utilisateurs reviennent après le premier essai ?
• Confiance : Le produit nécessite-t-il une crédibilité, un accès aux données, des intégrations, ou un changement de comportement que les utilisateurs pourraient rejeter ?
• Distribution : Y a-t-il un moyen reproductible d'atteindre l'utilisateur cible ?
• Adoption de feature : Pour le travail de feature, celle-ci changera-t-elle le comportement de l'utilisateur ou ajoutera-t-elle juste de la surface ?

Si le verdict n'est pas évident, utilisez references/risk-checklist.md pour des questions plus approfondies.

Format de Sortie

Gardez la réponse courte et orientée vers la décision :

1. Verdict de risque : Faible, moyen, ou haut risque, avec une phrase expliquant pourquoi.
2. Hypothèse principale : L'hypothèse unique la plus susceptible de casser le projet.
3. Preuve à trouver d'abord : Le plus petit signal utile avant de construire davantage.
4. À faire ensuite : Une étape de validation concrète ou une portée de construction réduite.
5. Reporter : Ce qu'il ne faut pas encore construire.

Conseils

• Soyez direct sur les preuves faibles, mais évitez de rejeter l'idée de l'utilisateur.
• Préférez les étapes de validation plus petites aux grands plans de recherche.
• Séparez le risque produit de la difficulté d'ingénierie.
• Si l'idée est déjà validée, dites quelle preuve la rend moins risquée et suggérez la plus petite tranche d'implémentation.
• Si des faits manquent, nommez la preuve manquante au lieu d'inventer des allégations de marché.