optimiseur-de-prompt

Optimiseur de Prompt

Analyse un brouillon de prompt, le critique, le fait correspondre aux composants de l'écosystème ECC et produit 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 commentaires ou une amélioration
• L'utilisateur dit « je ne sais pas comment formuler le prompt pour ça »
• L'utilisateur dit « comment devrais-je utiliser ECC pour... »
• L'utilisateur invoque explicitement /prompt-optimize

Ne pas utiliser quand

• L'utilisateur souhaite que la tâche soit effectuée directement (il suffit de l'exécuter)
• 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 ECC (utiliser configure-ecc à la place)
• L'utilisateur souhaite un inventaire des compétences (utiliser skill-stocktake à la place)
• L'utilisateur dit « fais-le simplement » ou « 直接做 »

Comment ça fonctionne

Uniquement à titre consultatif — 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 simplement », « 直接做 » 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 de manière séquentielle. 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 actuel du projet :

1. Vérifiez si un fichier CLAUDE.md existe dans le répertoire de travail — lisez-le pour connaître les conventions du projet
2. Détectez la pile technologique à partir des fichiers du projet :
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin (vérifiez ensuite la présence de quarkus dans le fichier de build → Quarkus, ou spring-boot → Spring Boot)
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. Notez la pile technologique 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 concerne un nouveau projet), ignorez la détection et signalez « pile technologique 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 faire, qu'est-ce que, explorer, étudier, 怎么, 如何	« Comment ajouter le SSO »
Test	tester, 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 de la base de code comme indicateur. Sinon, estimez-la à 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	Multi-domaines, 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 avec les Composants ECC

Faites correspondre l'intention + la portée + la pile technologique (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
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 compétence)	planner, architect

Par Pile Technologique

Pile Technologique	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 pour détecter les 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 technologique — 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 de défaillance traités ?
• Exigences de sécurité — Authentification, validation des entrées, secrets ?
• Attentes en matière de test — Tests unitaires, d'intégration, E2E ?
• Contraintes de performance — Charge, latence, limites de ressources ?
• Exigences UI/UX — Spécifications de conception, 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 ou plus sont manquants, posez jusqu'à 3 questions de clarification à l'utilisateur avant de générer le prompt optimisé. Incorporez ensuite les réponses dans le prompt optimisé.

Phase 5 : Recommandation de Workflow & de Modèle

Déterminez où se situe ce prompt dans le cycle de vie du développement :

Recherche → Plan → Implémentation (TDD) → Revue → Vérification → Commit

Pour les tâches de portée MOYENNE+, 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 (blueprint) + Sonnet 5 (exécution)	Raisonnement profond pour la planification multi-session

Division multi-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 + Plan (utilisez d'abord la compétence search-first, puis /plan)
• Prompt 2-N : Implémentez une phase par prompt (chacun se termine par /verify)
• Dernier prompt : 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 celle de 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)

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 au lieu de poser la question.

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 dans 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
• Pile technologique (détectée ou spécifiée)
• Invocations de /command aux é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 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.
Revue	/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 des portes /verify.

Section 5 : Justification des Améliorations

Amélioration	Raison
(ce qui a été ajouté)	(pourquoi c'est important)

Pied de Page

Pas ce dont vous avez besoin ? Dites-moi ce qu'il faut ajuster, ou faites une demande de tâche normale si vous souhaitez une exécution plutôt qu'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 pour ECC pour cette tâche ? »

Exemple 1 : Prompt Vague en Chinois (Projet Détecté)

Entrée utilisateur :

帮我写一个用户登录页面

Phase 0 détecte : package.json avec Next.js 15, TypeScript, Tailwind CSS

Prompt Optimisé (Complet) :

Utilisez la pile technologique existante du projet (Next.js 15 + TypeScript + Tailwind CSS) pour implémenter une page de connexion utilisateur.

Exigences techniques :
- Suivez la structure de composants et les conventions de routage existantes du projet
- Utilisez le schéma de validation existant dans le projet pour la validation de formulaire (vérifiez si Zod/Yup/autre est déjà utilisé)
- Méthode d'authentification : utilisez le schéma d'authentification existant du projet (si aucun, JWT par défaut)
- Inclut : 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 d'abord la structure des composants et le flux d'authentification, en vous référant aux modèles de pages existantes
2. /tdd tests en premier : écrivez des tests unitaires pour le formulaire de connexion et des tests d'intégration pour le flux d'authentification
3. Implémentez 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 la 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 la page d'inscription
- Ne pas implémenter la fonctionnalité de mot de passe oublié
- Ne pas modifier la structure de routage existante

Exemple 2 : Prompt Anglais Modéré

Entrée utilisateur :

Ajoute 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) :

Ajoute un point de terminaison d'API REST pour les mises à jour de profil utilisateur (PATCH /api/users/:id).

Pile technologique : Go 1.22 + routeur Chi (détecté depuis le 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

Workflow :
1. /plan pour la structure du point de terminaison, la chaîne de middleware et la logique de validation
2. /tdd — écrivez des tests paramétrés pour le succès, l'échec de validation, l'échec d'authentification, et la non-trouvabilité
3. Implémentez en suivant les modèles de gestionnaires existants
4. /go-review
5. /verify — exécutez toute la suite de tests, confirmez l'absence de régressions

Ne pas faire :
- Modifier les points de terminaison existants
- Changer le schéma de base de données (utiliser la table utilisateur existante)
- Ajouter de nouvelles dépendances sans vérifier d'abord les existantes (utilisez 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 limites de domaine existent dans le monolithe actuel ?
2. Quel service devrait être extrait en premier (couplage le plus faible) ?
3. Modèle de communication : API REST, gRPC, ou événementiel (Kafka/RabbitMQ) ?
4. Stratégie de base de données : base de données partagée initialement ou base de données par service dès le départ ?
5. Cible de déploiement : Kubernetes, Docker Compose, ou serverless ?

Le blueprint devrait produire des phases comme :
- Phase 1 : Identifier les limites de service et créer une carte de domaine
- Phase 2 : Mettre en place l'infrastructure (API gateway, service mesh, CI/CD par service)
- Phase 3 : Extraire le premier service (modèle du figuier étrangleur)
- Phase 4 : Vérifier avec des tests d'intégration, puis extraire le service suivant
- Phase N : Décommissionner le monolithe

Chaque phase = 1 PR, avec des portes /verify entre les phases.
Utilisez /save-session entre les phases

...

[tronqué pour la traduction]