chinese-novelist-skill : écrire un roman chinois de 10 à 50 chapitres avec un agent de code

Le problème visé : tenir jusqu'au dernier chapitre

Le README ouvre sur une phrase qui résume la cible : écrire un roman, le plus difficile est de le finir. Le projet ne prétend donc pas améliorer la qualité d'une phrase isolée. Il prétend maintenir une production sur vingt, trente ou cinquante chapitres, là où une conversation unique avec un modèle dérive, oublie les personnages secondaires et abandonne les fils ouverts. Le public visé est précis : des auteurs de webnovel chinois, un format où la publication est sérielle et où le volume compte autant que le style. Le dépôt annonce une fourchette de 10 à 50 chapitres, avec des chapitres de 3000 à 5000 caractères. Ce sont des ordres de grandeur de feuilleton, pas de nouvelle littéraire. Un écrivain francophone qui rédige en français n'a rien à en tirer : tout le dispositif de référence, guides de dialogue, techniques de suspense, modèles d'intrigue, est écrit pour la langue chinoise. Le skill est un assistant de production, pas un professeur d'écriture.

Phase 0 et mémoire : ce que l'agent retient entre deux sessions

Avant toute question, la Phase 0 charge un fichier user-preferences.json et cherche un projet interrompu. Le README décrit une mémoire qui apprend le genre préféré, le style narratif, la tendance sur le nombre de chapitres, la densité de texte. L'ambition est de supprimer les questions redondantes à la session suivante. C'est aussi la partie la plus discutable du dispositif. Un fichier de préférences partagé entre tous les projets signifie qu'un détour ponctuel, une expérience de style, peut se figer en habitude et orienter la génération suivante sans que vous l'ayez demandé. Le README ne documente pas de commande pour inspecter ni purger ce fichier. Si vous testez le skill, ouvrez user-preferences.json après la première œuvre et vérifiez ce qui s'y est accumulé : c'est le seul point de contrôle que le matériel fourni permette. La détection d'interruption, elle, est plus solide dans son principe : un projet laissé en cours est repris à son point d'arrêt plutôt que recommencé.

Le questionnaire en trois couches et le plan à sept colonnes

La Phase 1 se découpe en deux niveaux. Le Layer 1 pose trois questions obligatoires : genre et idée, profil du protagoniste, conflit central. Le Layer 2 en ajoute cinq, facultatives : univers, point de vue narratif, thème, lectorat cible, nombre de chapitres. Chaque question accepte une réponse aléatoire, et l'utilisateur peut répondre « passer » ou « tout par défaut ». Ce mécanisme a une conséquence concrète : un lancement rapide produit un roman dont les paramètres ont été tirés au sort, ce que la Phase 2 rend visible en affichant un récapitulatif avant validation. La Phase 2 génère ensuite un plan en sept colonnes, un fichier de personnages et un plan d'écriture au format JSON. Ce JSON n'est pas décoratif : le README le présente comme un état de progression lisible par machine, utilisé pour coordonner l'écriture parallèle. C'est lui qui permet à plusieurs sous-agents de savoir quel chapitre est libre. La validation humaine reste obligatoire à ce stade, et c'est le bon endroit pour corriger une intrigue avant que trente chapitres en dépendent.

Trois modes d'écriture, dont un seul est raisonnable par défaut

La Phase 2.5 propose trois modes. Le mode série écrit chapitre après chapitre depuis l'agent principal, et le README le donne comme recommandé par défaut. Le mode sous-agents parallèles répartit la rédaction sur plusieurs agents pour gagner du temps. Le mode Agent Teams s'appuie sur la collaboration multi-agents de Claude Code pour les projets longs. L'arbitrage est explicite dans la documentation : stabilité contre vitesse. Le mode série conserve un contexte unique, donc une voix cohérente. Le parallélisme accélère mais chaque sous-agent écrit à partir du plan et du résumé, pas du texte déjà rédigé, ce qui expose à des ruptures de ton entre chapitres voisins. Le mode Agent Teams est présenté comme réservé aux grandes longueurs, sans critère chiffré. Si vous ne savez pas lequel choisir, le mode série est le seul dont le README garantisse la fiabilité.

Ce que fait réellement la Phase 3, chapitre par chapitre

Une fois le plan validé, l'écriture devient automatique, sans nouvelle confirmation. Chaque chapitre suit une séquence fixe : analyse préalable, rédaction de 3000 à 5000 caractères, polissage pour retirer les tournures typiques des modèles, contrôle du nombre de caractères, mise à jour du résumé. Le contrôle s'appuie sur un script Python, scripts/check_chapter_wordcount.py, mentionné dans les notes de version 2.0. C'est un point d'ancrage concret : la contrainte de longueur n'est pas une consigne de prompt, elle est vérifiée par du code. Le polissage anti-détection mérite d'être signalé, car il révèle la vraie nature de l'outil. Ce skill ne cherche pas à écrire de la littérature, il cherche à produire du texte qui ne se lise pas comme généré. Les quatre règles affichées vont dans le même sens : montrer plutôt que raconter, un conflit ou un retournement par chapitre, une accroche en fin de chapitre, un pic d'intérêt dans les vingt premiers pour cent. Ce sont des règles de feuilleton, calibrées pour la rétention du lecteur.

Phase 4 : la boucle de correction et sa limite à trois tours

La Phase 4 vérifie deux choses : conformité du nombre de caractères et cohérence. Un chapitre qui échoue est réécrit automatiquement, avec un plafond de trois tentatives. Le plafond est la partie la plus intéressante du projet, parce qu'il admet implicitement que la boucle peut ne pas converger. Le README ne précise pas ce qui se passe au quatrième échec : chapitre conservé en l'état, signalé, ou arrêt du processus. C'est une zone d'ombre à tester avant de confier cinquante chapitres au système. La vérification de cohérence, elle, reste floue dans le matériel fourni : aucun critère, aucun seuil, aucun fichier de référence n'est cité pour cette étape, contrairement au contrôle de longueur qui a son script. On peut donc compter sur la contrainte de volume, beaucoup moins sur la détection d'incohérences narratives. Si la continuité vous importe, relisez les fichiers 00-人物档案.md et 02-写作计划.json en cours de route plutôt que d'attendre la validation finale.

Installation et arborescence produite

Deux chemins d'installation sont documentés. Le premier, une ligne de commande : npx skills add PenglongHuang/chinese-novelist-skill. Le second, une copie manuelle du répertoire dans ~/.claude/skills/chinese-novelist/. Une fois installé, le déclenchement se fait par une phrase en langage naturel, par exemple « 使用 chinese-novelist 帮我写一部小说 ». La sortie s'organise par horodatage : un dossier nommé sur le modèle 20260412-143000-午夜列车 contenant 01-大纲.md, 00-人物档案.md, 02-写作计划.json, puis un fichier par chapitre, par exemple 第01章-最后一班列车.md. Le fichier de préférences vit à la racine, partagé entre tous les projets. Cette séparation est saine : le plan et les personnages sont relisibles indépendamment du texte, et le format Markdown rend la reprise possible avec n'importe quel éditeur. Notez que la documentation décrit aussi une installation via l'interface de gestion des skills de Claude Code, sans détailler la procédure.

Ce que le dépôt ne dit pas, et l'alternative évidente

Le matériel fourni ne contient aucune version publiée, aucun numéro de version autre que le badge 2.0 et un lien vers une pull request de refonte. Il ne donne ni nombre d'utilisateurs, ni résultat de test, ni comparaison mesurée. La maintenance repose sur un unique mainteneur, qui finance le rythme de mise à jour par des dons sur 爱发电, ce qui est une information utile : le projet avance au rythme de son financement, pas d'une feuille de route d'équipe. L'alternative la plus directe n'est pas un autre skill mais l'usage brut d'un agent de code avec vos propres fichiers Markdown : vous conservez le contrôle du plan, vous écrivez vos propres consignes de style, et vous perdez la mémoire inter-sessions, le script de comptage et la boucle de correction. Une autre option consiste à écrire le plan vous-même et à ne confier à l'agent que la rédaction chapitre par chapitre, ce qui élimine la Phase 1 et la majeure partie du risque de dérive des paramètres. Le choix se joue entre structure imposée et contrôle manuel, pas entre deux qualités de prose.

Coût de maintenance et implications de la licence MIT

La licence MIT est permissive : usage commercial, modification et redistribution sont autorisés, à condition de conserver l'avis de copyright et le texte de licence. Le README ne mentionne aucune restriction sur les textes produits, mais le matériel fourni ne traite pas la question du droit d'auteur sur une œuvre générée, qui dépend de la juridiction et non du dépôt. Ne comptez pas sur le fichier LICENSE pour trancher ce point. Côté maintenance, la version 2.0 a réorganisé la documentation en séparant les flux d'exécution, dans references/flows/, des guides d'écriture, dans references/guides/, soit sept fichiers de flux et huit guides selon le README. Cette séparation réduit le coût d'une mise à jour ciblée, mais elle multiplie les fichiers à relire lors d'un changement de modèle, puisque les consignes de style y sont réparties. Le projet dépend fortement du comportement de l'agent hôte : une évolution de Claude Code peut modifier le rendu sans qu'une ligne du dépôt change.

Conclusion éditoriale

Adoptez-le si vous écrivez de la fiction chinoise longue et acceptez qu'un agent tienne le planning à votre place. Évitez-le si vous attendez une prose publiable sans relecture, ou si votre environnement n'est pas Claude Code. Avant de vous lancer, ouvrez references/flows/phase3-writing.md et scripts/check_chapter_wordcount.py : ce sont eux qui déterminent le rendu réel, pas la page d'accueil.

Sources officielles

1. Issues
2. License: MIT
3. PenglongHuang/chinese-novelist-skill on GitHub
4. README