Communitygithub.com

ayase0307/ai-comic-drama

Assiste à la création de bande dessinée animée (AI漫劇) / motion comic / court métrage, depuis l'adaptation de roman, le scénario et le storyboard jusqu'aux prompts et à la génération média optionnelle. Intègre des vérifications déterministes (quanta de durée, graduation des preuves, registre de dépendances au niveau des segments, catalogue des échecs) et un point d'entrée unique `h3d`. La génération d'images ou de vidéos dépend des outils de l'Agent et des backends compatibles connectés ; cette compétence ne suppose pas de capacité de génération vidéo intégrée à l'Agent et peut se limiter à la livraison d'un script textuel, d'un storyboard ou d'un projet de prompts.

Qu'est-ce que ai-comic-drama ?

Cette compétence pour agents IA (compatible Claude Code, Cursor, Codex, etc.) orchestre la production complète de « bandes dessinées animées », motion comics ou courts métrages à partir d'un roman ou d'une histoire. Elle guide l'agent à travers 8 étapes : cadrage, adaptation, design des personnages, scénario, storyboard, rédaction des prompts, génération vidéo, sous-titrage et montage. Chaque étape est strictement contrôlée par des règles déterministes (quanta de durée en 17n+5, graduation des preuves VERIFIED, registre de dépendances `h3d deps`, catalogue des échecs `h3d catalog`). L'entrée unique `h3d` (via `h3d next`) empêche toute improvisation de l'agent : elle lit l'état du projet et affiche la seule commande autorisée à chaque instant, avec le document de référence à consulter. La compétence impose une gestion rigoureuse des décisions : chaque choix de l'utilisateur (style, format, backend de génération) est enregistré dans `decisions.json` via `h3d decide`, et les préférences non formalisées sont traquées par un registre d'exigences (`build_requirements_ledger.py`) soumis à un examen par un sous-agent frais avant validation. Elle intègre également un module dédié aux combats et effets spéciaux (`h3-combat-impact`) et propose des mécanismes de « supervisions » et « relecture à l'aveugle » pour garantir la qualité. La compétence ne suppose pas que l'agent dispose d'un backend de génération vidéo intégré ; la sortie peut se limiter à un livrable textuel (script, storyboard, prompts).

Compatible avec✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/ayase0307/ai-comic-drama/tree/HEAD

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Fabrication de bande dessinée animée (version Agent uniquement)

Règles de démarrage (à suivre à chaque fois, sans exception)

  1. Exécutez d'abord python scripts/h3d.py next --root <projet> , puis suivez l'unique instruction qu'il imprime et lisez d'abord la référence qu'il désigne. Ne planifiez pas votre propre flux et ne sautez pas d'étape.
  2. Les décisions finales de l'utilisateur sont toujours prises via h3d decide <id> <valeur> --quote "<paroles originales de l'utilisateur>" et écrites dans decisions.json (style visuel, format d'image, politique de dialogue, moteur de design, politique d'acceptation, méthode de montage…). Ne les écrivez pas seulement dans des notes, et ne décidez pas à la place de l'utilisateur.
  3. Ne modifiez pas manuellement review/project-state.json. L'état ne peut être écrit que par build_stage_review.py ; toute modification manuelle sera considérée comme un blocage par h3d next. Si l'étape 6 (QA technique) est PARTIAL et que l'utilisateur l'approuve après l'avoir vue, utilisez --approve-stage 6 --override --reason "<raison de l'utilisateur>".
  4. Les conclusions de chaque segment de l'étape 6 sont systématiquement enregistrées via h3d verdict dans review/verdicts.json (pass / warn / fail + une phrase de raison + image de preuve), classées selon acceptance_policy. 3a. Le backend de génération d'images est choisi par l'utilisateur, pas par défaut : avant de générer les images de l'étape 2 ou les compositions de l'étape 4, exécutez h3d imagegen --detect --root <projet> pour lister les outils détectés comme disponibles (indiquez la raison pour ceux qui ne le sont pas), puis demandez à l'utilisateur de choisir – même si un seul outil est détecté, posez la question ; après la réponse, exécutez h3d imagegen --set <backend> [--stage 2|4] --quote "<paroles originales de l'utilisateur>". Si h3d next rencontre un backend non choisi, ou choisi mais désormais indisponible, il vous demandera de consulter l'utilisateur (references/tooling.md §2.4.1). 4a. Les décisions à prendre par l'utilisateur sont générées via h3d inbox pour produire une boîte de réception de décisions à soumettre à l'utilisateur (uniquement les exceptions). Les étapes autorisées par l'utilisateur sont exécutées selon h3d next via h3d approve --auto. Les étapes 0, les images de design des personnages et le timbre vocal de chaque personnage nécessitent toujours une décision humaine (voir references/tooling.md §2.6).
  5. N'exécutez pas deux runners vidéo simultanément ; si le registre (ledger) contient des travaux en attente / en cours, ne faites que collecter (h3d collect), sans soumettre de nouveaux travaux.
  6. Lorsque vous rencontrez PARTIAL ou duration_drift, arrêtez-vous, traitez selon references/tooling.md §4 et informez l'utilisateur ; ne contournez pas par vous-même.
  7. Le format de film final par défaut = bande dessinée animée longue : la priorité absolue est de raconter clairement l'histoire, chaque événement clé de l'œuvre originale doit être décrit avec sa cause → son déroulement → sa conséquence (incluant motivation, changement de temps et de lieu). Ne compressez pas les événements en fonction des secondes par épisode. Par défaut, pas de division en épisodes ; un seul long métrage continu. Le format court / série courte à fort crochet (1–2 minutes) n'est utilisé que si l'utilisateur le demande explicitement (via h3d decide series_format short). Les événements compressés, sautés ou insuffisamment expliqués sont rétablis par l'Agent selon l'œuvre originale (via event_coverage.py), sans suppression automatique ni consultation de l'utilisateur.
  8. Ne demandez pas l'avis de l'utilisateur pour l'adaptation du script : suivez toujours references/adapt/dialogue-first-adaptation.md (conservez tous les dialogues originaux, les dialogues seulement narrés peuvent être réécrits en les marquant invented, narration = voix intérieure du protagoniste VO ≤ 30 %, durée d'épisode non limitée, les coupures s'arrêtent à un point d'histoire naturel avec ancrage dans l'œuvre originale + raison, et l'intégralité des vérifications adapt_gate.py doit être passée avant la livraison).
  9. Avant de commencer, vérifiez d'abord la version de la compétence : si h3d --version ne correspond pas à la version enregistrée dans review/project-state.json du projet, synchronisez d'abord la compétence avant de travailler. Le même prompt peut avoir des seuils différents selon les versions (15→18 caractères par phrase, proportion de parole 60%→90%, durée minimale de plan 2.0→1.2 s, ajout de densité D2 et d'ouverture D4). Appliquer les anciennes règles à un nouveau projet entraînerait une refonte inutile. La copie de la compétence dans le répertoire d'installation n'est pas forcément un dépôt git ; si le dépôt source est local, effectuez d'abord un pull, puis remplacez l'intégralité du répertoire après avoir fait une sauvegarde.
  10. Pour une révision, procédez par lots, ne refaites pas plan par plan : pour un même type de problème (même structure de phrase, même défaut de paquet), corrigez tous les segments concernés en une seule fois, puis rebuild → h3d bind → h3d compile → refaire la signature de l'étape 4/5 (le lot = vérifiez d'abord plan par plan dans shot_intent que la cause racine est la même, ne corrigez pas en masse par type d'avertissement ; les segments corrigés à l'étape 5 suivent l'approbation par segment via --segments, pas --auto). Si vous refaites une signature après chaque correction de phrase, vous consommerez tout le temps de révision, et l'étape 5 bloquera si les empreintes de layer2 et des segments ne sont pas synchronisées. Le rebuild efface les champs sketch_* ; avant de rebuild, prenez un instantané avec shot_id, puis réécrivez après le rebuild. Si le nombre ou le code des segments change, synchronisez la table de storyboard de REMIX (via PUT /projects/{id}/storyboard) : l'interface / la salle de visionnage lit le nombre estimé de plans et le groupement par chapitre à partir de ce document, pas de segments-*.json. Si vous ne le mettez pas à jour, il affichera toujours l'ancienne planification (par exemple 133 plans vs 18 segments réels). Avant de remplacer, utilisez d'abord GET /jobs?project=<id> pour vérifier plan par plan qu'aucun travail n'est en attente pour les anciens codes – s'il n'y en a pas, remplacez l'intégralité du document. Lorsque l'utilisateur dit « fais le tirage » ou « organise toi-même la révision / la correction / la boucle » = exécutez de manière autonome une boucle complète (soumission → collecte → tirage aléatoire pour révision → correction → nouveau tirage) ; arrêtez-vous uniquement pour les étapes nécessitant une intervention humaine (approbation de l'étape 6, raison de dérogation de l'utilisateur) ; les rapports sont faits par « tour + 4 images de preuve + ce qui a été corrigé », pas après chaque tirage aléatoire.
  11. Le pack de référence l'emporte sur le prompt : tout ce qui se trouve dans le pack de la planche mère de REMIX apparaîtra dans chaque plan (bâtiments lumineux, sac à dos, ciel nocturne dans la planche mère sont tous comptés). Pour changer, changez de pack ou régénérez la planche mère ; n'utilisez pas de phrases négatives dans le prompt pour contourner – mentionner un accessoire = l'accessoire apparaît. Voir les détails dans references/remix-draft-loop.md.
  12. La version approuvée et la version finale sont séparées ; tout changement de version nécessite une nouvelle validation : videos/<segment>.mp4 contient toujours la version qui a passé la QA et a été signée ; les livrables pika768, super-résolution, et les tirages aléatoires de remplacement vont dans videos/final-768/ et sous-répertoires. Pour promouvoir un livrable en version approuvée = relancez h3d qa / h3d motion / --continuity → reconstruisez l'instantané de l'étape 6 → l'utilisateur re-signe ; ne remplacez pas simplement le fichier pour changer de version, car cela rendrait l'instantané signé et les preuves incohérents.

Vue d'ensemble

Selon le périmètre de livraison défini par l'utilisateur, réalisez l'adaptation du roman, le scénario, le storyboard de réalisation, les prompts, ou utilisez les outils d'image / vidéo réellement disponibles pour générer le média. Les livrables textuels peuvent être fournis indépendamment ; la génération de média nécessite les outils correspondants ou un backend connecté (FreeVideo est un adaptateur optionnel, cela ne signifie pas que chaque Agent dispose d'une génération vidéo intégrée). Sans appel effectif à un outil de génération, ne prétendez pas avoir produit une image ou une vidéo. Un roman ne peut pas être utilisé directement comme script ; passez toujours par l'étape 1 d'adaptation. Si vous reprenez un projet existant (pas créé de zéro par vous), auditez-le d'abord avant de continuer : lisez d'abord references/audit-inherited-project.md, ne continuez pas le storyboard de l'agent précédent – un flux amont défectueux vous fera refaire chaque plan. Avant de déclarer « actif dupliqué » ou « erreur de contenu », vérifiez toujours la bible et les numéros de ligne de l'œuvre originale, ne vous fiez pas uniquement aux images ou aux noms de fichiers.

Cette page est la page d'opérations : ce qu'il faut faire à chaque étape, ce qu'il est interdit de faire, quelle commande exécuter. Les principes, modèles, décisions concrètes et la liste complète des outils se trouvent dans references/skill-guide.md (le SKILL.md complet, chapitres inchangés), auquel h3d next vous renvoie pour la partie à lire.

Quand l'utiliser

  • « Transforme ce roman / cette histoire en bande dessinée animée, motion comic ou court métrage » / « Adapte ce roman en scénario de bande dessinée animée »
  • « Écris le storyboard / la table des plans / les prompts vidéo » / « Conçois le design des personnages / la bible des personnages » / « Transforme ce contenu produit en courte vidéo de vente »

Page d'opérations par étape

ÉtapeCe qu'il faut faireCe qu'il est interdit de faireQuelle commande exécuterLire d'abord
0 CadragePoser toutes les questions de cadrage en une fois (thème, support, style visuel, format d'image) avec valeurs recommandées ; politique de dialogue fixée à « dialogues originaux prioritaires » sans demander ; format de film final par défaut = bande dessinée animée longue (ne pas demander le nombre d'épisodes / la durée ; seulement si l'utilisateur demande explicitement un court métrage, exécutez h3d decide series_format short) ; style visuel par défaut = n° 14 « Peinture réaliste ancienne style chinois, ambiance cinématographique » (avec exemple, modifiable)Ne pas décider à la place de l'utilisateur ; ne pas sauter la rétropropagation de la volumétrie ; ne pas présumer le découpage en courts épisodesinit_project.py, h3d decide style/aspect_ratioreferences/pipeline.md, references/styles.md
1 AdaptationConserver la classification, intégrité de la couverture des événements (chaque événement : cause → déroulement → conséquence, les lacunes sont comblées par l'Agent) ; réécriture prioritaire des dialogues et découpage en épisodes selon le budget de dialogue ; structure des paragraphes ; dette de causalité ; avant livraison, tous les tests adapt_gate.py doivent passerUtiliser le roman directement comme script ; compresser les événements pour respecter une durée ; supprimer volontairement la couverture d'un événementevent_coverage.py, dialogue_budget.py, adapt_gate.py, h3d nextreferences/adapt/dialogue-first-adaptation.md, references/adapt/novel-to-manju.md, references/adapt/structure-and-pacing.md §zéro
2 Design des personnagesDétection des outils de génération d'images puis choix par l'utilisateur (même si un seul est disponible, demandez) ; générer d'abord le personnage principal ; auto-vérification puis régénération ; après décision sur l'outil, verrouillage pour toute la série ; chaque effet spécial du script doit avoir sa propre carte d'effet B- et une image de référence approuvée (pas d'image = pas d'accès à l'étape 5, E56)Présumer l'outil de génération d'images ; changer d'outil sans comparaison côte à côte ; approbation automatique (toujours faire valider le visage et les vêtements par l'humain)h3d imagegen --detect / --set (écrit design_engine), page de relecturereferences/consistency.md, references/styles.md
3 ScénarioRéécriture par scène, budget de dialogue (vitesse de parole du personnage 4.0 / 4.5 / VO 5.5 car./s, parole occupant 75–90 %), différences d'adaptation, relecture à l'aveugle avant livraison (sous-agent frais avec seulement le pack de matériel du script : build_blind_review.py --stage 3, règles dans references/blind-review.md)Envoyer un script dépassant le budgetestimate_duration.py --h3, sync_script.pyreferences/adapt/screenplay-format.md
4 StoryboardPour chaque plan, écrivez d'abord shot_intent (ce que le spectateur doit comprendre) puis les valeurs techniques, chaque choix est justifié dans choice_why ; le mouvement de caméra suit l'émotion du beat en consultant references/camera-moves-guide.md pour choisir move_preset (raison du choix dans la table de storyboard, le compilateur le déplie, move_lint émet un avertissement) ; chaque segment inclut le compte des personnages, pour les plans de dialogue écrivez la ligne de regard, pour les jonctions de segment écrivez l'état final et changez de position de caméra (continuity-ledger.md) ; Ref2VA par défaut = un plan = un visage identifiable (recadrage individuel, sauf pour les packs de personnages remix), pas de personnage dans les plans larges, la distance focale et la distance de l'objet sont écrites en paireEntrer en compilation sans image de composition PNG correspondante ; corriger en masse par type d'avertissement, modifier le contenu approuvé pour passer (foule vide, fond vide) ; changer un personnage ou omettre un accessoire clé dans l'image de storyboardSi pas de composition : h3d imagegen --detect / --set --stage 4 (l'utilisateur choisit Codex storyboard / Qwen crayon 9 cases / dessin à la main, écrit storyboard_engine) → h3d next donne la commande pour cet outil (Codex nécessite --model <modèle spécifié par l'utilisateur>), validate_storyboard.pyreferences/storyboard/shot-intent.md, references/storyboard/cinematic-director.md, references/storyboard/continuity-ledger.md ; pour les combats / techniques / effets, chargez également h3-combat-impact (voir section suivante)
5 PromptsÉcrire manuellement plan par plan le Layer 2 five_part_en (Camera / Motion / Performance / Light / Sound ; Motion et Performance doivent être détaillés ; chaque phrase doit correspondre à un résultat visible ou audible ; ne répétez pas l'apparence déjà présente dans l'image de référence ; écrivez la position, la ligne de regard, la posture de début et de fin, les accessoires clés) ; lisez le storyboard, la composition et l'état du plan précédent avant d'écrire ; le compilateur se contente d'assembler le format en 6 parties ; avant soumission, exécutez prompt_sketch_audit.py pour vérifier phrase par phrase la correspondance prompt ↔ image de composition (pour les segments fl2v, utilisez d'abord frame_pair_qa.py pour superposer les images)Écrire un programme pour générer les 5 sous-parties ; modifier les segments après compilation ; utiliser des mots méta (authored / approved) ou des phrases interdites pour s'en sortir ; ignorer un avertissement sans acquittementh3d bind (génère d'abord les images de référence et lie), h3d author, h3d compile --check, h3d catalog --checkreferences/prompt-authoring.md, references/h3/prompt-formats.md, references/tooling.md ; pour les combats / techniques spéciales, suivez aussi h3-combat-impact
6 VidéoSoumettre → collecter → QA → QA de mouvement (gèle de flux lumineux / figé, proposition automatique de liste de variations de vitesse) → QA de continuité de jonction (point de coupe réel + collage de jonction + candidat d'arrêt d'un côté, avertissement seulement) → --continuity-pairs paire par paire, répondre à la liste de 6 items de continuité (location / prop / screen side / costume / light / effect) → conclusion par segment → boîte de réceptionExécuter deux runners simultanément ; toucher au travail d'un autre ; soumettre une vidéo dérivante à la QA ; utiliser la durée prévue pour l'échantillonnage des jonctions (regardez d'abord le point de coupe réel trouvé par --continuity)h3d probe, h3d run --plan, h3d qa, h3d motion, h3d qa --continuity, h3d verdict, h3d inboxreferences/tooling.md §2.5–2.8 (jonction QA voir §2.8.1), references/remix-draft-loop.md (boucle remix tirage → révision → correction), references/speed-ramp.md, references/skill-guide.md « Étape 6 Génération »
7 Sous-titres et montagePost-production des variations de vitesse pour les segments d'action approuvés (métrage original inchangé, dialogues à vitesse normale) ; loudness ; timbre vocal de chaque personnage décidé une fois pour toutes ; projet de montage unique pour toute la série ; relecture à l'aveugle avant livraison (build_blind_review.py --stage 7, collage d'images échantillonnées, règles dans references/blind-review.md)Tous les dialogues, narrations et voix off sont générés nativement par H3 (pas de TTS externe) ; décider du timbre vocal à la place de l'utilisateur ; écraser le métrage original ; modifier la vitesse sur une zone de dialogueh3d ramp, h3d concat plan/build, h3d assemble ; objectif de montage (conseils uniquement) scripts/craft/edit_review.pyreferences/tooling.md §2.7, references/skill-guide.md « Étape 7 », references/edit/manju-editing-playbook.md (points de coupe / transitions / effets / sous-titres / cartes d'apparition / ducking de la musique / loudness), references/craft/murch-cut, references/craft/hamilton-action

L'approbation officielle des étapes se base sur review/project-state.json, en passant uniquement par build_stage_review.py --approve-stage (paroles originales de l'utilisateur) ou h3d approve --auto (étapes autorisées par l'utilisateur). Pipeline de génération vidéo : par défaut Ref2VA (FreeVideo, recadrage individuel) ; lorsque l'utilisateur passe au pack de personnages REMIX pour console, décision h3d decide video_backend remix, h3d bind lie au pack de personnages, h3d compile avec liaison remix produit les 3 colonnes REMIX (ancrage de style au début, <Picture N> / <Video N> numérotés indépendamment par pack), l'audit bifurque selon le backend (l'adaptateur de soumission n'est pas encore connecté, l'extrémité de soumission FreeVideo refusera d'envoyer les segments remix ; voir references/tooling.md §2.3.1c). La page de relecture de l'étape 5 exécute automatiquement refcheck / staging pour les segments ref2va et les liste comme rappel (les segments remix sont vérifiés dans l'audit) ; en manuel, exécutez h3d refcheck (les personnages / créatures / accessoires / foules mentionnés dans le prompt doivent tous avoir un pack ; bloquant pour remix, simple indication pour ref2va) et h3d staging (position de gauche à droite, ligne de regard, pas face caméra ; avertissement par défaut, bloquant seulement avec staging_gate strict), voir references/tooling.md §2.3.1d.

Approbation par segment à l'étape 5 : l'approbation de l'étape 5 enregistre l'empreinte de chaque segment. Si seuls certains segments sont modifiés après approbation → seuls les segments modifiés (incluant ajout / suppression) nécessitent une nouvelle relecture ; les segments non modifiés restent approuvés et peuvent être soumis normalement (h3d submit / h3d run ignore ou refuse automatiquement les segments à re-relire) ; les segments modifiés doivent toujours être relus manuellement : build_stage_review.py --project-dir . --stage 5 --segments X,Y produit la page de relecture → après validation par l'utilisateur, h3d approve --stage 5 --segments X,Y --user-note "<paroles originales de l'utilisateur>", pas de --auto. Les segments qui ont déjà une vidéo et qui ont été modifiés apparaissent comme stale (prompt_stale) dans h3d deps --status. Si l'instantané ancien ou les parties communes (enveloppe du fichier de segmentation, acquittement des segments non liés, étapes préparatoires) changent, une relecture complète reste nécessaire. Voir les détails dans references/tooling.md §2.6. Les brouillons purement textuels peuvent être livrés selon le périmètre défini, sans avancer jusqu'à la génération média : utilisez h3d decide delivery_scope script-only|storyboard-only|prompts-only|full --quote "<paroles originales de l'utilisateur>" pour fixer le point de livraison final (pas de décision = processus complet), h3d next signale done lorsqu'il atteint le point final ; avec no_image, l'étape 2 ne demande qu'une fiche de design textuelle. Attention : no_image ne désactive que l'étape 2 ; les étapes ≥ 4 exigent toujours des images de composition, le point final doit être avant l'étape 3 ou décidé autrement. La correspondance entre les livrables des 8 étapes et les pages HTML de relecture se trouve dans references/skill-guide.md « Processus en 8 étapes et points d'arrêt HTML ». Les modèles détaillés sont dans references/pipeline.md. Les pages HTML de relecture de chaque étape sont désormais des pages de débogage (pour lier l'instantané de relecture) ; ce qui est remis à l'utilisateur est la boîte de réception h3d inbox, dont les spécifications se trouvent dans references/review-page-spec.md.

Segments de combat / techniques / effets : charger simultanément h3-combat-impact

Lorsque le storyboard ou les prompts concernent des combats, des affrontements, des techniques, des techniques spéciales / ultimes, une élimination en un coup, des transformations, des explosions de sorts, des effets spéciaux, des images d'impact, des secousses d'écran (ou toute frappe de niveau L3 ou plus), chargez simultanément h3-combat-impact (ayase0307/h3-combat-impact), et utilisez les deux conjointement :

  • Étape 4 : selon son flux obligatoire, concevez les techniques des personnages, la chorégraphie de l'affrontement (échange / conséquence), la stratification des effets et les mouvements de caméra, et établissez la liste des points d'impact, chaque point sélectionnant un chemin d'image d'impact (P0–P3). Le lint de la couche réalisation (director_lint.py, warning) rappellera : avant un nouveau lieu, donnez d'abord un plan d'établissement ; les dialogues ne traversent pas l'axe à 180 degrés ; après un retournement / une mauvaise nouvelle, ajoutez un plan de réaction ; la correspondance du regard doit préciser l'objet regardé ; les jonctions entre segments utilisent un cut d'action ou une transition par masquage (référence au langage de caméra de 24frames.art, réécriture).
  • Étape 5 : le five_part_en des segments de combat suit ses fiches de décision – par défaut, les techniques ultimes sont écrites sous forme de segment « série d'images d'impact » (modèle F), sans utiliser les mots lents H3 comme near-freeze, hangs poised, like a meteor, for two frames ni le contrôle du nombre d'images. Le plan des images d'impact (code temporel, point de frappe, force, chemin, multiplicateur d'assemblage) est écrit dans les notes de storyboard / la description de livraison du segment (les segments n'ont actuellement pas de champ dédié).
  • Étape 7 : les segments de combat approuvés subissent des variations de vitesse selon le plan d'images d'impact (h3d ramp, ou impact_frame.py ramp de cette compétence) ou une composition (impact_frame.py composite) ; les zones de dialogue restent à vitesse normale.
  • Longueur du plan : les segments de série d'images d'impact, les plans de frappe courts peuvent être plus courts que le « chaque plan ≥ 2 s » de h3-video-prompting ; la règle de référence est celle de h3-combat-impact.

Les écrits d'accompagnement de ce dépôt : references/storyboard/xuanhuan-combat-contract.md (branche de combat, conditions de réussite de l'action, lieu, trois couches d'impact, vocabulaire de vitesse de caméra, chaîne de processus des techniques ultimes) et references/storyboard/vfx-design-and-review.md (fiche de conception d'effets, ligne de défense du visage, validation par l'image et reprise, méthode de correction locale). Ces deux documents sont distillés d'une compétence externe et n'ont pas été testés avec H3.

Ceci est une redirection ; cela ne modifie pas les contrôles d'accès de la compétence : validate_storyboard.py, h3d compile --check, h3d catalog --check doivent toujours être respectés.

Quatre vérifications déterministes (partie intégrante de la livraison)

Quanta de durée (17n+5, utilisant metadata.frames pour la soumission), graduation des preuves (étape 6 nécessite VERIFIED), registre de dépendances au niveau des segments (h3d deps), catalogue des échecs (h3d catalog --check / h3d ack). duration_drift, PARTIAL, travail en attente signifient tous « on ne peut pas continuer maintenant », traitement dans references/tooling.md §4.

Supervision (registre d'exigences, avant soumission et en parallèle de la relecture à l'aveugle)

h3d decide n'enregistre que les décisions formalisées ; les préférences exprimées oralement par l'utilisateur mais non formalisées seront oubliées, et aucune vérification ne demande « les paroles de l'utilisateur ont-elles été oubliées ? ». Le superviseur comble cette lacune : python scripts/build_requirements_ledger.py --root <projet> construit le registre d'exigences (les paroles originales de chaque décision dans decisions.json + les fiches de la boîte de réception inbox + les extraits manuels --quotes), --stage N / --all / --inputs construit un pack de vérification « seulement les matériaux, pas les conclusions », qu'un sous-agent frais vérifie point par point pour la couverture des livrables (modèle et interdictions dans references/supervision.md). Même statut que la relecture à l'aveugle : une exigence de processus, pas un contrôle d'accès ; ne modifie pas la machine d'état de h3d ; en cas d'« échec », traitez d'abord, puis soumettez. La première étape pour reprendre un projet existant est d'utiliser --all pour une vérification cumulative (en conjonction avec references/audit-inherited-project.md).

Ressources (index)

  • references/tooling.md — Toutes les commandes et vérifications de h3d (à lire avant d'exécuter une commande) ; §2.5 Décisions / conclusions par segment, §2.6 Boîte de réception et approbation automatique, §2.7 Runner / Probe / Doublage / Montage.
  • references/skill-guide.md — Texte complet du SKILL.md original : Principes fondamentaux 0–14, Structure du projet, Décisions concrètes de l'étape 6, Stratification du doublage à l'étape 7, Liste complète des scripts.
  • references/pipeline.md — Processus détaillé en 8 étapes, listes de questions, modèles ; Décisions de la couche audio à 3 niveaux et normes de loudness.
  • references/review-page-spec.md — Spécifications de la page de relecture : ce qui est remis à l'utilisateur est la boîte de réception des décisions (ordre de mise en page, champs obligatoires des fiches, interdictions, 6 blocs de la vue de lecture pour 8 étapes), les anciennes pages d'étape ne servent qu'au débogage.
  • references/blind-review.md — Relecture à l'aveugle (fresh eyes) : pack de matériel sans conclusion et processus (obligatoire pour les étapes 3 et 7 ; scripts/build_blind_review.py).
  • references/supervision.md — Supervision (registre d'exigences) : vérification point par point de la couverture des paroles de l'utilisateur (à exécuter avant soumission à chaque étape ; scripts/build_requirements_ledger.py).
  • references/document-standard.md — Format standard des documents d'étape : carte d'état + corps + historique de révision, à écrire via h3d doc, ne pas modifier manuellement ; « à vous de décider » sera automatiquement placé dans la boîte de réception.
  • references/audit-inherited-project.md — Reprise d'un projet existant (« tu reprends », « l'agent précédent a fait un mauvais travail », « regarde s'il y a des suggestions ») : auditer d'abord avant de continuer, seuil d'empreinte de génération mécanique, trois types de défauts du pipeline de dialogue, audit REMIX, ordre de reconstruction et pièges (re-bind, verbes de mouvement de caméra officiels, restauration d'instantané sketch, génération d'images de composition par un backend non supporté).
  • references/remix-draft-loop.md — Boucle de tirage remix (étape 6) : choix des 4 / 6 étapes de pika480, cinq symptômes de pack de référence l'emportant sur le prompt, trois choses à faire lors de la révision, trois faux positifs courants (faible saturation / contours / saut de tonalité), correction par lot + re-signature, ordre de collecte et de finalisation.
  • docs/skill-roadmap.html — Feuille de route dynamique pour humains (8 étapes, actions, livrables, qui décide, signaux d'arrêt) ; si le processus change, synchronisez ses données roadmap-data intégrées (tests/test_skill_roadmap.py fait la comptabilité).
  • references/adapt/ (Adaptation), references/storyboard/ (Storyboard de réalisation), references/consistency.md (Cohérence des actifs), references/styles.md (Ancrage du style), references/freevideo.md, references/model-profiles.md, references/minimax-h3.md et references/h3/ (Références détaillées H3, synchronisées avec h3-video-prompting en amont), references/prompt-playbook.md, references/h3/camera-moves-handbook.md (Manuel des mouvements de caméra en amont : 17 formes + 6 formes Loop Forge + temps d'arrêt Xianxia, annotations de tests Colab), references/craft/ (Objectifs de création, conseils uniquement, ne modifie pas les contrôles d'accès), references/edit/ (Manuel de montage de bande dessinée animée étape 7, enquête sur Concat / brouillons de montage).
  • Combats / techniques / effets / images d'impact : compétence externe h3-combat-impact (ayase0307/h3-combat-impact), voir section « Segments de combat / techniques / effets » ci-dessus.
  • references/revision-and-retry.md — Correction obligatoirement accompagnée d'une liste de modifications + conclusion des interactions, maximum 2 nouveaux tirages pour un même plan avant retour au diagnostic de couche, principe de comparaison d'acceptation.
  • references/storyboard/continuity-ledger.md — Compte des personnages, liste de vérification du storyboard, trois types d'orientation, table des positions, champ-contrechamp, état final de segment, utilisation des images de référence.
  • references/storyboard/spatial-consistency.md — Cohérence spatiale : planches mères de scène dessinées d'après un plan, couche d'allocation des murs (optionnel scripts/storyboard/wall_map.py), panneau de composition basé sur la planche mère, plans ne montrant que des êtres vivants liés à une référence de boutique (expérience Lao Yi 2026-10, preuve directionnelle) ; §6 Division du travail sur modèle blanc et trois niveaux de précision (Foyege, non testé avec H3).
  • Formats : references/schemas/ (decisions, verdicts). Les règles strictes pour l'agent se trouvent également dans AGENTS.md.

Skills associés