Ekran Görüntüsünden Kullanım Kılavuzu / Capture d'écran → Manuel d'utilisation
Entrée : captures d'écran + un exemple de manuel d'utilisation. Sortie : un nouveau manuel qui imite le style et la structure de l'exemple, mais dont le contenu provient des captures d'écran.
Input : screenshots + one example manual. Output : a new manual that copies the example's style and structure while its content comes from the images.
Ce fichier est bilingue : les instructions sont en turc, les règles critiques sont également répétées en anglais. La langue du manuel produit est celle demandée par l'utilisateur ; si non spécifiée, la langue du manuel de référence est utilisée.
1. Entrées / Inputs
| Entrée | Obligatoire | Remarques |
|---|---|---|
| Captures d'écran | ✅ | Dossier ou liste de fichiers. Indice de tri : nom de fichier, horodatage, EXIF. |
| Exemple de manuel d'utilisation | ✅ | .pdf, .docx, .md, .txt, .html. Source du style et de la structure. |
| Nom du produit / processus | ➖ | S'il manque, déduire des écrans et faire valider par l'utilisateur. |
| Public cible et langue | ➖ | S'il manque, déduire du manuel de référence. |
| Format de sortie | ➖ | Par défaut : Markdown (+ .docx / .html imprimable si demandé). |
| Informations de marque | ➖ | Société, numéro de document, révision — si non fournies, laisser des espaces réservés. |
Essayer de déduire les informations manquantes avant de les demander. Ne poser que des questions pour ce qui ne peut pas être déduit des écrans et du manuel de référence ; au maximum 3 questions.
Infer before you ask. Ask at most 3 questions, only for what the images and the reference manual cannot answer.
Priorité des informations / Source priority
En cas de contradiction, décider selon cet ordre — le plus haut l'emporte :
- Information explicitement donnée par l'utilisateur
- Captures d'écran
- Photos de la machine/produit
- Informations du modèle du manuel de référence
- Connaissances techniques générales (uniquement pour éviter de laisser un espace réservé ; ce n'est pas considéré comme une invention, mais demander confirmation)
On conflict: user's explicit statements > screenshots > photos > reference template > general knowledge.
Deux modes / Two modes
| Mode | Quand | Ce qui est préservé |
|---|---|---|
| Mode style | La référence est un simple .md/.txt | Disposition des titres, mode des étapes, format des avertissements |
| Mode modèle | La référence est un PDF/DOCX d'entreprise (page de garde, table des matières, en-tête, numéro de document) | Ordre des sections, numérotation, identité du document, format des tableaux/avertissements sont conservés à l'identique ; le contenu est rempli avec le produit réel |
En mode modèle, ne pas copier le PDF. Prendre le modèle comme squelette, générer le contenu à partir des captures d'écran. Si une section existe déjà, la conserver et l'enrichir ; si elle manque, ajouter une nouvelle section conforme à la conception du document.
In template mode: keep the section order, numbering and document identity; never copy the PDF's sentences — fill it with what the screenshots show.
2. Sorties / Outputs
<cikti-klasoru>/
├── kilavuz.md # Livraison principale — nouveau manuel d'utilisation
├── images/ # Captures d'écran copiées/renommées
├── kilavuz.html # (optionnel) Version imprimable depuis le navigateur
├── kilavuz.docx # (optionnel) Version Word
└── 00-analiz.md # Notes de travail : inventaire des écrans + contrat de style
00-analiz.md n'est pas un document livré, mais une preuve vérifiable : elle montre quel écran va à quelle étape et quelle décision de style a été prise à partir de la référence. Toujours la produire.
3. Correspondance des outils / Tool mapping
Le skill n'est pas écrit pour un outil spécifique. Utiliser l'équivalent disponible :
| Besoin | Claude Code | Cursor | Codex / DeepSeek Harness | Autre |
|---|---|---|---|---|
| Voir l'image | Read (visuel) | Read | read_image | Ajouter l'image au message |
| Écrire un fichier | Write / Edit | Write | write / edit | Éditeur |
| Exécuter un script | Bash | Terminal | pwsh / bash | Terminal |
Lire .docx / .pdf | Bash + python | Terminal | pwsh + python | python |
Critique : Voir réellement les images. Ne jamais inventer le contenu à partir du nom de fichier ou d'une interface connue.
Always actually view the images. Never infer screen content from file names.
4. Flux de travail / Workflow
Suivre la progression avec cette liste :
- [ ] 1. Collecter et valider les entrées
- [ ] 2. Extraire le contrat de style de la référence
- [ ] 3. Lire chaque capture d'écran individuellement
- [ ] 4. Ordonner les écrans en flux, marquer les lacunes
- [ ] 5. Rédiger le manuel
- [ ] 6. Porte QA — `check_manual.py`
- [ ] 7. Livraison (+ docx/html optionnel)
Étape 1 — Collecter et valider les entrées / Intake & validate
- Lister les fichiers de captures d'écran ; rapporter le nombre et les formats.
- Lire le manuel de référence (
.docx→ python-docx,.pdf→ pypdf/pdftotext, texte brut → directement). - Si un fichier est illisible ou corrompu, le dire immédiatement ; ne pas l'ignorer silencieusement.
- Déterminer le dossier de sortie et créer le sous-dossier
images/. - Copier les visuels : copier chaque écran utilisé dans le manuel dans
images/. Conserver les noms (ex.01-giris.png→images/01-giris.png) ; si vous les renommez, le script QA les associera avec le hash de contenu, mais il est plus sûr de conserver le nom pour ne pas perdre l'ordre. Ne pas écrire le chemin relatif vers le dossier d'origine.
List every screenshot, read the reference manual, report unreadable files, create the output folder, then COPY each screenshot into images/ keeping its file name. Never link back to the original screenshots folder.
Étape 2 — Extraire le contrat de style de la référence / Extract the style contract
D'abord mesurer, puis interpréter :
python <skill-dizini>/scripts/read_reference.py <ornek-kilavuz> \
--out 00-analiz-referans.md --json 00-analiz-referans.json
Ce script extrait un profil mesuré du PDF/DOCX/MD : fiche d'identité du document, hiérarchie des titres, profondeur de numérotation, en-tête/pied de page répété sur chaque page (numéro de document, révision), modèle de légende de figure/tableau, police, taille et couleurs. Transférer la sortie dans le tableau reference/style-contract.md.
read_reference.py nécessite PyMuPDF pour le PDF et python-docx pour le DOCX ; si l'un ou l'autre manque, demander à l'utilisateur une version .md/.txt (le script écrit la commande d'installation).
Vous ne copierez pas le contenu du manuel de référence, vous copierez son format. Remplir les champs du fichier reference/style-contract.md et les écrire dans 00-analiz.md :
- Hiérarchie des titres et numérotation (
1.,1.1,Adım 1,Bölüm) - Mode de la phrase d'étape (impératif, « cliquez », « cliquer ») et longueur
- Placement de la capture d'écran : avant ou après l'étape, légende présente ou non, numérotée ou non
- Types de boîtes d'avertissement/conseil (Remarque, Avertissement, Conseil, Attention) et format de marquage
- Utilisation des tableaux, listes, gras
- Sections préliminaires : page de garde, version, date, table des matières
- Sections finales : FAQ, dépannage, glossaire
- Ton : formel / décontracté, « vous » / « tu »
- Glossaire de termes (nommage utilisé par la référence)
- Identité du document : numéro de document, révision, date, bloc société (en mode modèle, conservé à l'identique ; si les valeurs sont inconnues, laisser un espace réservé)
- Profondeur de numérotation : si la référence utilise 4 niveaux comme
6.5.1.1, le nouveau manuel utilise la même profondeur
Extract form, not content: hierarchy, numbering, step voice, image placement, callout types, tables, front/back matter, tone, terminology, document identity.
Étape 3 — Lire chaque capture d'écran individuellement / Read every screenshot
Pour chaque visuel, enregistrer selon le schéma reference/screenshot-analysis.md :
| Champ | Exemple |
|---|---|
| Fichier | 03-ayarlar.png |
| Nom de l'écran/page | Paramètres |
| Composants principaux visibles | menu de gauche, bouton enregistrer, liste déroulante de langue |
| Action effectuée | Sélectionner « Turc » dans la liste déroulante « Langue » |
| État | avant / après / étape intermédiaire |
| Accentuation / flèche / cadre | cadre rouge sur le bouton « Enregistrer » |
| Illisible / incertain | nom de champ flou → [?] |
| Numéro d'étape (brouillon) | 4 |
Interdiction d'inventer : Ne pas écrire de nom de bouton, de chemin de menu, d'étiquette de champ ou de message d'erreur qui n'apparaît pas à l'écran. Si vous n'êtes pas sûr, mettre [?] et l'ajouter à la section « Questions ouvertes ».
Bloc de description par écran pour les manuels d'interface/HMI. Pour chaque capture d'écran, écrire les cinq parties suivantes (structure attendue dans la documentation opérateur) :
### <Nom de l'écran>
**Objectif.** À quoi sert cet écran — 1 à 2 phrases.
**Informations affichées.** Valeurs visibles, indicateurs, couleurs d'état.
**Fonctions des boutons.**
| Bouton | Fonction | Description |
|---|---|---|
**Utilisation par l'opérateur.** Procédure étape par étape.
**Attention.** S'il y a un risque de mauvaise utilisation, un avertissement ; sinon, ne pas écrire cette ligne.
Donner la légende selon le modèle de la référence (ex. Şekil 12 – Page des moteurs CA). Décrire les éléments importants du visuel en les numérotant (1 – START, 2 – STOP) mais sans réduire la lisibilité ou écrire par-dessus.
For UI/HMI manuals, describe every screen with the five-part block: purpose, displayed values, button table, operator steps, cautions. Number callouts only when it improves clarity.
Never invent a button label, menu path, field name or message that is not visible in the image. Mark uncertainty with [?] and list it under Open questions.
Étape 4 — Ordonner les écrans en flux / Order into a flow
- Utiliser les indices de tri : numéro de nom de fichier → horodatage → état d'écran (avant/après) → flux logique.
- Grouper les écrans en sections (ex. Installation, Premiers réglages, Utilisation quotidienne).
- Marquer les lacunes : « Il manque un écran intermédiaire en passant de l'étape 1 à l'étape 3 », par exemple. Ne pas inventer l'étape manquante ; demander à l'utilisateur ou l'écrire dans la section « Questions ouvertes ».
- Lier chaque écran à exactement une étape. Si le même écran illustre plusieurs étapes, utiliser le visuel dans une seule étape et faire référence à l'autre étape dans le texte.
Order with file names → timestamps → before/after state. Group into sections. Flag gaps instead of inventing steps. One screenshot maps to exactly one step.
Étape 5 — Rédiger le manuel / Draft the manual
Prendre le squelette templates/manual-template.md, le remplir avec le contrat de style de l'étape 2. Règles :
- Chaque étape = une seule action + une seule capture d'écran montrant cette action.
- Texte de l'étape court : 1 à 3 phrases. Si une justification/théorie est nécessaire, la déplacer dans une note « Pourquoi ? » séparée.
- Chemin du visuel relatif et portable :
. Adapter la légende au format de la référence. - Conserver les titres et la numérotation dans le même schéma que la référence ; prendre le contenu de l'écran.
- Utiliser les termes du glossaire de la référence à l'identique — ne pas inventer de synonymes.
- Ajouter les sections préliminaires (titre, version, public cible) et finales (FAQ, dépannage, glossaire) si elles existent dans la référence ; sinon, ne pas les ajouter.
- Toute information non vérifiable à partir des écrans est marquée : incertitude courte avec
[?], information manquante avec un espace réservé explicite du dictionnairereference/placeholders.md([À REMPLIR PAR LE FABRICANT],[À VALIDER], …). - Ajouter une section « Questions Ouvertes / Open Questions » à la fin du manuel (si vide, écrire « Aucune. »). Cette section est une annexe QA, ne fait pas partie du style de la référence ; l'utilisateur peut la supprimer avant publication. Le mentionner dans le message de livraison.
- Séparer les informations pour l'opérateur et le service technique. La programmation PLC, les noms de tags, les paramètres de servo, les algorithmes logiciels et les détails de communication n'entrent pas dans la section principale destinée à l'opérateur ; si nécessaire, ouvrir une section séparée sous le titre « Personnel Technique / de Maintenance ».
One step = one action + one screenshot. Relative image paths. Mirror the reference's numbering and terminology. Mark unverifiable claims with [?].
Étape 6 — Porte QA / QA gate
Exécuter les commandes depuis la racine du projet et donner le chemin du script par rapport au dossier du skill — le script et le manuel sont dans des dossiers différents :
python <skill-dizini>/scripts/check_manual.py <cikti>/kilavuz.md \
--screenshots <ekran-klasoru> --reference <ornek-kilavuz.md>
Le script vérifie : les chemins des visuels existent-ils, chaque écran est-il utilisé au moins une fois (nom ou hash de contenu), la numérotation des titres/sections est-elle continue, la numérotation des étapes est-elle cohérente (globalement ou par section), y a-t-il des résidus TODO/XXX/<espace réservé>, les [?] sont-ils dans la section « Questions Ouvertes », combien d'espaces réservés de champ attendent d'être remplis.
En cas d'erreur, corriger et réexécuter. Ne pas livrer sans avoir passé le test.
Ne pas donner de .docx/.pdf comme --reference ; pour la comparaison de style, d'abord extraire le profil avec read_reference.py (le script le signalera comme avertissement).
Run the checker; fix and re-run until it passes. Do not deliver a failing manual.
Étape 7 — Livrer / Deliver
kilavuz.md+images/+00-analiz.mdprêts.- Si demandé :
python <skill-dizini>/scripts/convert.py <cikti>/kilavuz.md --format docx,html(--outsi autre dossier, les visuels y sont également copiés ;--langdétermine la langue du HTML).- Pour
.docx, python-docx est nécessaire ; sinon, le script imprime la commande d'installation. .htmlpeut toujours être produit et imprimé depuis le navigateur avec Ctrl+P → PDF.
- Pour
- En mode modèle, mettre le numéro de document/révision dans l'en-tête du
.docxet le numéro de page dans le pied de page (voirconvert.py --doc-no,--header,--footer). - Dans le message de livraison : nombre d'écrans, nombre d'étapes, nombre de sections, nombre de
[?], nombre d'espaces réservés de champ et, s'il y a des écrans manquants, leur liste.
5. Règles strictes / Hard rules
- Ne pas écrire sans voir. Voir réellement chaque capture d'écran ; ne pas déduire le contenu du nom de fichier.
- Aucune invention. Ne pas écrire d'étiquette, de menu, de message, de version ou de nombre qui n'est pas à l'écran.
- Format de la référence, contenu de l'écran. Ne pas copier les phrases du manuel de référence.
- L'incertitude doit être visible.
[?]+ section « Questions Ouvertes » ; pas de supposition silencieuse. - Un écran = une étape. Aucun visuel ne doit rester inutilisé.
- Chemins portables. Chemin relatif
images/...; ne pas écrire de chemin Windows absolu. - Langue de l'utilisateur. Le manuel est dans la langue demandée ; pas dans la langue des instructions du skill.
- Signaler les entrées manquantes. Si un fichier est illisible ou qu'un écran intermédiaire manque, le dire.
- Si vous ne voyez pas, arrêtez. Si vous n'avez pas la capacité de lire les visuels (pas d'outil ou modèle ne supporte pas le visuel), ne commencez pas à rédiger le manuel. Dites à l'utilisateur que vous ne pouvez pas lire les visuels dans cette session et demandez une session avec capacité visuelle. Il est interdit de produire du contenu basé sur des suppositions à partir des noms de fichiers.
1 Never write without viewing. 2 Never invent UI. 3 Form from reference, content from images. 4 Surface uncertainty with [?] or an explicit placeholder. 5 One screenshot = one step, none unused. 6 Relative image paths. 7 Manual language = requested language. 8 Report missing or unreadable input immediately. 9 Stop if you cannot view the images — never guess from filenames.