Codex PPT

Aperçu

Cette skill crée des decks PowerPoint basés sur des images à partir de matériels source. Chaque diapositive est une image générée complète en 16:9. Les images finales sont assemblées en .pptx avec scripts/assemble_ppt.py.

Utilisez ceci quand l'utilisateur veut une présentation visuellement unifiée et accepte des pages de diapositives en pleine image. Ne l'utilisez pas quand chaque zone de texte, graphique ou forme doit rester séparément modifiable.

Préférez l'outil intégré de génération/édition d'images. Utilisez scripts/image_gen.py uniquement quand le backend intégré est indisponible, manque une capacité requise, ou que l'utilisateur demande explicitement le mode API/CLI.

Contraintes dures

• Lisez les fichiers Reference Map pertinents avant chaque phase. Ce fichier est le contrat d'orchestration ; les règles détaillées se trouvent dans docs/ et les prompts de workers dans prompts/.
• Respectez les portes d'approbation. Ne créez pas le deck_spec.json final, speech.md, les jobs de prompts, les images de diapositives ou le .pptx avant les approbations dans docs/workflow-gates-and-progress.md.
• Après que l'utilisateur approuve la diapositive d'exemple et autorise la génération du deck complet, chaque job d'image de diapositive restant doit être envoyé à un subagent de diapositive dès que les subagents sont disponibles.
• L'agent principal possède l'orchestration, les jobs de prompts, l'enregistrement d'état, l'AQ, les notes de présentation et l'assemblage. Ne remplacez pas silencieusement les subagents de diapositive disponibles par une production séquentielle.
• Chaque image finale origin_image/slide_XX.png doit être générée par le backend d'image sélectionné : outil intégré de génération/édition d'images ou scripts/image_gen.py.
• Le dessin local, Pillow, SVG, les captures d'écran HTML/CSS/canvas, les mises en page python-pptx/PptxGenJS et les overlays manuels sont des modes de défaillance, pas des solutions de secours.
• Le backend d'image sélectionné doit rester fixe après la confirmation du backend. Ne laissez pas les subagents changer de backend pour des raisons de commodité.
• Après l'approbation de l'exemple, enregistrez comment l'exemple approuvé a été généré et passez cette méthode exacte à chaque subagent de diapositive.
• La dispatch de diapositive et l'état du résultat doivent être enregistrés avec les scripts fournis. Les messages de chat seuls ne font pas qu'une diapositive est dispatchée ou complète.
• Si un subagent requis, un backend d'image ou un chemin d'image requis est indisponible, arrêtez-vous et signalez un blocage avec l'id de diapositive et la preuve. Ne créez pas de remplacement de qualité inférieure.

Progression visible

Pour les decks non triviaux, gardez une checklist visible par l'utilisateur avec une étape active. La preuve de fin canonique se trouve dans docs/workflow-gates-and-progress.md.

Étapes visibles par défaut :

1. Préparer la source, le plan, le style et les décisions de backend.
2. Générer et approuver une diapositive d'exemple.
3. Préparer les jobs de diapositives et l'état de diapositive.
4. Dispatcher les subagents de diapositive.
5. Enregistrer les résultats de diapositive générés.
6. AQ, réparation, notes et assemblage PPT.

Ne marquez pas une étape comme complète à partir du chat seul ; utilisez des fichiers réels ou un état enregistré par script.

Workflow par défaut

1. Comprendre le contenu source.

   • Identifiez le sujet, le public, l'objectif, le nombre de pages, les contraintes de style/marque et les sections à inclure ou exclure.
   • Si aucun nombre de pages n'est spécifié, choisissez un nombre pratique. Les decks typiques comptent 8-12 diapositives.

2. Planifier le plan du deck.

   • Avant d'écrire ou de mettre à jour outline.md, lisez docs/workflow-gates-and-progress.md et docs/outline-style-and-sample.md.
   • Brouillon des rôles de diapositive et des images source requises. Demandez une confirmation, puis arrêtez-vous avant le style, le backend, l'exemple ou les artefacts en aval jusqu'à approbation.

3. Confirmer un style visuel unifié.

   • Avant d'offrir des options de style ou d'utiliser des fichiers de references/, lisez docs/outline-style-and-sample.md.
   • Offrez 2-3 directions de style concrètes, recommandez-en une, attendez la confirmation, puis maintenez une identité visuelle tout en variant les mises en page par rôle de page.

4. Confirmer le backend d'image.

   • Avant de générer une image de diapositive, lisez docs/backend-selection.md.
   • Vérifiez si un outil d'image intégré est appelable, déclarez ce que vous avez vérifié, nommez le backend, expliquez le statut de solution de secours et attendez la confirmation.
   • Si le fallback CLI/API est sélectionné, lisez docs/cli-api-fallback.md. Lisez docs/image-model-configuration.md uniquement après des erreurs de configuration ou des demandes de paramètres API explicites.

5. Générer une diapositive d'exemple pour approbation.

   • Avant de générer ou d'approuver la diapositive d'exemple, lisez docs/outline-style-and-sample.md.
   • Générez exactement une diapositive d'exemple représentative après que le plan, le style et le backend sont confirmés. Ne générez pas le deck complet jusqu'à approbation.
   • Après approbation, enregistrez sample_generation_method dans deck_spec.json pour que les jobs et les subagents héritent du même chemin.

6. Créer le répertoire du projet.

   • Avant d'initialiser des dossiers ou d'assembler des fichiers, lisez docs/project-assembly-and-reporting.md.
   • Si aucune destination n'est spécifiée, utilisez le répertoire de travail actuel ou le répertoire du fichier source.

7. Préparer les ressources fournies par l'utilisateur.

   • Avant d'utiliser des figures papier, des graphiques, des captures d'écran, des logos ou d'autres ressources requises, lisez docs/user-supplied-assets.md.
   • Traitez les ressources requises comme des entrées strictes et confirmez le mappage diapositive-ressource avant la génération.

8. Générer toutes les images de diapositive.

   • Avant la génération d'images du deck complet, lisez docs/slide-generation-and-subagents.md.
   • Créez des jobs par diapositive avec scripts/prepare_slide_prompts.py ou des fichiers prompts/slide_XX.json enregistrés.
   • Chaque image finale doit provenir du backend sélectionné et être enregistrée avec les scripts d'état fournis.

9. Dispatcher les subagents de diapositive.

   • Avant de dispatcher ou de remplacer les workers de diapositive, lisez docs/slide-generation-and-subagents.md et prompts/slide-worker.md.
   • Utilisez un subagent par job de diapositive restant dans la mesure du possible. Si les subagents requis ne peuvent pas être créés, arrêtez-vous et signalez un blocage à moins que l'utilisateur ne change le workflow.

10. Contrôle de qualité et réparation.

    • Avant l'AQ ou l'assemblage, lisez docs/project-assembly-and-reporting.md.
    • Inspectez chaque diapositive avant l'assemblage : texte, correspondance du plan, troncature, style, numéros de page indésirables, chevauchements et ressources requises.
    • Régénérez les défaillances graves avec un prompt plus serré. Utilisez l'édition de backend pour les problèmes localisés quand disponible.
    • Pour les commandes d'édition du fallback CLI/API, lisez docs/cli-api-fallback.md. Remplacez la diapositive finale uniquement après validation de la sortie éditée.

11. Écrire les notes de présentation et assembler le PPT.

    • Avant d'écrire speech.md ou d'exécuter l'assemblage, lisez docs/project-assembly-and-reporting.md.
    • Assurez-vous que outline.md reflète le plan du deck final confirmé. Utilisez les en-têtes speech.md qui correspondent à Slide N.
    • Avant l'assemblage, assurez-vous que slide_jobs.json affiche les diapositives générées comme recorded et les exemples approuvés comme accepted. Si une diapositive est pending, dispatched ou blocked, arrêtez-vous.

12. Signaler le résultat.

    • Utilisez la checklist de rapport final dans docs/project-assembly-and-reporting.md.
    • Incluez les chemins, le nombre de diapositives, le backend utilisé, l'état du résultat enregistré et toute limitation ou blocage.

13. Enregistrer les styles réutilisables si demandé.

    • Si vous êtes invité à enregistrer le style du deck actuel ou un style d'image/PDF/PPT/PPTX fourni, lisez docs/style-library.md.

Dispatch de subagent

Les subagents de diapositive sont obligatoires après approbation de l'exemple dès que le runtime peut les créer. L'agent principal prépare les jobs et enregistre l'état ; chaque worker traite exactement un job prompts/slide_XX.json et retourne uniquement le chemin de l'image sélectionnée, le backend et une note AQ.

Utilisez docs/slide-generation-and-subagents.md pour le dispatch, les commandes, l'enregistrement des résultats, les blocages et la provenance du backend. Utilisez prompts/slide-worker.md comme modèle de remise.

Les subagents ne doivent pas éditer outline.md, deck_spec.json, d'autres jobs de diapositive, origin_image/, speech.md ou le .pptx final. Le parent enregistre les sorties et assemble.

Critères d'acceptation

• La sortie est un .pptx valide.
• Chaque image de diapositive finale attendue existe sous origin_image/slide_XX.png.
• Chaque image de diapositive finale a été générée par le backend confirmé et enregistrée via record_slide_result.py, sauf un exemple approuvé marqué accepté par l'état d'exécution.
• outline.md reflète le plan du deck approuvé.
• speech.md existe quand les notes de présentation sont attendues, et l'assemblage écrit ces notes dans le PPT.
• slide_jobs.json et slide_run_state.json reflètent l'état final.
• Les images source requises sont visiblement représentées, ou un blocage est signalé.
• Si bloqué, la réponse finale identifie la phase, l'id de diapositive, le chemin de preuve et la raison inachevée ; ne déclarez pas le deck complet.

Carte de référence

• docs/workflow-gates-and-progress.md : portes d'approbation, progression, preuve d'achèvement.
• docs/backend-selection.md : règles de décision de backend et texte de confirmation.
• docs/outline-style-and-sample.md : règles de plan, style, exemple, exemples de prompts.
• docs/user-supplied-assets.md : traitement strict des ressources source requises.
• docs/slide-generation-and-subagents.md : jobs, dispatch, enregistrement des résultats, blocages, provenance.
• docs/cli-api-fallback.md : runtime de fallback, commandes de génération/édition, limites d'image, dépannage.
• docs/image-model-configuration.md : clé API, URL de base, modèle, .env ; à lire uniquement quand la configuration est nécessaire.
• docs/project-assembly-and-reporting.md : répertoire du projet, notes, assemblage, rapport final, principes de prompting.
• prompts/slide-worker.md : modèle de remise de subagent de diapositive.
• references/*.md : références de style visuel.

Documentation et mises à jour

Pour la source, la documentation, l'installation, la configuration et les exemples, consultez ningzimu/codex-ppt-skill.