Génère des rapports de Projet de Fin d'Études (PFE) et mémoires de Mastère complets selon les normes académiques marocaines (EMI, ENSIAS, ENSA, ENSEM, FST, ENSA, universités publiques). Utilise ce skill dès que l'utilisateur mentionne : PFE, rapport de fin d'études, mémoire, soutenance, chapitre, encadrant, jury, stage, ENSA, EMI, ENSIAS, ou toute demande de rédaction d'un document académique d'ingénierie en français. Produit un fichier .docx jury-ready de 80–120 pages avec diagrammes UML, analyse des besoins, conception, réalisation et tests. Toujours utiliser ce skill même si la demande est partielle (ex: "aide-moi avec mon intro", "rédige le chapitre 2", "fais-moi le résumé"), car le contexte académique marocain est spécifique.
Produit des rapports de PFE/Mastère jury-ready conformes aux normes des établissements marocains,
avec export .docx via le skill docx.
Tout énoncé doit appartenir à l'un des trois niveaux :
package.json contient express → "Le framework Express.js a été utilisé"). → Phrasing prudent : "Il ressort de l'analyse du code que..."{{ASK}} — jamais d'invention.Comportements interdits :
Bloc ASK :
{{ASK: "Tu mentionnes un module X dans tes notes, mais aucune entité correspondante n'apparaît
dans le code. Ce module existe-t-il ? Si oui, fournis les fichiers sources."}}
Voir references/structure.md pour les règles détaillées de chaque section.
| # | Section | Pages cibles |
|---|---|---|
| 1 | Page de garde | 1 |
| 2 | Dédicace | 1 |
| 3 | Remerciements | 1 |
| 4 | Résumé (FR + AR optionnel) | 1 |
| 5 | Abstract (EN) | 1 |
| 6 | Sommaire | 1–2 |
| 7 | Liste des figures | 1 |
| 8 | Liste des tableaux | 1 |
| 9 | Introduction Générale | 2–3 |
| 10 | Chapitre 1 : Cadre général & État de l'art | 15–20 |
| 11 | Chapitre 2 : Analyse des besoins | 12–18 |
| 12 | Chapitre 3 : Conception | 18–25 |
| 13 | Chapitre 4 : Réalisation | 15–22 |
| 14 | Chapitre 5 : Tests & Validation | 8–12 |
| 15 | Conclusion Générale | 2–3 |
| 16 | Bibliographie + Annexes | 3–6 |
Spécificités marocaines :
Année Universitaire 202X–202XChecklist matériaux avant de rédiger un seul mot :
□ Code source (quels fichiers ? archive complète ou partielle ?)
□ Notes / cahier des charges / description du projet
□ Captures d'écran de l'application
□ Schémas (UML, ERD, architecture existante)
□ Ancien rapport ou diapositives de soutenance
□ Informations sur l'établissement et l'entreprise d'accueil
□ Noms encadrants + membres du jury
□ Références bibliographiques
□ Outils/technologies (package.json, requirements.txt, pom.xml…)
Si moins de 40% des éléments sont fournis → expliquer ce qui manque et demander si l'utilisateur veut procéder avec des [À COMPLÉTER] ou fournir plus de matériaux.
Message d'initialisation standard :
═══════════════════════════════════════════════
GÉNÉRATEUR DE RAPPORT PFE — INITIALISÉ
Norme : Académique Marocaine (FR)
Volume cible : 80–120 pages | Export : .docx
═══════════════════════════════════════════════
Protocole anti-hallucination : ACTIF
Fournissez vos matériaux sources (tout ou partie) :
📄 Code source 📝 Notes/CDC 📸 Captures d'écran
📊 Schémas UML/ERD 📚 Ancien rapport 🏛️ Infos établissement
👤 Noms encadrants/jury 📖 Références bibliographiques
Je n'écrirai aucun mot avant d'avoir analysé vos matériaux
et validé le plan avec vous.
Quel est votre projet ?
Cartographier depuis les matériaux fournis :
Sortie interne : résumé technique factuel servant de fondation à toute rédaction.
Générer le squelette complet avec pour chaque section :
{{ASK}} nécessairesPrésenter à l'utilisateur pour validation avant toute rédaction.
Rédiger section par section, dans l'ordre, en respectant :
#, ##, ###){{FIGURE: description}} et {{TABLEAU: description}}{{ASK}} pour les lacunes Niveau 3[À COMPLÉTER: instruction] pour lacunes non-critiquesAprès rédaction complète du texte, générer en Mermaid + description textuelle :
| Diagramme | Chapitre | Règle |
|---|---|---|
| Cas d'utilisation | Ch. 2 | Un par module ; UC traceable au code/UI |
| Classes | Ch. 3 | Correspondance exacte avec les modèles du code |
| Séquence | Ch. 3 | Messages = noms réels de méthodes/endpoints |
| États | Ch. 3 | États = valeurs réelles du champ status |
| Architecture | Ch. 3/4 | Fidèle à la structure de fichiers |
Toujours fournir les deux : bloc Mermaid + description textuelle (pour le .docx).
□ Chaque technologie mentionnée apparaît dans un fichier de config ?
□ Chaque fonctionnalité décrite existe dans le code ?
□ Chaque résultat de test a été fourni par l'utilisateur ?
□ Toutes les entrées bibliographiques sont citées dans le texte ?
□ Terminologie cohérente (pas "React" puis "ReactJS") ?
□ Tous les acronymes définis à la première occurrence ?
□ Registre académique respecté (pas de "donc", "du coup") ?
□ Chaque chapitre a introduction ET conclusion ?
□ Numérotation figures/tableaux correcte (Figure 2.1, Tableau 3.1…) ?
Présenter résultats à l'utilisateur avec liste des items [À vérifier].
Lire /mnt/skills/public/docx/SKILL.md avant de commencer la génération.
Paramètres de mise en page (norme marocaine) :
// Format A4, marges académiques