Validateur d'idée commerciale

Que fait Validateur d'idée commerciale ?

Utilisation : /business-idea-validator <texte de l'idée ou chemin vers un fichier> [--lang fr|en|pl] [--quick] [--out <dossier>]

Évalue une idée commerciale selon dix rubriques, applique une règle de verdict fixe et rédige un rapport. Le jugement réside dans les scores et leur justification ; le verdict est un calcul arithmétique basé sur les scores, garantissant un traitement équitable entre deux idées et vérifiable manuellement.

Exécutez-le depuis le répertoire de travail de votre choix (option --out <dossier>, par défaut le répertoire courant). N'écrivez jamais dans le dossier de cette compétence.

Fichiers que vous utiliserez

• references/rubrics/01-problem.md … 10-risks.md : un fichier par rubrique. Lisez celui que vous évaluez.
• references/report-style.md : règles de rédaction. À lire une fois avant toute évaluation.
• references/intake.md : quand poser d'abord des questions au fondateur.
• references/verdict.md : la règle, pour votre compréhension ; le code se trouve dans scripts/verdict.mjs.
• assets/rubric-output.schema.json : le schéma JSON exact qu'une passe de rubrique doit retourner.
• assets/report.schema.json : le rapport complet.
• assets/examples/fieldnote/ : un exemple complet (idée fictive) avec idea.md, report.json, report.md.
• scripts/check.mjs : valide, calcule le verdict et génère le Markdown. ${CLAUDE_SKILL_DIR} pointe vers ce dossier dans Claude Code ; ailleurs, utilisez le chemin d'installation de la compétence.

Étapes

1. Collecte

Prenez l'idée à partir de l'argument, de l'invite ou d'un chemin de fichier. Déterminez la langue du rapport : la langue du texte de l'idée, sauf indication contraire via --lang.

Appliquez references/intake.md. Si le texte est trop court (moins de 40 mots environ, ou s'il manque le public cible, la description de ce qu'il fait ou la manière dont il génère des revenus), posez une seule fois jusqu'à cinq questions au fondateur en un seul message, puis attendez. Si vous ne pouvez pas poser de questions (mode non interactif ou option --quick), continuez avec des hypothèses et mentionnez-le dans synthesis.notes.

Stockez ce que vous avez sous idea.text et idea.answers (for, money, today, advantage, stage ; uniquement ceux fournis).

2. Évaluez les dix rubriques

Lisez d'abord references/report-style.md. Ensuite, pour chaque rubrique dans l'ordre problem, customer, market, alternatives, monetization, distribution, feasibility, moat, founder, risks :

• Fournissez le texte de l'idée, les réponses, le fichier de la rubrique, les règles de style et le schéma de sortie.
• La passe retourne un objet JSON correspondant à assets/rubric-output.schema.json : id, score de 1 à 5, confidence bas/moyen/élevé, evidence (citations exactes), assumptions, reasoning (au maximum 160 mots), questions, improve.

Exécutez les passes en parallèle via le sous-agent business-idea-rubric si l'outil Agent est disponible (un agent par rubrique, briefez-le avec les chemins des fichiers et l'idée ; demandez-lui de retourner uniquement le JSON). Sinon, évaluez-les vous-même, une rubrique à la fois, en relisant le fichier de la rubrique à chaque fois pour garder les points d'ancrage sous les yeux.

Créez <out>/rubrics/ et enregistrez les dix résultats sous <id>.json au fur et à mesure. Validez chacun : node ${CLAUDE_SKILL_DIR}/scripts/check.mjs --rubric <out>/rubrics/<id>.json. Corrigez tout problème signalé (généralement une liste trop longue ou un raisonnement dépassant 120 mots) avant de passer à la suite.

3. Passe critique

Ignorez avec --quick. Sinon, donnez au sous-agent business-idea-critic (ou faites-le vous-même) les dix résultats, l'idée et les fichiers de rubriques. Son travail : tenter de réfuter chaque score de 1, 2 ou 5 en utilisant les points d'ancrage et le texte, et signaler toute rubrique où la confiance ne correspond pas à la stabilité du score. Il retourne { "changes": [{ "id", "from", "to", "confidence", "why" }], "notes": "" } où confidence est same ou le nouveau niveau ; why et notes sont dans la langue du rapport. Appliquez chaque changement au résultat de la rubrique : modifiez le score et la confiance, et réécrivez le reasoning de cette rubrique pour défendre le nouveau score (un résultat ne doit pas se contredire). Conservez l'objet critique pour le rapport.

4. Synthèse

Avec les scores finaux, écrivez l'objet de synthèse (assets/report.schema.json, synthesis) : summary (trois phrases), riskiestAssumption (une), experiments (une à trois, 14 jours maximum, chacune avec une métrique numérique), pivots (uniquement les vrais pivots ; vide est acceptable), openQuestions (les questions des rubriques, dédupliquées, des plus importantes aux moins importantes, au maximum huit), notes (comment le rapport a été réalisé lorsque c'est pertinent, sinon vide). Suivez les règles de synthèse dans references/report-style.md.

5. Assemblez et générez

Écrivez <out>/report.json avec version: "1", lang, idea, rubrics (les dix), critic (si exécutée), synthesis, verdict: {} (le script le remplit ; n'écrivez jamais un verdict à la main), meta (model : le modèle que vous utilisez tel que vous le connaissez, createdAt : date ISO, generator : "skill").

Exécutez node ${CLAUDE_SKILL_DIR}/scripts/check.mjs <out>/report.json. Il valide tout, écrit le verdict dans le fichier et génère <out>/report.md. Corrigez les problèmes jusqu'à ce qu'il affiche OK.

6. Remettez le rapport

Dites à l'utilisateur : le verdict et la règle qui l'a produit, l'hypothèse la plus risquée, la première expérience, et l'emplacement des deux fichiers. Limitez-vous à dix lignes ; le rapport contient le reste. Ne répétez pas la grille de scores dans le chat.

Règles qui prévalent sur tout ce qui précède

• Citez textuellement, ne paraphrasez pas, dans evidence. Tout ce qui ne figure pas dans le texte est une hypothèse et doit être étiqueté comme tel.
• Pas de chiffres inventés. Les tailles de marché et les prix sont exprimés sous la forme "en supposant …" avec une fourchette.
• Le verdict provient de scripts/check.mjs. Ne l'écrivez jamais à la main et ne le contestez jamais dans le rapport ; s'il semble erroné, c'est qu'un score est erroné, corrigez le score avec une raison.
• La langue du rapport suit le texte de l'idée (ou --lang). Les clés JSON restent en anglais.
• Style : phrases courtes, pas de tirets cadratins, pas d'exagération, pas de "non seulement X mais aussi Y".