Que fait Optimiseur de Prompts ?
Analyse un brouillon de prompt, le critique, le fait correspondre aux composants de l'écosystème ECC et produit un prompt optimisé complet que l'utilisateur peut copier-coller et exécuter.
Quand l'utiliser
- L'utilisateur dit "optimise ce prompt", "améliore mon prompt", "réécris ce prompt"
- L'utilisateur dit "aide-moi à écrire un meilleur prompt pour..."
- L'utilisateur dit "quelle est la meilleure façon de demander à Claude Code de..."
- L'utilisateur dit "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
- L'utilisateur colle un brouillon de prompt et demande un retour ou une amélioration
- L'utilisateur dit "je ne sais pas comment formuler un prompt pour ça"
- L'utilisateur dit "comment utiliser ECC pour..."
- L'utilisateur invoque explicitement
/prompt-optimize
Ne pas utiliser quand
- L'utilisateur veut que la tâche soit exécutée directement (exécutez-la simplement)
- L'utilisateur dit "优化代码", "优化性能", "optimise ce code", "optimise les performances" — ce sont des tâches de refactorisation, pas d'optimisation de prompt
- L'utilisateur pose une question sur la configuration d'ECC (utiliser
configure-eccà la place) - L'utilisateur veut un inventaire des skills (utiliser
skill-stocktakeà la place) - L'utilisateur dit "fais-le" ou "直接做"
Comment ça marche
Rôle consultatif uniquement — n'exécutez pas la tâche de l'utilisateur.
N'écrivez PAS de code, ne créez PAS de fichiers, n'exécutez PAS de commandes et ne prenez AUCUNE action d'implémentation. Votre SEULE sortie est une analyse plus un prompt optimisé.
Si l'utilisateur dit "fais-le", "直接做" ou "n'optimise pas, exécute juste", ne passez pas en mode implémentation dans ce skill. Dites à l'utilisateur que ce skill produit uniquement des prompts optimisés, et demandez-lui de faire une demande de tâche normale s'il souhaite une exécution.
Exécutez ce pipeline en 6 phases séquentiellement. Présentez les résultats en utilisant le format de sortie ci-dessous.
Pipeline d'analyse
Phase 0 : Détection du projet
Avant d'analyser le prompt, détectez le contexte du projet actuel :
- Vérifiez si un fichier
CLAUDE.mdexiste dans le répertoire de travail — lisez-le pour connaître les conventions du projet - Détectez la stack technique à partir des fichiers du projet :
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin / Spring BootPackage.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- Notez la stack technique détectée pour l'utiliser dans les phases 3 et 4
Si aucun fichier de projet n'est trouvé (par exemple, le prompt est abstrait ou pour un nouveau projet), ignorez la détection et signalez "stack technique inconnue" dans la phase 4.
Phase 1 : Détection de l'intention
Classez la tâche de l'utilisateur dans une ou plusieurs catégories :
| Catégorie | Mots-clés | Exemple |
|---|---|---|
| Nouvelle fonctionnalité | construire, créer, ajouter, implémenter, 创建, 实现, 添加 | "Construire une page de connexion" |
| Correction de bug | corriger, cassé, ne fonctionne pas, erreur, 修复, 报错 | "Corriger le flux d'authentification" |
| Refactorisation | refactoriser, nettoyer, restructurer, 重构, 整理 | "Refactoriser la couche API" |
| Recherche | comment, quoi, explorer, investiguer, 怎么, 如何 | "Comment ajouter le SSO" |
| Test | test, couverture, vérifier, 测试, 覆盖率 | "Ajouter des tests pour le panier" |
| Revue | revoir, auditer, vérifier, 审查, 检查 | "Revoir ma PR" |
| Documentation | documenter, mettre à jour la doc, 文档 | "Mettre à jour la documentation API" |
| Infrastructure | déployer, CI, docker, base de données, 部署, 数据库 | "Configurer le pipeline CI/CD" |
| Conception | concevoir, architecture, planifier, 设计, 架构 | "Concevoir le modèle de données" |
Phase 2 : Évaluation de la portée
Si la phase 0 a détecté un projet, utilisez la taille du code comme signal. Sinon, estimez à partir de la seule description du prompt et marquez l'estimation comme incertaine.
| Portée | Heuristique | Orchestration |
|---|---|---|
| TRIVIAL | Fichier unique, < 50 lignes | Exécution directe |
| FAIBLE | Composant ou module unique | Commande ou skill unique |
| MOYENNE | Plusieurs composants, même domaine | Chaîne de commandes + /verify |
| ÉLEVÉE | Transversal, 5+ fichiers | D'abord /plan, puis exécution par phases |
| ÉPIQUE | Multi-sessions, multi-PR, changement architectural | Utiliser le skill blueprint pour un plan multi-session |
Phase 3 : Correspondance des composants ECC
Faites correspondre l'intention + la portée + la stack technique (de la phase 0) aux composants ECC spécifiques.
Par type d'intention
| Intention | Commandes | Skills | Agents |
|---|---|---|---|
| Nouvelle fonctionnalité | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| Correction de bug | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
| Refactorisation | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
| Recherche | /plan | search-first, iterative-retrieval | — |
| Test | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
| Revue | /code-review | security-review | code-reviewer, security-reviewer |
| Documentation | /update-docs, /update-codemaps | — | doc-updater |
| Infrastructure | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
| Conception (MOYENNE-ÉLEVÉE) | /plan | — | planner, architect |
| Conception (ÉPIQUE) | — | blueprint (invoquer en tant que skill) | planner, architect |
Par stack technique
| Stack technique | Skills à ajouter | Agent |
|---|---|---|
| Python / Django | django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing | python-reviewer |
| Go | golang-patterns, golang-testing | go-reviewer, go-build-resolver |
| Spring Boot / Java | springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns | code-reviewer |
| Kotlin / Android | kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture | kotlin-reviewer |
| TypeScript / React | frontend-patterns, backend-patterns, coding-standards | code-reviewer |
| Swift / iOS | swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing | code-reviewer |
| PostgreSQL | postgres-patterns, database-migrations | database-reviewer |
| Perl | perl-patterns, perl-testing, perl-security | code-reviewer |
| C++ | cpp-coding-standards, cpp-testing | code-reviewer |
| Autre / Non listé | coding-standards (universel) | code-reviewer |
Phase 4 : Détection du contexte manquant
Analysez le prompt à la recherche d'informations critiques manquantes. Vérifiez chaque élément et indiquez si la phase 0 l'a détecté automatiquement ou si l'utilisateur doit le fournir :
- Stack technique — Détectée en phase 0, ou l'utilisateur doit-il la préciser ?
- Portée cible — Fichiers, répertoires ou modules mentionnés ?
- Critères d'acceptation — Comment savoir si la tâche est terminée ?
- Gestion des erreurs — Cas limites et modes de défaillance traités ?
- Exigences de sécurité — Authentification, validation des entrées, secrets ?
- Attentes de test — Tests unitaires, d'intégration, E2E ?
- Contraintes de performance — Charge, latence, limites de ressources ?
- Exigences UI/UX — Spécifications de design, responsive, accessibilité ? (si frontend)
- Modifications de base de données — Schéma, migrations, index ? (si couche données)
- Règles existantes — Fichiers de référence ou conventions à suivre ?
- Limites de la portée — Ce qu'il NE faut PAS faire ?
Si 3 éléments critiques ou plus sont manquants, posez jusqu'à 3 questions de clarification à l'utilisateur avant de générer le prompt optimisé. Intégrez ensuite les réponses dans le prompt optimisé.
Phase 5 : Recommandation de workflow et de modèle
Déterminez où se situe ce prompt dans le cycle de vie du développement :
Recherche → Planification → Implémentation (TDD) → Revue → Vérification → Commit
Pour les tâches MOYENNES+, commencez toujours par /plan. Pour les tâches ÉPIQUES, utilisez le skill blueprint.
Recommandation de modèle (à inclure dans la sortie) :
| Portée | Modèle recommandé | Justification |
|---|---|---|
| TRIVIAL-FAIBLE | Sonnet 4.6 | Rapide, économique pour les tâches simples |
| MOYENNE | Sonnet 4.6 | Meilleur modèle de codage pour le travail standard |
| ÉLEVÉE | Sonnet 4.6 (principal) + Opus 4.6 (planification) | Opus pour l'architecture, Sonnet pour l'implémentation |
| ÉPIQUE | Opus 4.6 (blueprint) + Sonnet 4.6 (exécution) | Raisonnement profond pour la planification multi-session |
Découpage en plusieurs prompts (pour portée ÉLEVÉE/ÉPIQUE) :
Pour les tâches qui dépassent une seule session, découpez en prompts séquentiels :
- Prompt 1 : Recherche + Planification (utiliser le skill
search-first, puis/plan) - Prompt 2-N : Implémenter une phase par prompt (chacun se termine par
/verify) - Prompt final : Test d'intégration +
/code-reviewsur toutes les phases - Utiliser
/save-sessionet/resume-sessionpour préserver le contexte entre les sessions
Format de sortie
Présentez votre analyse dans cette structure exacte. Répondez dans la même langue que l'entrée de l'utilisateur.
Section 1 : Diagnostic du prompt
- Points forts : Listez ce que le prompt original fait bien.
- Problèmes :
Problème Impact Correction suggérée (problème) (conséquence) (comment corriger) - Clarifications nécessaires : Liste numérotée des questions auxquelles l'utilisateur devrait répondre. Si la phase 0 a détecté automatiquement la réponse, indiquez-la plutôt que de demander.
Section 2 : Composants ECC recommandés
| Type | Composant | Objectif |
|---|---|---|
| Commande | /plan | Planifier l'architecture avant de coder |
| Skill | tdd-workflow | Guide de méthodologie TDD |
| Agent | code-reviewer | Revue post-implémentation |
| Modèle | Sonnet 4.6 | Recommandé pour cette portée |
Section 3 : Prompt optimisé — Version complète
Présentez le prompt optimisé complet à l'intérieur d'un seul bloc de code délimité. Le prompt doit être autonome et prêt à être copié-collé. Incluez :
- Description claire de la tâche avec contexte
- Stack technique (détectée ou spécifiée)
- Invocations de
/commandaux étapes appropriées du workflow - Critères d'acceptation
- Étapes de vérification
- Limites de la portée (ce qu'il NE faut PAS faire)
Pour les éléments qui font référence à blueprint, écrivez : "Utilisez le skill blueprint pour..." (pas /blueprint, car blueprint est un skill, pas une commande).
Section 4 : Prompt optimisé — Version rapide
Une version compacte pour les utilisateurs expérimentés d'ECC. Varie selon le type d'intention :
| Intention | Modèle rapide |
|---|---|
| Nouvelle fonctionnalité | /plan [fonctionnalité]. /tdd pour implémenter. /code-review. /verify. |
| Correction de bug | /tdd — écrire un test qui échoue pour [bug]. Corriger pour passer au vert. /verify. |
| Refactorisation | /refactor-clean [portée]. /code-review. /verify. |
| Recherche | Utiliser le skill search-first pour [sujet]. /plan basé sur les résultats. |
| Test | /tdd [module]. /e2e pour les flux critiques. /test-coverage. |
| Revue | /code-review. Puis utiliser l'agent security-reviewer. |
| Documentation | /update-docs. /update-codemaps. |
| ÉPIQUE | Utiliser le skill blueprint pour "[objectif]". Exécuter les phases avec des portes /verify. |
Section 5 : Justification des améliorations
| Amélioration | Raison |
|---|---|
| (ce qui a été ajouté) | (pourquoi c'est important) |
Exemples
Exemple 1 : Prompt chinois vague (Projet détecté)
Entrée utilisateur : 帮我写一个用户登录页面
Phase 0 détecte : package.json avec Next.js 15, TypeScript, Tailwind CSS
Prompt optimisé (Complet) :
Utiliser la stack technique existante du projet (Next.js 15 + TypeScript + Tailwind CSS) pour implémenter une page de connexion utilisateur.
Exigences techniques :
- Suivre la structure de composants et les conventions de routage existantes du projet
- Validation de formulaire en utilisant la solution existante dans le projet (vérifier si Zod/Yup/autre est déjà utilisé)
- Méthode d'authentification : utiliser le schéma d'authentification existant du projet (par défaut, JWT si aucun)
- Inclure : formulaire de connexion email/mot de passe, validation de formulaire, messages d'erreur, état de chargement, mise en page responsive
Workflow :
1. /plan pour planifier la structure des composants et le flux d'authentification, en se référant aux modèles des pages existantes
2. /tdd d'abord les tests : écrire des tests unitaires pour le formulaire de connexion et des tests d'intégration pour le flux d'authentification
3. Implémenter la page de connexion et la logique d'authentification
4. /code-review pour examiner l'implémentation
5. /verify pour vérifier que tous les tests passent et que la page s'affiche correctement
Exigences de sécurité :
- Le mot de passe ne doit pas être transmis en clair
- Protection contre les attaques par force brute (rate limiting)
- Protection XSS
- Token CSRF
Critères d'acceptation :
- Tous les tests passent, couverture 80%+
- La page s'affiche correctement sur mobile et desktop
- Connexion réussie : redirection vers le tableau de bord, échec : affichage d'un message d'erreur
Ne pas faire :
- Ne pas implémenter de page d'inscription
- Ne pas implémenter la fonctionnalité "mot de passe oublié"
- Ne pas modifier la structure de routage existante