Romans

ROMANS — DESCRIPTION DÉTAILLÉE ET COHÉRENTE DU SKILL
Langue : français

1. BASE DOCUMENTAIRE ET STATUT

Cette présentation repose sur le contenu intégral du fichier SKILL.md de Romans, enregistré le 5 septembre 2026, et sur le fichier Modifications_Romans_24_aout_2026.txt. Les améliorations décrites dans ce dernier sont déjà présentes dans le SKILL.md consulté.

Ce document explique les instructions de Romans. Il ne modifie pas le skill et ne constitue pas une preuve que ses scripts, références ou intégrations sont installés et fonctionnels. Le SKILL.md a été retrouvé comme fichier ; Romans n’apparaissait pas dans les compétences exécutables exposées à cette session.

2. IDENTITÉ ET OBJECTIF

Nom technique : romans.
Nom descriptif : Romans — Novel Writer (Any Language).

Romans est un ensemble d’instructions destiné à accompagner une IA dans l’écriture, la révision, la correction et l’amélioration stylistique de fictions longues. Sa méthode vise à maintenir la cohérence d’un manuscrit au fil de nombreux chapitres, à éviter les répétitions involontaires et à produire un livre mis en forme.

Le fichier source emploie le nom Claude pour désigner l’IA qui applique ces instructions. Cela ne définit pas un modèle, une version de modèle, une API ou un abonnement précis.

3. PÉRIMÈTRE

Usages prévus :

• Création de romans et de récits de fiction longs.
• Création de novellas et de recueils de récits dans un projet de livre.
• Révision de manuscrits existants.
• Correction de l’orthographe, de la grammaire et de la syntaxe.
• Amélioration de la fluidité et du naturel du style.
• Réparation des contradictions et des problèmes de continuité.
• Détection et correction des passages répétitifs.
• Mise en forme d’un livre Word, sommaire automatique et pagination.

Le skill n’est pas destiné aux ouvrages de non-fiction ni aux nouvelles isolées de quelques pages. La mention des recueils concerne un ensemble de récits constituant un projet long.

4. LANGUE ET UNIVERS

Le skill prévoit l’écriture dans la langue demandée par l’utilisateur, avec une attention particulière au français. À défaut de langue explicitement indiquée, il utilise normalement celle de la demande et annonce son choix avant de commencer. La langue reste ensuite stable dans l’ensemble du livre.

Pour une création nouvelle, tous les personnages et lieux doivent être inventés. Les noms, les conventions de dialogue et le registre doivent correspondre à la langue et à l’univers retenus.

Pour une révision, les faits déjà établis dans le manuscrit doivent être préservés. Les instructions ne prévoient pas de remplacer automatiquement ses personnages ou lieux pour les rendre fictifs : toute transformation de cette nature doit être demandée.

5. INFORMATIONS DE DÉPART

Avant la rédaction, Romans recueille ou réutilise :

• La langue.
• Le genre et le ton.
• L’époque et le cadre.
• La longueur approximative souhaitée.
• L’idée centrale, le thème ou les éléments déjà imaginés.
• Les contraintes et les éléments à conserver.

Il évite un long questionnaire lorsque la demande contient déjà les informations utiles. Si la longueur n’est pas précisée, le fichier propose comme exemple un projet d’environ 120 à 180 pages à faire confirmer. Cette fourchette n’est pas une longueur obligatoire.

Dans une exécution sans interlocuteur disponible, le skill prévoit des hypothèses raisonnables, annoncées clairement.

6. LIMITE DE LONGUEUR

Le livre final ne doit pas dépasser 500 pages. Il s’agit d’un plafond, pas d’un objectif systématique. Une demande plus courte reste plus courte.

Pendant l’écriture, la longueur est estimée à partir des mots ou des caractères, selon la langue. Cette estimation sert à ajuster le plan avant un dépassement. La pagination réelle dépend de la mise en page et doit être vérifiée sur le document final rendu.

Si le livre dépasse le plafond, il doit être retravaillé avant livraison. Lors de la révision d’un livre existant, cette contrainte doit être conciliée avec l’interdiction de raccourcir silencieusement le texte : un changement substantiel de longueur doit être explicite.

7. BIBLE NARRATIVE

Avant de rédiger, Romans crée une bible narrative à partir du modèle prévu. Elle contient notamment :

• Les personnages et leurs caractéristiques.
• Les villes, lieux et relations géographiques.
• La chronologie.
• Le plan des chapitres.
• Les faits établis au cours du récit.
• Les règles de continuité et le registre des révisions.

Avant chaque chapitre, l’IA relit les sections pertinentes. Après chaque chapitre, elle ajoute les nouveaux faits. Cette mémoire écrite permet de conserver des détails qui ne sont plus présents dans le contexte immédiat de la conversation.

La bible soutient la rédaction ; elle ne remplace pas le roman complet.

8. RÉDACTION ET SAUVEGARDE

Le premier manuscrit est écrit chapitre par chapitre dans un fichier texte de travail, par exemple manuscript.txt. Les paragraphes sont séparés par des lignes vides pour faciliter les contrôles.

Après chaque chapitre, ou environ tous les 5 000 mots lorsque les chapitres sont très courts, le skill prévoit :

• Une recherche de doublons dans tout le manuscrit rédigé jusque-là.
• Une estimation de longueur.
• La correction des problèmes détectés.
• La mise à jour de la bible.
• La sauvegarde du manuscrit.

Un roman long peut nécessiter plusieurs sessions. La continuité doit dépendre des fichiers sauvegardés plutôt que de la seule mémoire conversationnelle.

9. DOUBLONS ET ORIGINALITÉ

La consigne générale est d’éviter la répétition de phrases et de paragraphes. Le contrôle distingue les répétitions exactes et les passages proches.

Un passage signalé doit normalement être réécrit de façon substantielle, plutôt que remplacé par une simple série de synonymes. Un refrain volontaire ou une expression propre à un personnage peut toutefois être conservé après examen éditorial.

La règle cohérente est donc : supprimer les doublons involontaires et examiner les répétitions intentionnelles. Les contrôles ne constituent pas une garantie universelle d’originalité et ne sont pas décrits comme une recherche de plagiat dans des œuvres externes.

10. RÉVISION EN QUATRE PASSES

A. Continuité
Comparer le manuscrit à la bible et corriger les contradictions concernant les noms, âges, dates, déplacements, lieux, relations, objets, points de vue, temps narratifs et intrigues secondaires. Consigner les problèmes résolus.

B. Langue
Corriger orthographe, accords, conjugaisons, grammaire, syntaxe, ponctuation et typographie des dialogues. Pour le français, vérifier aussi les anglicismes. Relire le contexte après chaque correction pour préserver le sens.

C. Humanisation stylistique
Préserver la voix de l’auteur et l’intrigue tout en réduisant les rythmes mécaniques, formulations génériques, clichés, transitions répétitives et explications excessives. Varier naturellement les phrases, préciser les détails et distinguer les voix des personnages.

L’humanisation signifie ici une amélioration éditoriale du naturel et de la lisibilité. Elle n’exige pas d’ajouter des fautes, de l’argot ou des événements artificiels et ne promet aucun résultat auprès d’un détecteur de texte IA.

D. Lecture à voix haute
Examiner le rythme, les dialogues et les transitions. Retravailler les passages rigides, répétitifs ou dont l’émotion manque de préparation.

11. RÉVISION D’UN MANUSCRIT EXISTANT

Romans travaille à partir d’une copie et préserve, sauf demande contraire :

• Le titre et le nom de l’auteur.
• Les faits de l’intrigue.
• L’ordre des chapitres.
• Les choix stylistiques délibérés.

Il ne doit pas raccourcir ni développer silencieusement le livre. Une fois la révision terminée, les contrôles de doublons et de longueur sont exécutés à nouveau.

12. LIVRE FINAL ET MISE EN PAGE

Le livrable principal prévu est un fichier .docx mis en forme. Le fichier texte est un support de travail ; il peut aussi être livré si l’utilisateur le demande.

La fabrication du livre comprend :

• Une page de titre.
• De vrais styles de titres pour les parties, chapitres, prologue et épilogue présents.
• Un sommaire automatique après la page de titre.
• Des points de conduite et des numéros de pages alignés à droite dans le sommaire.
• Une pagination uniforme en pied de page après la page de titre.
• Des sections configurées explicitement si les pages liminaires ont une numérotation distincte.
• La mise à jour des champs après stabilisation de la mise en page.

Un fichier .txt ne peut pas conserver des champs Word, une pagination réelle ni un sommaire dynamique. Ces fonctions concernent le document .docx.

13. VÉRIFICATION FINALE

Le skill prévoit de rendre le document et d’inspecter visuellement :

• La page de titre et toutes les pages du sommaire.
• Les débuts de sections.
• Les en-têtes et pieds de page.
• La suite des numéros de pages.
• Les lignes isolées en haut ou en bas de page.
• Les chevauchements, textes coupés et pages blanches involontaires.

Après correction, le document doit être rendu à nouveau jusqu’à obtention d’une présentation propre. La vérification comprend également un dernier contrôle des doublons, du plafond de pages et de la cohérence avec la bible, ainsi qu’une dernière relecture linguistique.

14. RESSOURCES ET DÉPENDANCES CITÉES

Le SKILL.md mentionne :

• assets/story_bible_template.md : modèle de bible narrative.
• references/french_conventions.md : conventions pour le français.
• references/style_conventions_by_language.md : conventions pour les autres langues.
• scripts/check_duplicates.py : détection des répétitions.
• scripts/estimate_length.py : estimation de longueur et contrôle final prévu.
• La compétence documents : fabrication, rendu et vérification du .docx.

Commandes prévues pendant l’écriture :
python scripts/check_duplicates.py manuscript.txt
python scripts/estimate_length.py manuscript.txt --budget 500

Ces chemins et commandes sont ceux du fichier source. Les fichiers associés et leur fonctionnement n’ont pas été vérifiés pour cette présentation. Le comptage réel des pages nécessite un environnement de rendu adapté ; une estimation fondée sur les mots ne suffit pas.

15. CE QUE LE SKILL NE DÉFINIT PAS

Le SKILL.md ne fixe pas :

• Un fournisseur ou un modèle d’IA obligatoire.
• Une clé API ou un nom de variable d’environnement.
• Un tarif, une formule commerciale ou un quota de requêtes.
• Une intégration à Capafy ou à un site SaaS.
• Une architecture de serveur, une base de données ou un système de paiement.
• Une publication automatique sur une plateforme de vente.
• Une génération audio, podcast, vidéo ou bande dessinée.
• Un mécanisme de sous-agents.

Ces fonctions peuvent appartenir à un projet distinct, mais ne doivent pas être présentées comme des capacités confirmées de cette version du skill.

16. LIMITES PRATIQUES

Romans fournit une méthode de travail, des règles éditoriales et des contrôles prévus. Il ne garantit pas à lui seul un roman sans défaut, un succès commercial ou un livre de 500 pages produit en une seule réponse.

Les scripts visent des problèmes mécaniques, comme les répétitions et les dépassements de longueur. L’intérêt de l’intrigue, la qualité littéraire et la crédibilité des émotions restent soumis au jugement éditorial de l’IA et à la lecture de l’utilisateur.

17. EXEMPLES DE DEMANDES

Création :
« Écris un roman fantastique en français, d’environ 150 pages, dans une ville inventée. Le personnage principal découvre une station de métro qui apparaît uniquement la nuit. Utilise la méthode Romans et livre le roman complet en .docx. »

Révision :
« Révise ce manuscrit avec Romans. Préserve le titre, le nom de l’auteur et l’intrigue. Corrige le français, les contradictions et les doublons involontaires. Améliore la fluidité, puis actualise le sommaire et la pagination du .docx. »

18. DESCRIPTION COURTE RÉUTILISABLE

Romans accompagne la création et la révision de fictions longues dans la langue choisie. Il s’appuie sur une bible narrative, une rédaction chapitre par chapitre, des contrôles de répétition et de longueur, puis une révision de la continuité, de la langue et du style. Son livrable principal est un livre .docx avec sommaire automatique et pagination vérifiée, limité à 500 pages. L’exécution complète dépend de la disponibilité des ressources, scripts et outils de mise en page prévus.