视觉画布设计
canvas-design
基于设计原则创作静态视觉作品,用于海报与品牌图形。
presentation-docs【文档与办公】Transforme une source (note Obsidian, texte/Markdown brut, ou fichier de présentation PPTX/PDF/DOCX/ODT/ODP) en un fichier Markdown propre respectant la convention "mode présentation" de Docs (La Suite) — une diapo par diviseur `---`. Produit uniquement le fichier .md (et ses assets) prêt à coller/importer dans Docs ; ne publie rien. Utiliser quand l…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
---. Produit uniquement le fichier .md (et ses assets) prêt à coller/importer dans Docs ; ne publie rien. Utiliser quand l'utilisateur dit "/presentation-docs", "transforme cette note en présentation Docs", "convertis X en présentation Docs", "mets ce PPTX/PDF/DOCX/ODT en diapos Docs", "formate ce texte en présentation Docs".Transforme une source en un fichier Markdown propre, formaté selon la convention du mode présentation de Docs (La Suite). La sortie est un .md prêt à coller ou importer dans Docs. La skill ne publie rien : aucun appel réseau, aucune publication — elle produit le fichier et ses assets, point.
Le mode présentation de Docs (doc officielle) repose sur une règle unique : chaque diviseur --- crée une nouvelle diapo. C'est un mode lecture. Il supporte alignement, couleurs, types de blocs, colonnes et médias (images/vidéos lisibles en présentant).
Read).Un seul livrable : un fichier .md dans le vault, respectant la convention diapos ci-dessous, avec ses médias dans un dossier d'assets à côté. À la fin, montrer le résultat et rappeler le nombre de diapos (= nombre de --- + 1). L'utilisateur l'utilise ensuite dans Docs (copier-coller le contenu, ou importer le .md) — ce n'est pas du ressort de la skill.
--- seul sur sa ligne, avec une ligne vide avant et après. Sans ces lignes vides, --- collé à une ligne de texte au-dessus est interprété comme un soulignement de titre (setext H2), pas comme un diviseur — la diapo ne se crée pas.# pour la diapo d'accroche, ## pour les diapos suivantes — les modèles officiels de l'équipe Docs utilisent un # Titre (souvent avec emoji) comme 1re diapo. Donc # = diapo de titre/accroche, ## = titres des diapos de contenu, ### = sous-titres. (Seul cas où éviter le # H1 : quand un titre est déjà poussé séparément par une API de création de document, pour ne pas doublonner.)##) + contenu concis (puces, lignes courtes). Éviter les pavés : un contenu plus haut que l'écran reste accessible au scroll mais nuit à la lisibilité en présentation. → bloc image/vidéo. Liens, gras, italique, listes, citations >, tableaux et blocs de code sont conservés..md livre la structure (titres, texte, listes, diapos, images, liens) ; le fignolage visuel se fait à la main dans Docs après import. Le dire à l'utilisateur, ne pas le simuler.poppler (pdftotext, pdfimages, pdftoppm, pdfinfo — brew install poppler).python-pptx (pip install python-pptx), ou LiteParse.npm i -g @llamaindex/liteparse, plus LibreOffice pour les formats Office : brew install --cask libreoffice sur macOS, apt-get install libreoffice sur Ubuntu/Debian), utilisable directement en lit parse ou via la skill rag-parse si elle est installée.magick/convert (ImageMagick)..md) → Read.pdftotext/pdfimages/pdftoppm ; pour un PPTX, parsing python-pptx ; pour un DOCX/ODT/ODP, lit parse {fichier} (LiteParse ; sortie texte par défaut, --format json pour la structure) — les médias sont récupérés à part, depuis l'archive du document (word/media/ pour un DOCX, qui est un zip).Distinction de fidélité selon la source :
Source PDF / PPTX / présentation existante → respecter à l'identique la mise en forme et le découpage de la source. Une diapo source = une diapo Docs, dans le même ordre, mêmes titres/puces/médias. Ne pas synthétiser, reformuler, fusionner ni réordonner : on translittère le deck en convention Docs (un --- entre chaque diapo), transformation syntaxique seulement.
Source note / texte / Markdown brut → construire un deck en découpant aux frontières logiques, 1 idée par diapo :
---) : titre (# recommandé, à la manière des modèles Docs), sous-titre, date. Garder court.---## Titre court + 2 à 5 puces concises, ou une citation >, ou un média, ou un tableau.Si la source est déjà du Markdown, réutiliser sa structure (titres existants → titres de diapo) plutôt que de tout réécrire ; n'ajouter que les --- et les ajustements de convention.
Veiller pour chaque --- à la ligne vide avant et après.
Objectif : un deck texte éditable + images, jamais un empilement de pages aplaties en images. Le texte d'une diapo (titres, puces, libellés) reste du texte markdown — éditable, cherchable, accessible. On n'embarque en image que ce que le markdown ne peut pas reproduire (photos, captures, schémas).
1. Récupérer le texte de chaque diapo.
pdftotext -layout -f {page} -l {page} {fichier.pdf} - (la couche texte d'un export de slides est en général propre, emojis compris).python-pptx : pour chaque shape de slide.shapes, vérifier shape.has_text_frame avant de lire shape.text_frame — toutes les formes n'en ont pas, sinon AttributeError ; ou dézipper le .pptx et lire ppt/slides/slideN.xml). Avantage du PPTX : texte et images sont des éléments distincts par diapo.2. Récupérer les médias de contenu.
pdfimages -all -p {fichier.pdf} {prefixe} (PDF, pdfimages -list pour l'inventaire) ou ppt/media/ du PPTX. Écarter le bruit de gabarit (fonds, logos répétés, emojis décoratifs).3. Schémas vectoriels non reproductibles (diagrammes, pyramides, infographies, flux) → ni texte ni bitmap extractible, et le markdown ne sait pas les recréer. Pour ceux-là seulement, rendre la page concernée en image et l'embarquer en plus du texte : pdftoppm -jpeg -r 130 -f {page} -l {page} {fichier.pdf} {prefixe}. Résultat par diapo : ## titre + texte markdown + image du schéma.
Décision par diapo : titres/puces/colonnes de texte → tout en markdown (pas d'image) ; photo/capture/schéma → texte markdown + l'image. Conserver les liens en texte ([libellé](url)). Récupérer les URL écrites en clair depuis le texte extrait (pdftotext {fichier.pdf} - | grep -oE 'https?://[^ )<>"]+' | sort -u) ; pour un lien dont le libellé diffère de la cible (annotation hypertexte), lire les annotations avec un parser PDF — ex. pypdf : pour chaque page, page.annotations → /A → /URI (ne pas compter sur strings, les flux PDF étant souvent compressés).
Enregistrer les médias dans un dossier d'assets à côté du .md (ex : assets/{nom-deck}/slide-04.jpg) et les référencer en markdown relatif : .
Builds d'animation PowerPoint : un même slide exporté en plusieurs pages quasi identiques produit des doublons. Replier chaque série sur son état final et le signaler à l'utilisateur (ne pas supprimer silencieusement).
Proposer un emplacement cohérent dans le vault :
- présentation.md (ex : ALLiaNCE/Strat 2026.md → ALLiaNCE/Strat 2026 - présentation.md).Écrire avec Write, puis montrer le résultat (nombre de diapos) et indiquer où il se trouve. Si des médias locaux sont référencés, signaler qu'à l'import dans Docs ils peuvent devoir être réinsérés à la main (un import markdown ne transporte pas les binaires).
.md et son dossier d'assets — et rien d'autre : la skill ne publie pas et ne touche à aucun service Docs. Les médias extraits (étape 2) sont écrits à côté du .md et référencés en chemins relatifs ; ne jamais produire un lien vers un fichier qui n'a pas été écrit.# pour la diapo d'accroche (comme les modèles officiels de l'équipe Docs), ## pour les titres des diapos suivantes, ### pour les sous-titres.Source (texte/Markdown brut) :
## Bilan T1
- 3 serveurs MCP en prod
- 12 administrations accompagnées
## Cap T2
- Cartographie des données mobilisables
- Guide MCP pour les administrations
Sortie .md (--- = nouvelle diapo, lignes vides autour, # pour la diapo d'accroche) :
# Socle IA interministériel
Point d'étape · juin 2026
---
## Bilan T1
- 3 serveurs MCP en production
- 12 administrations accompagnées
---
## Cap T2
- Cartographie des données mobilisables pour l'IA
- Guide MCP à destination des administrations
→ 3 diapos (titre + bilan + cap).