Novel Architect — Compétence de création de romans web commerciaux chinois
Version 3.0.0. L'objectif est de permettre à l'Agent de réaliser de manière stable l'ouverture, la suite, la relecture, la correction et la maintenance à long terme de romans web commerciaux chinois en combinant des "gardes d'état scriptés" et des "jugements littéraires du modèle".
0. Principes généraux
Considérez cette compétence comme un workflow exécutable de manière autonome : ne transférez pas la liste des commandes CLI à l'utilisateur.
- L'utilisateur fournit les objectifs créatifs de haut niveau, le genre, la plateforme, les préférences, les limites et les choix de direction majeurs.
- L'Agent est chargé de lire ce
SKILL.md, de lire si nécessairereferences/, d'appeler lui-même le CLInovel_architect, de lire ses sorties, de générer les JSON/corps de texte/corrections, et de progresser jusqu'à un point d'arrêt valide. - Le CLI Python est la couche d'outils déterministe chargée de l'état du projet, des index, des registres, des portes, des signaux, des hachages et de l'écriture des fichiers ; ce n'est pas un mode d'emploi destiné à être exécuté manuellement par l'utilisateur.
- Le modèle est responsable des jugements littéraires et de la création : le market pack, la sélection des beats, l'écriture du corps de texte, les signaux du modèle, la correction et le diagnostic des retours.
- Ne demandez à l'utilisateur que si vous manquez d'outils shell/fichier, si le chemin du projet est inconnu et impossible à déduire, ou si un véritable choix de direction créative est nécessaire.
Les seuls points d'arrêt valides sont les suivants : gate.passed=true pour un chapitre et commit effectué ; échec de la révision des trois premiers chapitres nécessitant une réécriture du début ou une refonte du market pack ; manque d'entrées nécessaires empêchant la poursuite ; permissions insuffisantes ; nécessité pour l'utilisateur de choisir entre plusieurs grandes directions créatives.
1. Conventions d'exécution des commandes
Exécutez les commandes dans un espace de travail où novel_architect peut être importé. Utilisez de préférence la racine du dépôt du projet :
uv run python -m novel_architect <commande> ...
Si uv n'est pas disponible dans l'environnement actuel mais que le paquet est installé, utilisez :
python -m novel_architect <commande> ...
Si un script console est disponible, vous pouvez également utiliser :
novel-architect <commande> ...
Avant d'exécuter, déterminez le chemin du projet : utilisez le chemin donné par l'utilisateur ; si l'utilisateur dit "ce livre / continuez à écrire", vérifiez d'abord les répertoires courants projects/<titre_du_livre>/ et project.json ; en cas de multiples projets candidats, demandez à l'utilisateur.
Un code de retour non nul de review, save-first3-review, etc. indique généralement que la porte n'est pas passée, et non une panne du programme. Dans ce cas, lisez la sortie JSON, gate.json ou repair.json, corrigez et réessayez.
2. Contrat d'exécution autonome de l'Agent
Actions que l'Agent doit exécuter lui-même
Lorsqu'une tâche implique l'ouverture d'un livre, la suite, la relecture, la correction, la modification du plan, la reconstruction, le diagnostic des retours ou la vérification de l'état, l'Agent DOIT appeler lui-même le CLI, lire les fichiers de sortie, écrire les fichiers et poursuivre le processus.
Ne vous contentez pas de répondre :
Veuillez exécuter python -m novel_architect prepare ...
Vous devez réellement exécuter la commande, vérifier le résultat, puis passer à l'étape suivante. Ne donnez la commande à l'utilisateur que si l'environnement ne dispose pas des permissions shell/fichier.
Les prompts exportés sont des éléments de travail pour l'Agent
Ces commandes exportent des prompts ou des fichiers d'entrée. L'Agent doit les lire, générer lui-même le JSON/texte correspondant, puis appeler la commande de sauvegarde ou mettre à jour les fichiers.
| Commande d'export | Résultat | Prochaine étape de l'Agent |
|---|---|---|
market-open | editorial/market_pack_prompt.md, market_pack_input.json | Générer un JSON strict, appeler market-save |
beat-candidates | editorial/chXXXX/beat_competition_prompt.md, beat_competition_input.json, beat_options.json | Choisir/générer le meilleur plan, appeler beat-select, puis apply-beat-selection |
export-signal-prompts | 12 prompts de signal JSON | Générer un par un les signaux modèle JSON, appeler save-model-signal |
first3-review | data/reviews/first3_review_prompt.md, first3_review_input.json | Générer un verdict contenant review_input_hash et 8 scores, appeler save-first3-review |
feedback-diagnose | data/feedback/chXXXX_diagnosis_prompt.md, input | Générer un diagnostic ; si nécessaire, écrire le diagnostic dans le champ diagnosis du JSON de feedback, puis appeler save-feedback |
export-title-review-prompt / export-intro-review-prompt | Prompt de révision du titre/résumé | Générer un diagnostic, mettre à jour si nécessaire market_pack.json, les candidats titre/résumé ou les documents d'ouverture |
Ne demandez pas à l'utilisateur de copier ces prompts dans un autre modèle, sauf s'il demande explicitement ce mode de collaboration manuelle.
3. Aide-mémoire des points d'entrée des tâches
| Intention de l'utilisateur | Processus principal à exécuter par l'Agent |
|---|---|
| Ouvrir un nouveau livre | init → market-open → market-save → renforcer les sources de vérité → first-10-retention / save-first10-plan → production test des trois premiers chapitres |
| Continuer avec le chapitre suivant | status → prepare → compétition de beats → écrire le corps → review → signaux du modèle → review → boucle de correction → commit |
| Corriger le chapitre actuel | Lire editorial/chXXXX/repair.json et gate.json → modifier le corps → review → signaux du modèle si nécessaire → à nouveau review → si réussi, commit |
| Révision des trois premiers chapitres | Après la validation des chapitres 1-3, exécuter first3-review → générer le verdict → save-first3-review |
| Modifier le plan/les paramètres | Modifier les sources de vérité src/*.json → rebuild → status → si nécessaire, relancer la review des chapitres concernés |
| Examen par volume/lot | batch-review, volume-review, benchmark, status |
| Intégration des retours de la plateforme | save-feedback → feedback-diagnose → générer un diagnostic → mettre à jour la planification glissante, le market pack, les notes de chapitre |
| Modélisation par décomposition d'ouvrage | learn --sample-dir <dossier>, puis transformer les conclusions en ajustements actionnables de genre/rythme/planification de chapitre |
gen-prompt n'est à utiliser que lorsque l'utilisateur demande explicitement "exporter un prompt indépendant pour un modèle d'écriture externe / Claude Code". Pour les suites normales, n'utilisez pas gen-prompt pour remplacer le processus principal prepare → beat → writing_task → review → commit.
4. Processus d'ouverture d'un livre
Lors de l'ouverture d'un nouveau livre, ne commencez pas directement à écrire le chapitre 1. Établissez d'abord le positionnement marché et les sources de vérité.
4.1 Initialisation du projet
python -m novel_architect init --project <dossier_projet> --title <titre> --genre <genre> --platform <plateforme> --premise <prémisse> --core-hook <accroche_centrale> --protagonist <nom>
L'initialisation génère project.json, src/, manuscript/, data/, editorial/, etc. L'initialisation ne fournit qu'une structure ; elle ne signifie pas que la planification du livre est terminée.
4.2 Générer et sauvegarder le market pack
Exécutez market-open, lisez le prompt/l'entrée exporté, générez vous-même le JSON strict, puis exécutez market-save.
Le market pack doit contenir au minimum :
target_platformgenre_lanetarget_readerreader_desirescore_sell_pointsanti_sell_pointstitle_candidatesintro_candidatesfirst_10_chapter_retention_planplatform_notesauthor_constraints
Chaque chapitre du plan des 10 premiers chapitres doit avoir chapter, hook, visible_payoff, drop_off_risk. N'écrivez pas de paroles creuses comme "renforcer le conflit" ou "augmenter la satisfaction".
4.3 Renforcer les sources de vérité
src/ est la source de vérité confirmée manuellement. Après l'ouverture, vérifiez et renforcez :
src/blueprint.json: prémisse, accroche centrale, conflit central, objectif du protagoniste.src/characters.json: identité du personnage, désirs, peurs, faiblesses, arc, slug.src/character_voice_bible.json: règles de voix du personnage, tons interdits, préférences d'action, points de fuite émotionnelle. Structure :{"schema_version":1,"characters":{"nom_du_personnage":{...}}}; si le fichier est encore une structure vide ou si le personnage aneeds_completion=true, complétez-le d'abord avant d'écrire le corps du texte.src/world.json: règles du monde/industrie/pouvoir, ne gardez que les paramètres qui servent le conflit et la satisfaction.src/taboos.json: les scènes à ne surtout pas toucher, l'odeur de l'IA, les anti-modèles du genre.src/volumes.json: objectifs par volume et plan de chapitre glissant. Ne figez pas chaque chapitre du livre en une seule fois.src/genre_config.json: stratégie par genre ; prise en charge native prioritaire pour les paliers de cultivation, le retournement de situation urbain, les intrigues historiques, la résolution d'enquêtes ; pour les autres genres, fiez-vous davantage au market pack et au genre_config personnalisé.
Après avoir modifié les sources de vérité, exécutez :
python -m novel_architect rebuild --project <dossier_projet>
python -m novel_architect status --project <dossier_projet>
Ne modifiez pas manuellement les registres ou les états dérivés dans data/ pour "réparer" l'histoire ; écrivez les corrections sémantiques à long terme dans src/ledger_overrides.json ou le src/*.json correspondant, puis reconstruisez.
4.4 Plan de rétention des dix premiers chapitres
Utilisez first-10-retention pour exporter/générer le plan ; si nécessaire, détaillez-le vous-même puis sauvegardez-le avec save-first10-plan. Les dix premiers chapitres sont l'entonnoir d'entrée ; la planification doit être spécifique pour chaque chapitre : accroche, bénéfice visible, risque d'abandon et ce qu'il ne faut pas faire.
5. Processus standard pour la suite du chapitre suivant
Chaque chapitre doit boucler complètement. N'écrivez pas le corps directement à partir du contexte de la conversation.
5.1 Vérification de l'état
Exécutez d'abord :
python -m novel_architect status --project <dossier_projet>
Déterminez le nombre de chapitres terminés, l'état de la porte, la santé de l'index et les risques en attente. Ne vous fiez pas à la mémoire de la conversation pour déterminer le numéro du chapitre suivant.
5.2 PREPARE
python -m novel_architect prepare --project <dossier_projet> --query "<exigences créatives de haut niveau pour ce chapitre>"
Résultat : editorial/chXXXX/writing_task.json. C'est le paquet de tâches autonome pour la phase d'écriture ; il doit être lu. Il contient writer_brief, narrative_context, les créneaux narratifs, les champs de rétention commerciale, les voix des personnages, les promesses au lecteur, le format de sortie et les règles strictes.
À partir du chapitre 4, prepare vérifie la révision spéciale des trois premiers chapitres. Pour un nouveau livre normal, n'utilisez pas --force-after-first3-fail ; ce paramètre n'est destiné qu'à la migration d'anciens projets ou au débogage.
5.3 Compétition de beats
La compétition de beats est obligatoire pour les chapitres 1 à 10 ; à partir du chapitre 10, elle est recommandée par défaut, sauf si l'utilisateur demande explicitement un brouillon rapide.
python -m novel_architect beat-candidates --project <dossier_projet> --chapter <n>
Lisez le prompt exporté, générez ou choisissez le plan le plus fort stratégiquement, sauvegardez et appliquez-le :
python -m novel_architect beat-select --project <dossier_projet> --chapter <n> --file <selection.json>
python -m novel_architect apply-beat-selection --project <dossier_projet> --chapter <n>
Critères de sélection : le point de satisfaction visible le plus clair, la perte de l'ennemi la plus concrète, le bouton de personnage le plus distinct, la raison la plus forte de vouloir lire la suite en fin de chapitre, le risque d'abandon le plus faible. Après application, relisez le writing_task.json mis à jour.
5.4 ÉCRIRE
Écrivez le corps du texte selon writing_task.json et sauvegardez-le dans manuscript/ChapitreXXX-Titre.md. Le titre doit être accrocheur ; ne le sauvegardez pas simplement sous ChapitreXXX.md.
Le corps du texte doit strictement respecter le writing_task.output_format.field_template :
# ChapitreXXX-Titre## Informations sur le chapitre## Plan de ce chapitre## Corps du texte## Écriture mémoire
Exigences clés :
- Le corps ne doit pas être inférieur à 2000 caractères, objectif 2000-2500 caractères.
- Utilisez les guillemets courbes chinois
"". - Le premier paragraphe doit enchaîner sur l'accroche du chapitre précédent ; pour le chapitre 1, établissez rapidement la pression, le désir du protagoniste et l'opportunité visible.
- Chaque chapitre doit avoir un point de satisfaction visible qu'un lecteur moyen peut reformuler en 5 secondes.
- Les processus/termes professionnels doivent être traduits en gains/perdants d'argent, pouvoir, face, identité, relations, secrets, capacité de combat, ressources ou sécurité.
- Les dialogues des personnages doivent refléter
character_voice_bible; il est interdit que tous les personnages aient le même ton de résumé stratégique. - Si vous créez de nouvelles attentes du lecteur, vous devez remplir les nouvelles promesses au lecteur dans l'écriture mémoire ; si vous réalisez une attente, vous devez remplir l'ID de réalisation et la preuve visible.
5.5 PREMIÈRE RONDE DE REVIEW
python -m novel_architect review --project <dossier_projet> --chapter <n>
Si le code de retour est non nul, lisez editorial/chXXXX/gate.json et repair.json ; ne sautez pas cette étape.
5.6 Évaluation des signaux du modèle
Exportez les prompts de signaux :
python -m novel_architect export-signal-prompts --project <dossier_projet> --chapter <n>
Pour les 10 premiers chapitres, le début de volume, la fin de volume, les points culminants, les rebondissements, les chapitres avant publication : les 12 signaux doivent tous être générés et le signal du modèle sauvegardé.
En période stable, couvrez au minimum :
reader_pullvisible_payoffblockbustertitle_hookcharacter_voicedomain_translationstory_logicstate_guard
Sauvegardez chaque signal du modèle :
python -m novel_architect save-model-signal --project <dossier_projet> --chapter <n> --signal <type_signal> --file <signal.json>
Les signaux du modèle doivent produire un JSON strict. Si le score est inférieur à 7, n'écrivez pas pass. Le pass du modèle ne peut pas remplacer un warn/fail heuristique ; la fusion finale utilise le plus strict.
5.7 DEUXIÈME RONDE DE REVIEW et boucle de correction
Après avoir sauvegardé les signaux du modèle, relancez :
python -m novel_architect review --project <dossier_projet> --chapter <n>
Ne validez que si passed=true dans gate.json. Si passed=false, lisez repair.json, modifiez le corps, puis répétez review/signal-modèle/review jusqu'à ce que ce soit passé ou que vous atteigniez un point d'arrêt valide.
5.8 COMMIT
python -m novel_architect commit --project <dossier_projet> --chapter <n>
N'exécutez que si la porte est passée. commit met à jour l'état, reconstruit l'index, met à jour le registre, gère la création/validation/expiration des promesses au lecteur. Ne validez pas en sautant des chapitres ; ne modifiez pas manuellement gate.json ou les signaux pour forcer le passage.
6. Porte spéciale pour les trois premiers chapitres
Les chapitres 1 à 3 d'un nouveau livre sont la phase de production test. Une fois que les chapitres 1, 2 et 3 ont chacun terminé prepare → beat → write → review → signaux du modèle → review → commit, vous devez exécuter :
python -m novel_architect first3-review --project <dossier_projet>
Lisez data/reviews/first3_review_prompt.md et first3_review_input.json, générez le verdict JSON, puis sauvegardez-le :
python -m novel_architect save-first3-review --project <dossier_projet> --file <first3_verdict.json>
Pour pouvoir continuer vers le chapitre 4, les conditions suivantes doivent être simultanément remplies :
verdict == "continue"bulk_continue_allowed == true- Contient exactement le
review_input_hashactuel - Les 8 scores doivent tous être présents :
title_intro_click_score,first_chapter_hook_score,protagonist_desire_score,conflict_speed_score,first_payoff_speed_score,enemy_or_pressure_score,setting_clarity_score,continuation_score - Tous les scores sont des nombres de 1 à 10, et tous
>= 7
Si le résultat est rewrite_opening, corrigez d'abord les trois premiers chapitres ; si c'est redo_market_pack, refaites d'abord le market pack, le titre/résumé et le plan des dix premiers chapitres. N'utilisez pas --force-after-first3-fail pour faire progresser normalement un nouveau livre.
Lorsque le texte des trois premiers chapitres, le market pack ou les entrées d'ouverture changent, l'ancien first3_review bloquera la production à partir du chapitre 4 en raison de l'expiration du hachage ; vous devez relancer first3-review et sauvegarder un nouveau verdict.
7. Portes et 12 signaux
review génère 12 signaux, un verdict, une porte et une réparation. Chaque review relance les signaux heuristiques ; les nouveaux signaux du modèle sont sauvegardés en tant que variante .model.json et participent à la fusion stricte (strictest merge) ; le signal final est le plus strict.
| Signal | Détection | Traitement en cas d'échec |
|---|---|---|
anti_ai | Langage formaté IA, densité d'abstraction, paragraphes vides, guillemets droits | hard, doit être réparé |
story_logic | POV, sources d'information, logique de pouvoir/commerce, déversement d'informations | hard, doit être réparé |
state_guard | Accroche, coût, ligne ennemie, éléments obligatoires, zones interdites, promesses lecteur en souffrance | hard/quality, doit être réparé |
emotion | Arc émotionnel, dynamique relationnelle, conséquences | quality, ne peut pas être validé en cas d'échec |
blockbuster | Arc de satisfaction en quatre segments : pression/contre-mesure/réalisation/coût | quality, ne peut pas être validé en cas d'échec |
visible_payoff | Gains/pertes d'argent, pouvoir, face, identité, relations, secrets, capacités, ressources, sécurité | quality, ne peut pas être validé en cas d'échec |
reader_pull | Accroche d'ouverture, suspense au milieu, envie de lire la suite en fin de chapitre, cycle d'addiction | quality, ne peut pas être validé en cas d'échec |
title_hook | Attrait du titre du chapitre, cohérence titre/nom de fichier, accroche de fin de chapitre | quality, ne peut pas être validé en cas d'échec |
character_voice | Différence de voix des personnages, tons interdits, attribution des dialogues | quality, ne peut pas être validé en cas d'échec |
domain_translation | Traduction des paramètres professionnels en gains visibles pour le lecteur moyen | quality, ne peut pas être validé en cas d'échec |
novelty | Répétition de structure/de rythme/de modèle de fin | market, même en échec, cela bloque |
continuity | Enchaînement des accroches, des coûts, des lignes ennemies | market, même en échec, cela bloque |
Règle simple : regardez seulement gate.passed. passed=true permet de valider ; passed=false signifie qu'il faut réparer.
8. Maintenance à long terme
- Chaque chapitre : exécutez complètement
prepare → beat → write → review → signaux du modèle → review → repair → commit. - Tous les 3 chapitres : exécutez
status, vérifiez les promesses lecteur actives/en souffrance, les changements de porte, la santé de l'index. - Tous les 5 chapitres : exécutez
batch-review --start <a> --end <b>, vérifiez les faiblesses continues et les modèles répétitifs. - Tous les 10 chapitres ou aux nœuds clés : exécutez
volume-review,benchmark, mettez à jourvolumes.jsonet la planification des 5 à 10 chapitres suivants. - Fin de chaque volume : vérifiez les objectifs du volume, les pertes de l'ennemi, le respect des promesses au lecteur, l'accroche du volume suivant.
- Après publication : utilisez
save-feedbackpour enregistrer les données et les commentaires, utilisezfeedback-diagnosepour les transformer en suggestions expérimentales pour le prochain cycle. Lorsque l'échantillon est très petit, ne surajustez pas un seul commentaire.
9. Sources de vérité et règles de répertoire
Structure du projet :
projects/<titre_du_livre>/
├── project.json
├── src/ # Sources de vérité, paramètres et planification confirmés manuellement
├── manuscript/ # Chapitres du corps en .md
├── data/ # État dérivé, peut être reconstruit, ne pas modifier manuellement
├── editorial/ # Brief / writing_task / signaux / porte / réparation par chapitre
└── exports/
Règles importantes :
src/etmanuscript/sont les entrées de vérité.data/,editorial/sont des produits dérivés/d'exécution ; ne les modifiez pas manuellement pour contourner les portes.- Pour modifier les paramètres, le plan de volume, les personnages, modifiez
src/*.json, puisrebuild. - Pour modifier le corps du texte, modifiez
manuscript/ChapitreXXX-Titre.md, puisreview. - Pour les corrections de registre manuelles à long terme, écrivez dans
src/ledger_overrides.json, puisrebuild.
10. Interdictions
Ne faites pas ce qui suit :
- Ne transférez pas le travail CLI à l'utilisateur pour qu'il l'exécute manuellement.
- N'écrivez pas directement des chapitres formels sans
prepare. - Ne sautez pas la compétition de beats pour écrire les 10 premiers chapitres.
- Ne validez pas et ne continuez pas vers le chapitre suivant si
gate.passed=false. - N'utilisez pas
--force-after-first3-failpour un nouveau livre normal. - Ne considérez pas qu'une review heuristique seule suffit pour la qualité commerciale ; les chapitres clés doivent avoir un signal du modèle.
- Ne modifiez pas manuellement
gate.json, les signaux oudata/ledgerspour créer un passage. - Ne laissez pas les chapitres sans titre ou nommés seulement
ChapitreXXX.md. - Ne laissez pas l'écriture mémoire remplir "aucun" pendant longtemps, en particulier pour les promesses au lecteur.
- N'écrivez pas les processus professionnels comme des comptes rendus de réunion, des autorisations, des listes de contrôle, sans les traduire en gains visibles pour le lecteur.
- Ne promettez pas d'imiter mot pour mot le style d'un auteur ou d'une œuvre existante.
11. Fichiers de référence à lire
Lisez selon les besoins, évitez de mettre tous les documents en contexte en une seule fois.
| Fichier | Quand le lire |
|---|---|
references/pipeline-spec.md | En cas de doute sur PREPARE/WRITE/REVIEW/COMMIT, la reprise, le hachage, la fraîcheur |
references/review-spec.md | Lors du traitement des 12 signaux, signal du modèle, verdict, porte, réparation |
references/story-spec.md | En cas d'incertitude sur le format du chapitre, le rythme du chapitre, les variantes de rythme, les champs d'écriture mémoire |
references/state-spec.md | Lors de la modification de l'état, du registre, des promesses au lecteur, des overrides de registre, de la reconstruction |
references/genre-spec.md | Stratégie de genre, genre_config, marqueurs de genre, playbooks intégrés |
references/learning-spec.md | Lors de la modélisation par décomposition d'ouvrage et de l'apprentissage de la structure d'échantillon |
references/longrun-spec.md | Lors des vérifications batch/volume/benchmark et de la stabilité des longs formats |
En cas de conflit entre le comportement implémenté, le README et les références, le comportement actuel du CLI Python prime ; synchronisez la documentation lors des tâches de maintenance.
12. Liste des commandes courantes
python -m novel_architect --help
python -m novel_architect init --project <dossier> --title <titre> --genre <genre> [--platform <plateforme>] [--premise <texte>] [--core-hook <texte>] [--protagonist <nom>]
python -m novel_architect market-open --project <dossier> [--platform <plateforme>] [--genre-hint <genre>] [--seed-idea <idée>] [--author-intent <intention>] [--constraint <texte>] [--stdout]
python -m novel_architect market-save --project <dossier> --file <market_pack.json>
python -m novel_architect market-status --project <dossier>
python -m novel_architect first-10-retention --project <dossier> [--stdout]
python -m novel_architect save-first10-plan --project <dossier> --file <first10.json>
python -m novel_architect status --project <dossier>
python -m novel_architect prepare --project <dossier> [--query <texte>]
python -m novel_architect beat-candidates --project <dossier> --chapter <n>
python -m novel_architect beat-select --project <dossier> --chapter <n> --file <selection.json>
python -m novel_architect apply-beat-selection --project <dossier> --chapter <n>
python -m novel_architect review --project <dossier> --chapter <n>
python -m novel_architect export-signal-prompts --project <dossier> --chapter <n>
python -m novel_architect save-model-signal --project <dossier> --chapter <n> --signal <type> --file <signal.json>
python -m novel_architect commit --project <dossier> --chapter <n>
python -m novel_architect resume --project <dossier> --chapter <n> [--query <texte>]
python -m novel_architect first3-review --project <dossier>
python -m novel_architect save-first3-review --project <dossier> --file <first3_verdict.json>
python -m novel_architect batch-review --project <dossier> --start <a> --end <b>
python -m novel_architect volume-review --project <dossier> [--volume <n>]
python -m novel_architect benchmark --project <dossier>
python -m novel_architect rebuild --project <dossier>
python -m novel_architect rebuild-index --project <dossier>
python -m novel_architect validate --project <dossier> --chapter <n>
python -m novel_architect learn --sample-dir <dossier>
python -m novel_architect save-feedback --project <dossier> --chapter <n> --file <feedback.json>
python -m novel_architect feedback-diagnose --project <dossier> --chapter <n>
python -m novel_architect feedback-summary --project <dossier>
python -m novel_architect gen-prompt --project <dossier> [--outline-file <chemin>] [--stdout]