| name | mega-prompt-builder |
| description | Construit un mega-prompt complet et structuré à partir d'un objectif simple. À utiliser quand l'utilisateur veut créer un prompt complexe et puissant de zéro. Se déclenche aussi avec "crée un prompt pour", "mega prompt", "prompt complet", "construis un prompt", "super prompt", ou toute demande de création de prompt élaboré. Also triggers on "build a full prompt", "write a prompt for me". |
Mega-Prompt Builder
Workflow
Étape 1 — Recueil des paramètres
Avant d'écrire quoi que ce soit, extraire :
| Paramètre | Question clé |
|---|
| LLM cible | GPT-4o, Claude 3.x, Gemini, local ? |
| Objectif principal | Une seule phrase : "Le LLM doit…" |
| Audience finale | Qui lit la sortie (dev, client, outil automatisé) ? |
| Format de sortie | JSON, Markdown, texte libre, bullet list… |
| Ton | Expert, pédagogique, neutre, concis ? |
| Contraintes dures | Longueur max, langue, ce qui est interdit |
| Réutilisabilité | Prompt one-shot ou template avec variables ? |
Si plusieurs paramètres sont ambigus, poser les questions groupées en une seule fois.
Étape 2 — Choix de l'architecture
Sélectionner les blocs selon le besoin :
[RÔLE] — Persona du LLM (expert, outil, agent…)
[CONTEXTE] — Background nécessaire à la tâche
[OBJECTIF] — Tâche principale en 1-2 phrases
[INSTRUCTIONS]— Étapes numérotées, ordre chronologique
[FORMAT] — Structure exacte de la sortie
[EXEMPLES] — Few-shot : 1-3 paires input → output
[CONTRAINTES] — Ce qu'il ne faut PAS faire (liste)
[QUALITÉ] — Critères de succès mesurables
[VARIABLES] — {{placeholders}} pour la réutilisation
Critères de décision — quand inclure chaque bloc :
[RÔLE] : toujours, sauf prompts ultra-courts (< 3 lignes)[EXEMPLES] : dès que le format attendu est non trivial ou que le ton est très précis[CONTRAINTES] : dès qu'il y a un risque de dérive (hallucinations, hors-sujet, verbosité)[VARIABLES] : si le prompt sera utilisé > 1 fois avec des inputs variables[QUALITÉ] : si le prompt sera évalué automatiquement (CI, eval harness)
Étape 3 — Rédaction du mega-prompt
Rédiger le prompt complet, prêt à copier-coller. Exemple de structure :
# [RÔLE]
Tu es un expert en analyse de code Python spécialisé en performance et sécurité.
# [CONTEXTE]
L'utilisateur te soumet un extrait de code Python issu d'une API REST.
Les environnements cibles sont Python 3.11+ et déploiement serverless.
# [OBJECTIF]
Analyser le code soumis et produire un rapport de revue structuré.
# [INSTRUCTIONS]
1. Identifier les problèmes de performance (O(n²), I/O bloquant, etc.)
2. Signaler les vulnérabilités OWASP Top 10 pertinentes
3. Proposer une version corrigée du code avec commentaires inline
4. Donner un score de qualité global sur 10 avec justification
# [FORMAT]
## Problèmes détectés
- [PERF|SEC|STYLE] Description — ligne X
## Code corrigé
```python
...code...
Score qualité : X/10
Justification : ...
[CONTRAINTES]
- Ne pas réécrire intégralement si le code est fonctionnel à > 80%
- Ne pas mentionner de bibliothèques non disponibles en serverless standard
- Répondre uniquement en français
[QUALITÉ]
- Chaque problème cite le numéro de ligne
- Le code corrigé est exécutable sans modification
- Le score est justifié en 2-3 phrases
[VARIABLES]
CODE = {{code_python}}
---
### Étape 4 — Version template avec placeholders
Fournir systématiquement une version avec `{{variables}}` pour la réutilisation :
```python
# Exemple d'usage programmatique (Python)
template = open("prompt.md").read()
prompt = template.replace("{{code_python}}", code_to_review)
response = client.messages.create(model="claude-opus-4-5", messages=[{"role": "user", "content": prompt}])
sed 's/{{code_python}}/'"$(cat myfile.py)"'/g' prompt.md | pbcopy
Étape 5 — Guide d'utilisation
Livrer systématiquement avec le prompt :
- Variables à remplir : liste avec format attendu pour chaque
{{placeholder}}
- Paramètres LLM recommandés : temperature (0.0–0.3 pour tâches factuelles, 0.7–1.0 pour créatif), max_tokens
- Test rapide : un exemple d'input minimal pour vérifier que le prompt fonctionne
- Points d'adaptation : quelles sections modifier selon le contexte
Anti-patterns et garde-fous
Ce qu'il ne faut PAS faire
| Anti-pattern | Problème | Correction |
|---|
| Instructions contradictoires | Le LLM choisit arbitrairement | Revoir la logique, une seule règle par cas |
| Surcontraindre sans exemples | Résultat trop rigide ou mauvais | Ajouter 1-2 few-shot examples |
| Prompt > 4 000 tokens sans nécessité | Coût élevé, distraction du modèle | Découper en prompts chaînés |
[RÔLE] vague ("Tu es un assistant utile") | Aucun guidage de comportement | Préciser domaine + niveau d'expertise |
| Instructions en langage naturel flou | Interprétations variables | Utiliser des listes numérotées + mots-clés |
| Mélanger langue FR/EN dans les instructions | Confusion du modèle | Choisir une langue, termes techniques EN OK |
Pas de [CONTRAINTES] | Dérives, hallucinations, verbosité | Toujours lister 3-5 interdits explicites |
Pièges spécifiques 2025-2026
- Context window : Claude 3.x / GPT-4o supportent 128k–200k tokens, mais la précision décline au-delà de 50k tokens d'input ; éviter de coller des fichiers entiers si non nécessaire.
- System vs User prompt : les instructions de comportement stables vont dans le
system prompt, le contenu variable dans le user prompt.
- Few-shot ordering : placer les exemples les plus représentatifs en dernier (effet de récence).
- JSON mode : si la sortie doit être du JSON strict, activer le mode
response_format: {type: "json_object"} côté API plutôt que de l'imposer via le prompt seul.
- Prompt injection : si des données externes (fichiers, web) sont injectées, isoler avec des balises claires :
<user_data>...</user_data>.
Bonnes pratiques 2026
- Versionner les prompts comme du code : fichier
.md ou .txt dans le repo, changelog.
- Eval avant déploiement : tester sur ≥ 10 exemples représentatifs avant usage en production.
- Prompt court + RAG > prompt long : injecter uniquement le contexte pertinent via retrieval plutôt que tout coller.
- Séparation des responsabilités : un prompt = une tâche. Chaîner pour les pipelines complexes.
- Commentaires dans le prompt : les LLM modernes ignorent les commentaires HTML
<!-- --> ; utiliser pour documenter sans affecter la sortie.
