Optimiseur de Prompt
Analysez un brouillon de prompt, critiquez-le, associez-le aux composants de l'écosystème ECC et produisez un prompt optimisé que l'utilisateur peut copier 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 des retours ou une amélioration
- L'utilisateur dit "je ne sais pas comment formuler le prompt pour ça"
- L'utilisateur dit "comment utiliser ECC pour..."
- L'utilisateur invoque explicitement
/prompt-optimize
Ne pas utiliser quand
- L'utilisateur souhaite que la tâche soit effectué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 des questions sur la configuration d'ECC (utilisez
configure-eccà la place) - L'utilisateur veut un inventaire des compétences (utilisez
skill-stocktakeà la place) - L'utilisateur dit "fais-le" ou "直接做"
Comment ça fonctionne
Conseil 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 de mise en œuvre. Votre SEULE sortie est une analyse plus un prompt optimisé.
Si l'utilisateur dit "fais-le", "直接做" ou "n'optimise pas, exécute simplement", ne passez pas en mode implémentation dans cette compétence. Dites à l'utilisateur que cette compétence ne produit que 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 pile 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 (vérifiez ensuite la présence dequarkusdans le fichier de build → Quarkus, ouspring-boot→ Spring Boot)Package.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- Notez la pile technique détectée pour une utilisation 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), sautez la détection et signalez "pile 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, qu'est-ce que, explorer, étudier, 怎么, 如何 | "Comment ajouter SSO" |
| Test | tester, couverture, vérifier, 测试, 覆盖率 | "Ajouter des tests pour le panier" |
| Révision | réviser, auditer, vérifier, 审查, 检查 | "Réviser 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 de la base de code comme signal. Sinon, estimez à partir de la seule description du prompt et marquez l'estimation comme incertaine.
| Portée | Heuristique | Orchestration |
|---|---|---|
| TRIVIALE | Fichier unique, < 50 lignes | Exécution directe |
| FAIBLE | Composant ou module unique | Commande ou compétence unique |
| MOYENNE | Plusieurs composants, même domaine | Chaîne de commandes + /verify |
| ÉLEVÉE | Transversal, 5+ fichiers | /plan d'abord, puis exécution par phases |
| ÉPIQUE | Multi-sessions, multi-PR, changement architectural | Utiliser la compétence blueprint pour un plan multi-session |
Phase 3 : Correspondance des composants ECC
Faites correspondre l'intention + la portée + la pile technique (de la phase 0) aux composants ECC spécifiques.
Par type d'intention
| Intention | Commandes | Compétences | 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 |
| Révision | /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 (invoquée comme compétence) | planner, architect |
Par pile technique
| Pile technique | Compétences à 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 | java-reviewer |
| Quarkus / Java | quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns | java-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 :
- Pile technique — Détectée en phase 0, ou l'utilisateur doit-il la spécifier ?
- 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 d'échec 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 de données)
- Modèles existants — 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 sont manquants, posez à l'utilisateur jusqu'à 3 questions de clarification avant de générer le prompt optimisé. Incorporez ensuite les réponses dans le prompt optimisé.
Phase 5 : Recommandation du flux de travail et du modèle
Déterminez où ce prompt se situe dans le cycle de vie du développement :
Recherche → Planifier → Implémenter (TDD) → Réviser → Vérifier → Commiter
Pour les tâches de niveau MOYEN+, commencez toujours par /plan. Pour les tâches ÉPIQUES, utilisez la compétence blueprint.
Recommandation de modèle (inclure dans la sortie) :
| Portée | Modèle recommandé | Justification |
|---|---|---|
| TRIVIALE-FAIBLE | Sonnet 5 | Rapide, économique pour les tâches simples |
| MOYENNE | Sonnet 5 | Meilleur modèle de codage pour le travail standard |
| ÉLEVÉE | Sonnet 5 (principal) + Opus 5 (planification) | Opus pour l'architecture, Sonnet pour l'implémentation |
| ÉPIQUE | Opus 5 (planification) + Sonnet 5 (exécution) | Raisonnement approfondi pour la planification multi-session |
Division en plusieurs prompts (pour portée ÉLEVÉE/ÉPIQUE) :
Pour les tâches qui dépassent une seule session, divisez en prompts séquentiels :
- Prompt 1 : Recherche + Planification (utilisez la compétence search-first, puis /plan)
- Prompt 2 à N : Implémentez une phase par prompt (chacune se termine par /verify)
- Prompt final : Test d'intégration + /code-review sur toutes les phases
- Utilisez /save-session et /resume-session pour 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 | Correctif suggéré |
|---|---|---|
| (problème) | (conséquence) | (comment corriger) |
Points à clarifier : Liste numérotée des questions auxquelles l'utilisateur doit répondre. Si la phase 0 a détecté automatiquement la réponse, indiquez-la au lieu de la demander.
Section 2 : Composants ECC recommandés
| Type | Composant | Objectif |
|---|---|---|
| Commande | /plan | Planifier l'architecture avant le codage |
| Compétence | tdd-workflow | Guide de méthodologie TDD |
| Agent | code-reviewer | Révision post-implémentation |
| Modèle | Sonnet 5 | Recommandé pour cette portée |
Section 3 : Prompt optimisé — Version complète
Présentez le prompt optimisé complet à l'intérieur d'un bloc de code délimité. Le prompt doit être autonome et prêt à être copié-collé. Incluez :
- Une description claire de la tâche avec le contexte
- La pile technique (détectée ou spécifiée)
- Les invocations de /command aux bons moments du flux de travail
- Les critères d'acceptation
- Les étapes de vérification
- Les limites de la portée (ce qu'il NE faut PAS faire)
Pour les éléments qui font référence à blueprint, écrivez : "Utilisez la compétence blueprint pour..." (pas /blueprint, car blueprint est une compétence, 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 échouant pour [bug]. Corriger pour passer au vert. /verify. |
| Refactorisation | /refactor-clean [portée]. /code-review. /verify. |
| Recherche | Utilisez la compétence search-first pour [sujet]. /plan basé sur les résultats. |
| Test | /tdd [module]. /e2e pour les flux critiques. /test-coverage. |
| Révision | /code-review. Utilisez ensuite l'agent security-reviewer. |
| Documentation | /update-docs. /update-codemaps. |
| ÉPIQUE | Utilisez la compétence blueprint pour "[objectif]". Exécutez les phases avec les vérifications /verify. |
Section 5 : Justification des améliorations
| Amélioration | Raison |
|---|---|
| (ce qui a été ajouté) | (pourquoi c'est important) |
Pied de page
Ce n'est pas ce dont vous avez besoin ? Dites-moi ce qu'il faut ajuster, ou faites une demande de tâche normale si vous voulez une exécution au lieu d'une optimisation de prompt.
Exemples
Exemples de déclencheurs
- "Optimise ce prompt pour ECC"
- "Réécris ce prompt pour que Claude Code utilise les bonnes commandes"
- "帮我优化这个指令"
- "Comment formuler le prompt ECC pour cette tâche ?"
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 pile technique existante du projet (Next.js 15 + TypeScript + Tailwind CSS) pour implémenter une page de connexion utilisateur.
Exigences techniques :
- Suivre les conventions de structure de composants et de routage existantes du projet
- Utiliser le schéma de validation existant du projet pour la validation de formulaire (vérifier si Zod/Yup/autre est déjà utilisé)
- Méthode d'authentification : utiliser le schéma d'authentification existant du projet (sinon, JWT par défaut)
- Inclure : formulaire de connexion email/mot de passe, validation de formulaire, messages d'erreur, état de chargement, mise en page responsive
Flux de travail :
1. /plan pour planifier la structure des composants et le flux d'authentification, en se référant aux modèles de pages existantes
2. /tdd test d'abord : é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 réviser 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 n'est pas transmis en clair
- Protection contre les attaques par force brute (rate limiting)
- Protection XSS
- Jeton CSRF
Critères d'acceptation :
- Tous les tests passent, couverture 80%+
- La page s'affiche correctement sur mobile et desktop
- Connexion réussie redirige vers le tableau de bord, échec affiche un message d'erreur
Ne pas faire :
- Ne pas implémenter de page d'inscription
- Ne pas implémenter de fonctionnalité de mot de passe oublié
- Ne pas modifier la structure de routage existante
Exemple 2 : Prompt anglais modéré
Entrée utilisateur :
Ajouter un point de terminaison d'API REST pour les mises à jour de profil utilisateur avec validation
Phase 0 détecte : go.mod avec Go 1.22, routeur Chi
Prompt optimisé (complet) :
Ajouter un point de terminaison d'API REST pour les mises à jour de profil utilisateur (PATCH /api/users/:id).
Pile technique : Go 1.22 + routeur Chi (détecté à partir du projet)
Exigences :
- PATCH /api/users/:id — mise à jour partielle du profil utilisateur
- Validation des entrées pour les champs : nom, email, avatar_url, bio
- Authentification : nécessite un jeton valide, les utilisateurs ne peuvent mettre à jour que leur propre profil
- Retourner 200 avec l'utilisateur mis à jour en cas de succès
- Retourner 400 avec les erreurs de validation en cas d'entrée invalide
- Retourner 401/403 pour les échecs d'authentification
- Suivre les modèles d'API existants dans la base de code
Flux de travail :
1. /plan pour la structure du point de terminaison, la chaîne de middleware et la logique de validation
2. /tdd — écrire des tests pilotés par tableau pour le succès, l'échec de validation, l'échec d'authentification, non trouvé
3. Implémenter en suivant les modèles de gestionnaires existants
4. /go-review
5. /verify — exécuter la suite de tests complète, confirmer l'absence de régressions
Ne pas faire :
- Modifier les points de terminaison existants
- Modifier le schéma de la base de données (utiliser la table utilisateur existante)
- Ajouter de nouvelles dépendances sans vérifier d'abord celles qui existent (utiliser la compétence search-first)
Exemple 3 : Projet ÉPIQUE
Entrée utilisateur :
Migrer notre monolithe vers des microservices
Prompt optimisé (complet) :
Utilisez la compétence blueprint pour planifier : "Migrer l'architecture monolithique vers des microservices"
Avant d'exécuter, répondez à ces questions dans le blueprint :
1. Quelles sont les limites de domaine dans le monolithe actuel ?
2. Quel service doit être extrait en premier (couplage le plus faible) ?
3. Modèle de communication : API REST, gRPC ou piloté par événements (Kafka/RabbitMQ) ?
4. Stratégie de base de données : base de données partagée au départ ou une base par service dès le début ?
5. Cible de déploiement : Kubernetes, Docker Compose ou serverless ?
Le blueprint devrait produire des phases comme :
- Phase 1 : Identifier les limites des services et créer une carte des domaines
- Phase 2 : Mettre en place l'infrastructure (API gateway, service mesh, CI/CD par service)
- Phase 3 : Extraire le premier service (motif du figuier étrangleur)
- Phase 4 : Vérifier avec des tests d'intégration, puis extraire le service suivant
- Phase N : Mettre hors service le monolithe
Chaque phase = 1 PR, avec des vérifications /verify entre les phases.
Utilisez /save-session entre les phases
…
[tronqué pour la traduction]
Exemple 4 : Pas de détection de projet
Entrée utilisateur :
Construire une API RESTful pour un blog en Python FastAPI
Phase 0 : Aucun fichier de projet trouvé. Pile technique spécifiée par l'utilisateur : Python FastAPI (utiliser cette pile dans les phases 3 et 4).
Prompt optimisé (complet) :
Construire une API RESTful pour un blog en utilisant la pile technique spécifiée : Python FastAPI. Aucun projet existant détecté, donc supposez une configuration standard FastAPI.
Exigences fonctionnelles :
- Opérations CRUD pour les articles de blog (créer, lire, mettre à jour, supprimer)
- Authentification (token JWT)
- Pagination et filtrage pour la liste des articles
- Validation des entrées avec Pydantic
- Documentation automatique via Swagger/OpenAPI
Exigences non fonctionnelles :
- Gestion des erreurs avec codes HTTP appropriés
- Tests unitaires avec pytest (au moins 80 % de couverture)
- Journalisation des requêtes
Flux de travail :
1. /plan : esquisser les modèles, les routes et l'architecture de la base de données
2. /tdd : écrire des tests pour chaque point de terminaison
3. Implémenter l'API
4. /code-review
5. /verify : exécuter les tests et confirmer le bon fonctionnement de l'API
Critères d'acceptation :
- Tous les points de terminaison répondent correctement
- Tests passant avec >= 80 % de couverture
- Authentification fonctionnelle
- Documentation Swagger accessible via /docs
Ne pas faire :
- Ne pas ajouter de fonctionnalités frontend
- Ne pas implémenter de système de commentaires ou de gestion des tags (sauf si explicitement demandé)