Bel article
Principes de base
Plus le contenu généré par l'IA est complexe, plus le support de sortie est important. La valeur du HTML réside dans l'augmentation simultanée de la densité de l'information, de la clarté visuelle, de la facilité de partage et des capacités interactives : tableaux, SVG, CSS, extraits de code, widgets réglables, boutons de copie et d'exportation permettent au lecteur non seulement de « finir de lire », mais de comparer, localiser, ajuster, vérifier et continuer à utiliser. Le but de Beautiful Article est de transformer un matériel textuel autrement ennuyeux, linéaire et difficile à digérer en un article Web monocouche qui offre une meilleure expérience visuelle, un rythme de lecture plus clair et est plus facile à réviser et à partager.
Limites (vérifier d'abord si cette compétence est appropriée)
- Le produit final principal est un article HTML unique, pas une application Web.
- L'article peut avoir une couche libre
Raw(HTML/CSS/JS/React arbitraire : interactivité, mise en page, animations, petits outils, diagrammes SVG/canvas à la demande), mais doit servir la lecture, l'explication, l'argumentation, le rythme ou l'esthétique. - Ne pas générer : backend, formulaires, tableaux de bord, prototypes de produits, applications Web génériques.
- La densité de l'information est confirmée par l'utilisateur ; par défaut, conserve 100 % des informations et génère un article Web long.
Si l'utilisateur veut une application plutôt qu'un article, arrêtez-vous pour clarifier, n'entrez pas dans cette compétence.
Aperçu du flux de travail
Phase 0 Intake Déterminer si l'on entre dans cette compétence + type d'article préliminaire
▼
Phase 1 Source → Markdown URL/PDF/DOCX/MD/texte → source.md + extraction-notes.md
└ Agent principal : auto-vérification avec 5 listes de contrôle (SubAgent uniquement pour les sources complexes/peu fiables)
▼
Phase 2 Planification éditoriale Un plan.md (quatre sections : Brief / Outline / Theme / Assets)
└ Agent principal : auto-vérification en ligne (pas de SubAgent, pas de fichier de révision)
▼
Phase 3 Point de contrôle du plan ★Point de contrôle 1 : doit s'arrêter. Confirmer 5 éléments un par un : type d'article (avec taux de rétention par défaut) / thème / mise en page / mode d'illustration / couverture
▼
Phase 4 Première diffusion Première page + première section + un bloc visuel représentatif (création de l'échafaudage ici)
└ SubAgent de révision de la première diffusion (écrit review/first-spread-review.md)
└ ★Point de contrôle 2 : doit s'arrêter. Confirmer 2 éléments un par un : conclusion d'acceptation / mode de développement A/B
▼
Phase 5 Construction complète de l'article Générer l'article Web complet (agent unique par défaut, peut être isolé par section si très long)
└ SubAgent de révision de section (retourne pass/fail par message, pas besoin d'écrire de fichier de révision)
▼
Phase 6 Révision finale Révision finale sous trois angles : éditorial / visuel / technique (écrire review/final-review.md)
▼
Phase 7 Réparation Réparations par tranches minimales, écrire repair-log.md uniquement s'il y a des réparations
▼
Phase 8 Livraison ★Point de contrôle 3 : doit s'arrêter. Confirmer la décision de livraison → livrer article.html + brève note éditoriale
Structure de l'espace de travail (créé par l'échafaudage ; ces fichiers sont la mémoire à long terme de la compétence, ne vous fiez pas uniquement au contexte de la discussion pour vous souvenir des décisions) :
<workspace>/
source/ original.* source.md source.<langue>.md (si traduction nécessaire) extraction-notes.md
plan/ plan.md # Fichier de planification unique : quatre sections Brief / Outline / Theme / Assets
article/ Cover.tsx (par défaut) Article.tsx sections/ raw-blocks/ assets/ article.html (produit final)
review/ first-spread-review.md final-review.md # Seuls ces deux sont des produits réguliers
source-review.md (uniquement pour les sources complexes) repair-log.md (uniquement s'il y a des réparations)
index.html package.json vite.config.ts tsconfig*.json (Outils de construction)
Protocole strict d'assurance qualité (tout au long de la compétence)
La méthode d'assurance qualité varie selon le nœud – ce n'est pas tous les contrôles qui nécessitent un SubAgent, ni tous qui nécessitent un fichier. L'ouverture erronée d'un SubAgent / l'écriture erronée d'un fichier est le principal problème de performance. Suivre strictement le tableau ci-dessous :
| Nœud | Méthode d'assurance qualité | Produit | Pourquoi |
|---|---|---|---|
| Phase 1 Source (par défaut) | Auto-vérification en ligne par l'Agent principal avec 5 points de contrôle | Aucun fichier | L'Agent principal doit de toute façon lire source.md |
| Phase 1 Source (uniquement source complexe/peu fiable) | SubAgent de révision de source (diff avec original.*) | review/source-review.md | Les pertes silencieuses ne peuvent être détectées que par diff |
| Phase 2 Plan / Avant le point de contrôle 1 | Auto-vérification en ligne par l'Agent principal (interdiction d'ouvrir un SubAgent) | Aucun fichier | Le plan est une décision textuelle de 200 à 400 lignes, le contexte est chaud, un SubAgent à froid serait plus lent |
| Phase 4 Première diffusion / Avant le point de contrôle 2 | SubAgent de révision de la première diffusion | review/first-spread-review.md | La première page donne le ton, un œil indépendant supplémentaire est plus sûr |
| Phase 5 Chaque section | SubAgent de révision de section | Retourne pass/fail + points de réparation par message (pas de fichier) | Un article peut avoir 5 à 15 sections, N fichiers de révision ne seront plus lus |
| Phase 6 Révision finale / Avant le point de contrôle 3 | SubAgent de révision éditoriale + visuelle + technique | review/final-review.md | Partie de la livraison, précieux pour la documentation |
Règles absolues :
- Au point de contrôle du plan (Phase 2 → Point de contrôle 1), il est strictement interdit d'ouvrir un SubAgent pour l'assurance qualité. Après avoir écrit
plan.md, l'Agent principal vérifie sur place les 5 points de contrôle (voir la section d'auto-vérification du plan dansreferences/review-checklist.md), corrigeplan/plan.mden conséquence, n'écrit aucun fichier de révision, puis entre dans le Point de contrôle 1. - La première diffusion / la finale doivent utiliser un SubAgent (à ces nœuds, la valeur du SubAgent > le coût) ; uniquement si l'environnement du SubAgent n'est pas détectable, l'Agent principal prend le relais et mentionne « Environnement sans SubAgent, prise en charge par l'Agent principal » en tête du fichier.
- Le réviseur de section utilise un SubAgent, mais la valeur de retour est un message (pass / fail + points de réparation) ; l'Agent principal répare directement les éléments en échec, ne laissez pas le SubAgent écrire le fichier
review/section-NN-review.md. - En recevant toute conclusion d'assurance qualité – corrigez d'abord le produit selon les éléments en échec, puis rapportez « fait + conclusion d'auto-vérification + ce qui a été changé ». Signaler directement la conclusion brute sans réparer = violation.
- Règle absolue de collecte des décisions · Interdiction de choisir silencieusement à la place de l'utilisateur : à chaque point de contrôle (1 / 2 / 3), tous les éléments de décision nécessitant la confirmation de l'utilisateur doivent être listés indépendamment + attendre la réponse de l'utilisateur. L'Agent peut recommander (« Je recommande X parce que … »), mais ne peut pas dire « J'ai déjà décidé X pour vous, dites-moi si ce n'est pas bon » – cela équivaudrait à priver l'utilisateur du choix.
- Priorité : si l'environnement dispose de l'outil
AskQuestion, chaque élément de décision est une question indépendante (un appel peut transmettre plusieurs questions), l'utilisateur peut confirmer un par un avec des cartes de sélection. - Sinon : arrêtez-vous et listez tous les problèmes numérotés dans le message (chaque problème occupe un paragraphe, écrivez clairement l'élément recommandé + la raison + les alternatives), dites explicitement « J'attends vos réponses une par une avant de continuer », ne continuez aucun travail ultérieur.
- Jamais : regrouper plusieurs décisions en une question oui/non du type « Tout sélectionner ce que je recommande / Tout va bien ? » ; ne pas passer par défaut à l'étape suivante après une « phrase de recommandation ».
- Priorité : si l'environnement dispose de l'outil
Les listes de contrôle et les modèles de prompt SubAgent pour chaque nœud se trouvent dans references/review-checklist.md.
Guide de lecture des fichiers par phase (chargement progressif, ne pas tout lire à la fois)
| Phase | À lire absolument | À consulter si nécessaire |
|---|---|---|
| Phase 0 Intake | references/harness.md | —— |
| Phase 1 Source → MD | references/source-to-markdown.md | scripts/source-to-markdown-markitdown.py · scripts/source-to-markdown.py |
| Phase 2 Planification | references/article-types.md · references/information-density.md · references/plan-template.md · references/theme-selection.md · references/layout.md · references/asset-policy.md · references/cover.md (idées de composition de couverture) | references/article-types/<type>.md · theme-profiles/*.md |
| Phase 4 Première diffusion / Phase 5 Construction (revoir chaque section) | references/section-build.md · references/component-policy.md · references/raw-policy.md · Thème choisi theme-profiles/<id>.md · Couverture : references/cover.md | references/scaffold.md (une fois pour créer le projet) · references/html-output.md |
| Phase 6/7 Révision et réparation | references/review-checklist.md · references/repair-policy.md | —— |
| Phase 8 Livraison | references/html-output.md | references/pdf-output.md (uniquement si l'utilisateur choisit l'export PDF) |
Dans les longues conversations, l'agent peut oublier les principes – la Phase 5 répète N sections, avant chaque section, revoir
component-policy.md+raw-policy.md+ le thème actueltheme-profiles/<id>.md.
Phase 0 – Intake
Déterminer si l'on entre dans cette compétence, donner le type d'article préliminaire et le mode de sortie (par défaut, HTML unique).
| Ce que l'utilisateur donne | Ce qu'il faut faire |
|---|---|
| Un ou plusieurs éléments (URL/PDF/DOCX/MD/texte/capture d'écran) | Passer à la Phase 1 |
| Dit seulement « fais-moi un article X » mais sans élément | Demander en retour : demander d'abord le matériel ou le plan. La compétence n'invente pas le contenu pour l'utilisateur |
| Demande clairement une application / un outil / un tableau de bord | S'arrêter pour clarifier, ne pas entrer dans cette compétence |
Capturer la langue cible : enregistrer dès le début la langue finale souhaitée pour l'article (par exemple, si l'utilisateur dit « en chinois / fais-en une version anglaise », etc.).
- L'utilisateur spécifie une langue → l'enregistrer dans la section « Brief » de
plan/plan.mdcomme « langue cible ». Si elle est différente de la langue du matériel source, la Phase 1 doit d'abord produire une traduction idiomatique du texte source, puis rédiger sur cette base (voir Phase 1). - L'utilisateur ne spécifie pas → par défaut, la langue finale de l'article suit la langue du matériel source, sans traduction.
Auto-vérification : l'utilisateur veut-il un article ou une application Web ? A-t-il besoin de toutes les informations ? Faut-il d'abord demander plus de matériel ? L'utilisateur a-t-il spécifié la langue finale ? Est-elle différente de la langue source ?
Phase 1 – Source → Markdown
Uniformiser toute entrée en source/source.md, écrire les incertitudes dans source/extraction-notes.md.
Les règles et le traitement des différents types d'entrée se trouvent dans references/source-to-markdown.md ; vous pouvez utiliser le chemin principal MarkItDown ou un script de repli léger pour l'extraction PDF/DOCX/HTML.
Après enregistrement, l'Agent principal effectue une auto-vérification en ligne (les 5 points de contrôle de references/source-to-markdown.md), corrige en fonction des conclusions, puis passe à la Phase 2 ; uniquement si extraction-notes.md marque la source comme peu fiable / complexe, on passe à un SubAgent de révision de source indépendant qui effectue une vérification par diff avec original.* (écrit review/source-review.md).
Traitement de la langue (immédiatement après l'extraction) : déterminer la langue de source.md.
- L'utilisateur n'a pas spécifié de langue cible, ou la langue cible est identique à la source → pas de traduction, la rédaction ultérieure se base directement sur
source.md, la langue finale de l'article = langue source. - L'utilisateur a spécifié une langue cible différente de la source → d'abord produire une traduction idiomatique
source/source.<langue>.md(par exemplesource.zh.md/source.en.md), qui servira de base factuelle pour les Phases 2+ ; le texte originalsource.mdest conservé pour consultation. Exigences de traduction : utiliser une langue cible idiomatique, éliminer le ton de traduction (réorganiser les phrases selon les habitudes d'expression de la langue cible, pas de traduction mot à mot, pas de structures de phrases étrangères / d'empilement passif / de ponctuation étrangère), préserver l'exactitude des termes / chiffres / code / formules / citations, la structure et le taux de rétention des informations restent inchangés. La note de traduction est écrite dansextraction-notes.md.
Phase 2 – Planification éditoriale
Formuler un plan éditorial, ne pas écrire directement du HTML. Produire uniquement un fichier plan/plan.md (quatre sections : Brief / Outline / Theme / Assets), modèle dans references/plan-template.md :
- Brief : public cible / type d'article / taux de rétention des informations / ce qui doit être conservé / ce qui peut être supprimé / ton / idées principales / objectif de lecture / langue cible / largeur de mise en page / TOC / stratégie d'illustration.
- Outline : Hero / Lead / Résumé / Liste des sections / quelles informations sont conservées dans chaque section / si chaque section nécessite Raw · Table · CodeBlock · Formula · Image / manière de conclure.
- Theme : thème choisi + raison + explication des conflits (voir
references/theme-selection.md). - Assets : stratégie d'illustration et plan par image (voir
references/asset-policy.md; en modenone, une phrase suffit pour cette section).
Le routage des types d'articles se trouve dans references/article-types.md ; la densité de l'information et les proportions des composants dans references/information-density.md.
Méthode d'auto-vérification · Contrainte forte : après avoir écrit plan/plan.md, l'Agent principal vérifie en ligne les 5 points de contrôle du plan (voir la section d'auto-vérification du plan dans references/review-checklist.md), corrige plan/plan.md en conséquence, puis passe directement au Point de contrôle 1, interdiction d'ouvrir un SubAgent, interdiction d'écrire review/plan-review.md.
Phase 3 – Point de contrôle du plan (★Nœud dur · Point de contrôle 1, doit s'arrêter)
Règle absolue : interdiction de choisir silencieusement à la place de l'utilisateur. Chaque élément de décision doit être listé indépendamment et attendre la réponse de l'utilisateur.
On peut recommander (« Je recommande X parce que … »), ne pas dire « J'ai déjà décidé X pour vous, dites-moi si ce n'est pas bon » – cela équivaudrait à faire passer la valeur par défaut en fraude et à priver l'utilisateur du choix.
Méthode de collecte (selon l'environnement, choisir une des deux) :
- Priorité à l'outil
AskQuestion: chaque élément est transmis comme une question indépendante (un appel peut transmettre plusieurs questions), l'utilisateur confirme un par un avec des cartes de sélection. - Sans outil
AskQuestion: arrêtez-vous et listez chaque problème numéroté + en paragraphe indépendant + écrivez clairement l'élément recommandé + la raison + les alternatives dans le message, dites explicitement « J'attends vos réponses une par une avant de continuer », ne continuez aucun travail ultérieur.
Quelle que soit la méthode : chaque décision indépendante correspond à une question indépendante, ne pas regrouper en un oui/non du type « Tout va bien ? ».
Les 5 éléments à confirmer indépendamment (indispensables) :
| # | Élément de décision | Options (étiquette sémantique · inclut le taux de rétention d'information par défaut) | Notes |
|---|---|---|---|
| 1 | Type d'article (taux de rétention inclus) | Long article archivé longform · ~100% / Rapport de recherche / Analyse formelle full-report · ~80% / Étapes pédagogiques / Guide de démarrage tutorial · ~90% / Explication de concept / système explainer · ~80% / Dialogue / Interview / Podcast dialogue · ~80% / RP / Plan / Révision d'incident review · ~70% / Opinion / Commentaire / Récit essay · ~70% / Apprentissage interactif / Comprendre un concept en jouant interactive-explainer · ~25% d'extraits originaux + 75% reconstruit par IA / Résumé de décision / Pour les gens pressés briefing · ~50% / Principalement visuel / Pour la diffusion visual-essay · ~40% | L'IA en recommande un et donne une raison. Le taux est déjà lié au type, pas de question séparée (sinon on aurait des combinaisons absurdes comme longform + 20%). Si l'utilisateur veut s'écarter du standard, il peut écrire une phrase en texte libre (ex. « je veux longform + 60% »), voir « Comment s'écarter du standard » ci-dessous |
| 2 | Thème | tufte / press / autres thèmes enregistrés (lire theme-profiles/index.json) | L'IA en recommande un et donne une raison |
| 3 | Largeur de mise en page | narrow / regular / wide / full | L'IA en recommande une ; par défaut regular |
| 4 | Mode d'illustration (obligatoire · pas de « passer par défaut ») | none / user-assets / placeholders / ai-generated | Une phrase : « Décide seulement si l'on utilise l'image externe ; Raw n'est pas affecté » |
| 5 | Couverture (image de titre format livre 3:4, au-dessus du TOC + du corps) | On (par défaut) / Off | L'IA recommande « On », et donne une idée de composition (quel visuel principal + quel modèle de couverture A/B/C/D/E choisir). Pour briefing / dialogue, peut recommander « Off ». Voir references/cover.md |
Le TOC est activé par défaut : comme il n'a qu'un seul interrupteur + qu'il devrait être activé pour presque tous les articles, on peut le mentionner en une phrase dans le message d'ouverture du Point de contrôle du plan : « TOC activé par défaut, dites-moi si vous voulez le désactiver », pas besoin d'en faire une question séparée.
Éléments déjà en valeur par défaut, pas besoin de demander séparément (mais il faut toujours les mentionner dans le message d'ouverture en disant « si vous voulez changer, dites-le moi », pour donner à l'utilisateur une chance de revenir en arrière, ne pas les cacher complètement) :
- Langue finale de l'article : suit la langue source (sauf si l'utilisateur a déjà spécifié / si la traduction est déjà faite).
- Autorisation de supprimer, réorganiser, réécrire le ton dans l'édition : autorisé par défaut (exécuté selon le taux de rétention ci-dessus).
- Demander à voir d'abord une maquette de la première page : par défaut, on le fait (c'est la Phase 4).
- TOC : activé par défaut.
Si l'utilisateur dit « Vous décidez » pour le thème → prendre votre première recommandation, mais dans les options, il faut toujours la mettre en concurrence avec les autres, marquer « Par défaut · Recommandé par l'IA », laisser une marge de recul, ne pas sauter directement la question sur le thème.
Comment s'écarter du taux de rétention « standard » : chaque type d'article a un taux de rétention recommandé intégré (voir tableau ci-dessus). Dans la grande majorité des cas, on suit le standard. Si l'utilisateur veut un réglage fin (par exemple « longform mais seulement 60% » → un long article fortement édité), demandez à l'utilisateur d'écrire une phrase en texte libre après le message d'ouverture : « Je veux + <X%> » pour remplacer. L'IA, après avoir reçu ce remplacement, doit enregistrer dans la section Brief de plan/plan.md à la fois « type / taux standard / remplacement par l'utilisateur à X% », et rappeler à l'utilisateur qu'il s'agit d'une « combinaison non standard » – ces combinaisons nécessitent que l'Agent principal ajuste manuellement le rapport texte/visuel lors de la rédaction de chaque section.
Modèle de message d'ouverture du Point de contrôle du plan (envoyer d'abord une brève explication avant de collecter les décisions) :
plan/plan.md a été écrit (auto-vérification réussie). Je vais confirmer avec vous un par un 5 éléments : type d'article / thème / largeur de mise en page / mode d'illustration / couverture.
Mes recommandations sont données ici pour référence (je ne choisis pas à votre place) :
- Type : <X> (avec taux de rétention standard <Y%>. Raison : …)
- Thème : <theme> (Raison : …)
- Largeur de mise en page : <width> (Raison : …)
- Mode d'illustration : <stratégie> (Raison : …)
- Couverture : On / Off (Raison : … ; si On, idée de composition : …)
Valeurs par défaut que vous pouvez modifier : la langue suit la langue source ; édition, suppression, réorganisation autorisées ; TOC activé ; une maquette de la première page sera faite ensuite.
Si vous voulez vous écarter du taux de rétention standard du type, dites-moi directement le pourcentage après avoir répondu ci-dessous (par exemple « longform mais seulement 60% »).
Je vais maintenant vous demander un par un.
Après avoir envoyé ce message ci-dessus, immédiatement, utiliser AskQuestion pour transmettre les 5 questions (ou, dans un environnement sans outil, lister les 5 questions numérotées et attendre la réponse). Les 5 réponses doivent toutes être collectées pour passer à la Phase 4 ; si l'utilisateur a donné un « taux de rétention non standard » en texte libre, confirmer d'abord que l'IA l'a enregistré dans plan/plan.md avant de passer à la Phase 4.
Phase 4 – Première diffusion (la « validation du premier chapitre » de l'article)
Faire d'abord « couverture (si activée) + première page + première section + un bloc visuel représentatif ». L'échafaudage crée l'espace de travail ici :
# Couverture activée par défaut
bash <chemin-vers-beautiful-article>/scripts/scaffold.sh ./mon-article --theme=<id>
# Point de contrôle 1 : l'utilisateur a choisi « Couverture · Off »
bash <chemin-vers-beautiful-article>/scripts/scaffold.sh ./mon-article --theme=<id> --no-cover
bash <chemin-vers-beautiful-article>/scripts/scaffold.sh --list-themes
Il crée un espace de travail Vite + React + TS (installe la dernière version publiée de reacticle depuis npm) + les répertoires de mémoire source/ plan/ review/ + l'assembleur article/Article.tsx + un composant de section d'exemple (+ article/Cover.tsx par défaut, sauf --no-cover). Voir references/scaffold.md pour plus de détails.
La première page (Hero / Lead) est écrite dans l'assembleur article/Article.tsx ; la première section doit être écrite comme un composant indépendant article/sections/01-*.tsx (c'est le point d'ancrage du code pour les sections suivantes, voir references/section-build.md). La couverture (si activée) remplace <CoverPlaceholder /> dans article/Cover.tsx par une composition graphique et textuelle personnalisée selon le thème et le sujet de l'article, le squelette (conteneur 3:4 + saut de page pour l'impression) ne doit pas être modifié. Les directives de conception de la couverture se trouvent dans references/cover.md. Aperçu avec npm run dev. Cela détermine le ton du titre / la taille de la police / la densité du contenu / le style de Raw / la manière d'illustrer / si le thème est approprié.
Après avoir terminé la première section, créer le SubAgent de révision de la première diffusion conformément au protocole strict d'assurance qualité, écrire review/first-spread-review.md (inclut l'auto-vérification en 5 points de la couverture, voir references/cover.md), puis passer au Point de contrôle 2 après correction.
Point de contrôle 2 · Première diffusion (★Nœud dur, doit s'arrêter)
Faire valider à l'utilisateur la première page + la première section, et choisir le mode de développement ultérieur. Les mêmes règles absolues de collecte des décisions du Point de contrôle 1 s'appliquent : les deux éléments sont confirmés indépendamment, interdiction de les regrouper ; priorité à AskQuestion, sinon lister numéroté et attendre la réponse.
Envoyer d'abord un bref message :
La première page + la première section sont prêtes, npm run dev pour un aperçu sur localhost.
Les conclusions de l'assurance qualité se trouvent dans review/first-spread-review.md (j'ai déjà corrigé selon les éléments en échec, liste de ce qui a été modifié).
Veuillez confirmer indépendamment les deux choses suivantes : 1) Conclusion d'acceptation 2) Mode de développement ultérieur.
Puis, avec AskQuestion, transmettre deux questions indépendantes (ou lister deux questions numérotées et attendre la réponse) :
- Conclusion d'acceptation – Options :
Acceptée · Passer à la génération complète/Modifications locales · Je vais dire quoi modifier dans un autre message/Thème ou mise en page inadapté · Revenir au Point de contrôle 1. - Mode de développement ultérieur – Options :
A · Agent unique séquentiel (par défaut · le plus stable · le plus cohérent stylistiquement)/B · Multi-agent parallèle (le plus rapide · légères différences stylistiques).
Ne pas regrouper ces deux choses en « Accepté + A, OK ? » – l'utilisateur pourrait « accepter mais vouloir B » ou l'inverse. Passer à la Phase 5 après avoir reçu les deux réponses.
Phase 5 – Construction complète de l'article
Générer l'article complet selon le mode de développement choisi au Point de contrôle 2. Voir references/section-build.md + references/component-policy.md + references/raw-policy.md.
Règle absolue · Chaque section doit être un fichier composant indépendant (article/sections/NN-*.tsx), il est strictement interdit d'écrire plusieurs sections directement dans un seul composant. article/Article.tsx est uniquement un assembleur : il importe et ordonne les sections, possédé par l'Agent principal. Les grands blocs Raw sont également isolés dans article/raw-blocks/NN-*.tsx. L'isolation au niveau fichier est la condition préalable au parallélisme multi-agent.
Mode de développement (choisi au Point de contrôle 2) :
- A · Agent unique séquentiel (par défaut) : l'Agent principal écrit chaque
sections/NN-*.tsxséquentiellement, le plus stable, le plus cohérent stylistiquement. - B · Parallèle multi-agent : chaque sous-agent possède un fichier
sections/NN-*.tsxet le développe en parallèle ; l'Agent principal est responsable de la fusion et de la stabilité – maintient l'import et l'ordre dansArticle.tsx, exécutenpm run typecheck/build, assure la cohérence du thème et du style, résout les conflits. Le modèle de prompt pour le sous-agent se trouve dansreferences/section-build.md.
Autres principes : le corps du texte est le sujet principal ; tous les Raw utilisent les jetons de thème --ra-*, pas de styles sauvages ; la rétention de 100% des informations se fait principalement par la structure du texte long, avec Raw / illustrations en renfort ; une faible densité d'information peut augmenter la proportion de blocs visuels, mais il doit toujours s'agir d'une forme d'article.
Après chaque section, doit passer par le SubAgent de révision de section conformément au protocole strict d'assurance qualité : la tâche de l'outline est-elle terminée ? le taux de rétention des informations est-il respecté ? la continuité avec les sections précédentes/suivantes ? y a-t-il une composante excessive ? y a-t-il assez de texte de corps ? le Raw et les illustrations ont-ils un objectif clair ? le numéro de la section est-il cohérent ?
Le SubAgent retourne pass/fail + points de réparation par message (si pass, une ligne OK ; si fail, lister les points de réparation), ne pas écrire le fichier review/section-NN-review.md. L'Agent principal, après avoir reçu les éléments en échec, corrige directement le fichier de la section concernée, puis rend compte de la livraison de cette section.
Phase 6 – Révision finale (révision sous trois angles)
Valider sous les angles du lecteur / du thème / de la technique, produire review/final-review.md + une liste de réparations.
La liste de contrôle complète se trouve dans references/review-checklist.md. Trois réviseurs sont recommandés (en l'absence de Teams, au moins un SubAgent indépendant) :
- Réviseur éditorial : qualité d'article, choix d'information, structure.
- Réviseur visuel : thème, Raw, illustrations, mobile.
- Réviseur technique : construction, console, code/formules, accessibilité.
Lignes rouges principales : c'est toujours un article (pas une application) · le taux de rétention des informations correspond au Plan · les informations devant être conservées ne sont pas perdues · le thème est cohérent · les Raw n'ont pas de styles sauvages · pas d'odeur d'IA évidente · lisible sur desktop + mobile · le HTML peut être construit, ouvert et partagé.
Phase 7 – Réparation (tranche minimale)
Réparer par unité minimale, règles dans references/repair-policy.md. Interdictions : ne réécrire tout l'article que pour un seul retour / ne modifier la structure de l'article déjà confirmée que pour corriger un problème visuel / ne supprimer le contenu que l'utilisateur a spécifié comme devant être conservé pour compresser l'information. Écrire review/repair-log.md uniquement s'il y a des réparations (pas de réparation / réussi du premier coup, ne pas écrire).
Point de contrôle 3 – Final (★Confirmation de livraison)
Après avoir terminé la révision finale, s'arrêter pour que l'utilisateur confirme indépendamment la décision de livraison (ne pas dire « Je vais exporter le HTML, c'est bon comme ça » et passer directement). Priorité à AskQuestion, sinon lister les questions numérotées dans un message et attendre la réponse.
- Décision de livraison – Options :
Accepté · Exporter HTML pour livraison/Accepté · Exporter à la fois HTML + PDF/Il y a encore des réparations locales · Je vais lister exactement quoi réparer/Faire une pause · Je veux revoir.
Il n'y a qu'une seule décision, mais il faut toujours s'arrêter activement pour demander, ne pas passer silencieusement à l'export HTML par défaut.
Phase 8 – Livraison
Construire et livrer (commandes dans references/html-output.md) :
article/article.html(page unique autonome, CSS + JS intégrés, ouvrable hors ligne) – Produit principal.- Optionnel
article/article.pdf: généré uniquement si l'utilisateur a choisi « Accepté · Exporter à la fois HTML + PDF » au Point de contrôle 3. Commande :
Le script détecte le système…bash <chemin-vers-beautiful-article>/scripts/html-to-pdf.sh
…
[Le reste a été tronqué pour la traduction]
Si l'assistant a l'impression que le fichier a été tronqué, il doit demander à l'utilisateur de fournir la suite.