Pour créer un SKILL, il suffit de créer un fichier markdown (.md) en lui donnant un nom facilement identifiable commençant par « skill-« .

Voici un cas simple : la création d’un SKILL dédié à une documentation orientée utilisateur : skill-documentation-utilisateur.md

L’objectif de ce SKILL étant de fournir à BOB les informations nécessaires pour produire un documentation utilisateur, non technique, affichant les enchainements écran et détaillant les diverses options et touches de fonctions utilisables.

Une fois le fichier .md créé, il faut, ensuite, saisir dans ce fichier, de préférence de manière ordonnée, la liste des informations à fournir à l’IA.

Il est aussi possible de demander de l’aide à BOB pour créer ce skill avec, par exemple, le prompt suivant :
Génère moi un SKILL appelé skill-documentation-utilisateur.md, définissant une documentation de chaine de traitement interactive sur IBMi. La documentation ne doit pas être technique mais fonctionnelle, orientée utilisateur. Elle devra comporter des schémas au format mermaid représentant les enchainements d’écran. Chaque option et touche de fonction utilisée devra être décrite. Chaque écran devra faire l’objet d’une représentation graphique au format mermaid. Les données techniques telles que les noms des programmes et des DSPF ne doivent pas apparaître dans la documentation.

Le document produit par BOB devra être relu et revu (complété avec des informations supplémentaires, ou épurée de paragraphes jugés non utiles par exemple)…

Le mieux étant d’utiliser le SKILL et de le corriger en fonction des résultats obtenus, puis de le rejouer pour le vérifier de nouveau…
Ceci afin d’obtenir le SKILL idéal, produisant un résultat répondant totalement aux attentes initiales.  

Exemple :
Fichier : skill-documentation-utilisateur.md

# SKILL : Documentation Utilisateur pour Chaînes de Traitement IBMi

## Objectif du SKILL

Ce SKILL guide Bob pour créer une documentation utilisateur complète et fiable d’une chaîne de traitement sur IBMi.
La documentation doit être orientée utilisateur final, sans détails techniques d’implémentation, et
**100% basée sur l’analyse des sources réels** (programmes RPGLE et fichiers DSPF).
Le document généré doit être un .md généré dans : « C:\BOB\Résultats BOB »

## Principes Fondamentaux

### 1. Fiabilité Absolue

– **TOUTE information DOIT provenir de l’analyse des sources réels**
– **INTERDICTION FORMELLE d’inventer ou supposer des informations**
– Analyser les fichiers DSPF pour les touches de fonction réelles
– Analyser les programmes RPGLE pour les options réelles du subfile
– Vérifier chaque détail dans le code source avant de le documenter

### 2. Orientation Utilisateur

– Utiliser un vocabulaire métier, pas technique
– Expliquer « ce que fait » l’application, pas « comment elle le fait »
– Éviter les termes techniques (subfile, indicateurs, RPGLE, etc.)
– Se concentrer sur les actions utilisateur et leurs résultats

### 3. Exhaustivité

– Documenter TOUS les écrans de la chaîne
– Documenter TOUTES les options disponibles
– Documenter TOUTES les touches de fonction actives
– Inclure les messages d’avertissement et de confirmation

## Structure Obligatoire de la Documentation

### 1. Page de Garde

« `markdown

# Guide Utilisateur : [Nom de l’Application]

**Version** : [Version]  
**Date** : [Date]  
**Application** : [Code Application]

« `

### 2. Vue d’Ensemble

« `markdown

## Vue d’Ensemble

### Objectif de l’Application
[Description en 2-3 phrases de la fonctionnalité principale]

### Accès à l’Application

– **Programme principal** : [Code du programme d’entrée]
– **Menu** : [Chemin d’accès depuis le menu principal]

« `

### 3. Navigation entre Écrans

« `markdown

## Navigation entre les Écrans

« `mermaid

graph TD

    A[Menu Principal] –>|Option 1| B[Écran 1]
    A –>|Option 2| C[Écran 2]
    B –>|F12| A
    C –>|F12| A

« `

« `

**Règles pour le diagramme Mermaid :**
– Utiliser des noms d’écrans compréhensibles (pas les codes techniques)
– Indiquer les options/touches qui permettent la navigation
– Montrer les retours arrière (F12, F3)
– Garder le diagramme simple et lisible

### 4. Description Détaillée des Écrans

Pour **CHAQUE écran**, suivre cette structure :

« `markdown

## [Nom de l’Écran]

### Description
[Expliquer à quoi sert cet écran en 2-3 phrases]

### Représentation de l’Écran
[Inclure une représentation ASCII de l’écran en utilisant la police CONSOLAS]

**Format de représentation** :

« `
Utiliser des blocs de code avec la police CONSOLAS pour les représentations d’écran.

RÈGLES STRICTES :
1. Les représentations écran ne doivent pas afficher de bordure encadran les écrans
2. La largeur d’une ligne doit être SOIT 80 colonnes, SOIT 132 colonnes
3. Compléter avec des espaces si nécessaire pour atteindre la largeur exacte
4. Utiliser impérativement la police CONSOLAS pour les représentations d’écran

VÉRIFICATION :

« `

### Zones de Saisie

| Zone | Description | Format | Obligatoire |
|——|————-|——–|————-|
| [Nom] | [Description] | [Type] | Oui/Non |

### Options Disponibles

| Option | Description | Action |
|——–|————-|——–|
| [Code] | [Nom] | [Ce qui se passe] |

**IMPORTANT** : Vérifier dans le programme RPGLE (section TRAITEMENT ou SELECT) les options réellement traitées.

### Touches de Fonction

| Touche | Description |
|——–|————-|
| F3 | Sortie de l’application |
| F12 | Retour à l’écran précédent |

**IMPORTANT** : Vérifier dans le fichier DSPF les touches réellement définies (CF03, CF06, CF08, etc.).

« `

### 5. Glossaire

« `markdown

## Glossaire

| Terme | Définition |
|——-|————|
| [Terme métier] | [Explication simple] |

« `

## Méthodologie d’Analyse des Sources

### Étape 1 : Identifier TOUS les Fichiers Sources de la Chaîne

« `markdown
**IMPORTANT** : Analyser TOUS les programmes appelés, y compris ceux appelés par des programmes appelés (analyse récursive).

Pour identifier tous les programmes :
1. Lire le programme principal (ex: SCNFLDP00.RPGLE)
2. Identifier tous les programmes appelés dans les prototypes (Dcl-pr … extpgm)
3. Pour CHAQUE programme identifié, répéter l’étape 2
4. Continuer jusqu’à avoir identifié tous les programmes de la chaîne

Pour chaque programme identifié :
– Le programme RPGLE (ex: SCNFLDP00.RPGLE)
– Le fichier DSPF correspondant (ex: SCNFLDD00.DSPF)

Exemple de chaîne :
– SCNFLDP00 appelle SCNFLDP01, SCNFLDP03, etc.
– SCNFLDP01 appelle SCNFLDP10, SCNFLDP11, SCNFLDP12
– SCNFLDP03 appelle SCNFLDP30, SCNFLDP31, SCNFLDP32
– Tous ces programmes doivent être documentés

« `

### Étape 2 : Analyser le Fichier DSPF

« `markdown

Dans le DSPF, extraire :
1. **Touches de fonction** : Chercher les lignes CF03, CF06, CF08, CF12, etc.
 Exemple : CF03(03) signifie que F3 est active
2. **Zones de saisie** : Chercher les champs avec attribut B (Both = saisie)
   Exemple : C_CHOIX 2 0B signifie zone de saisie numérique   
3. **Libellés d’écran** : Les textes entre quotes définissent les titres et labels
4. **Structure du subfile** : Si présent, identifier les colonnes affichées

« `

### Étape 3 : Analyser le Programme RPGLE

« `markdown

Dans le RPGLE, extraire :
1. **Options du menu** : Dans la section SELECT/WHEN
 Exemple : WHEN E_CHOIX = 1; indique que l’option 1 existe
2. **Actions des options** : Le code appelé après chaque WHEN
 Exemple : GestionTextes(l_codeRetour); indique l’action de l’option
3. **Options du subfile** : Dans la section de traitement du subfile
 Exemple : WHEN S_OPTION = ‘2’; indique que l’option 2 existe
4. **Validations** : Les contrôles effectués sur les saisies
« `

### Étape 4 : Vérification Croisée

« `markdown
– Vérifier que chaque option documentée existe dans le code
– Vérifier que chaque touche documentée est définie dans le DSPF
– Vérifier la cohérence entre DSPF et RPGLE

« `

## Éléments à EXCLURE de la Documentation

**Ne PAS inclure** :
– Noms techniques des programmes (sauf en référence)
– Détails d’implémentation (SQL, RPG, indicateurs)
– Noms de tables ou fichiers techniques
– Structures de données internes
– Codes d’erreur système
– Sections « Prérequis techniques »
– Sections « FAQ » (sauf si demandé explicitement)
– Sections « Support technique » (sauf si demandé explicitement)
– Sections « Messages et alertes » (sauf si demandé explicitement)
– Sections « Cas d’usage pratiques » (sauf si demandé explicitement)

## Checklist de Qualité

Avant de finaliser la documentation, vérifier :
– [ ] Toutes les informations proviennent des sources analysés
– [ ] Aucune information n’a été inventée ou supposée
– [ ] Tous les écrans de la chaîne sont documentés
– [ ] Toutes les options réelles sont documentées
– [ ] Toutes les touches de fonction actives sont documentées
– [ ] Le vocabulaire est orienté utilisateur (pas technique)
– [ ] Le diagramme Mermaid est clair et complet
– [ ] Les cas d’usage sont pratiques et réalistes
– [ ] Le glossaire explique les termes métier
– [ ] Les représentations d’écrans sont présentes

## Exemple de Prompt pour Bob

« `
Crée une documentation utilisateur pour la chaîne de traitement [NOM].
Sources à analyser :
– Programme principal : [chemin/XXXP00.RPGLE]
– Écran principal : [chemin/XXXD00.DSPF]
– Autres programmes : [liste]

Instructions :
1. Analyse TOUS les fichiers sources fournis
2. Extrais les informations réelles (options, touches, écrans)
3. Crée la documentation en suivant le SKILL-DOCUMENTATION-UTILISATEUR
4. N’invente AUCUNE information
5. Utilise un vocabulaire orienté utilisateur

« `

## Conseils de Rédaction

### Vocabulaire Utilisateur vs Technique
| Terme Technique | Terme Utilisateur |
|——————-|———————|
| Subfile | Liste |
| Option 2 du subfile | Modifier un élément |
| Indicateur 30 | Champ actif/inactif |
| EXFMT | Affichage de l’écran |
| F8 = Extraction | F8 = Exporter les données |
| RPGLE | Programme |

### Structure des Phrases
**Bon** : « Saisissez le code de la bibliothèque à analyser »  
**Mauvais** : « Le champ C_BIB attend une valeur CHAR(10) »

**Bon** : « Appuyez sur F6 pour créer un nouveau texte »  
**Mauvais** : « CF06 appelle le programme SCNFLDP10 »

**Bon** : « La liste affiche les résultats de la recherche »  
**Mauvais** : « Le subfile SFL01 contient les enregistrements »

## Gestion des Cas Particuliers

### Écrans avec Subfile (Listes)
– Décrire la liste comme « Liste des [éléments] »
– Documenter les colonnes affichées
– Expliquer comment naviguer (Page Up/Down)
– Lister les options disponibles sur chaque ligne

### Écrans de Confirmation
– Mettre en évidence les avertissements
– Expliquer clairement les conséquences de la confirmation
– Documenter les deux choix (Oui/Non)

### Écrans de Saisie
– Indiquer les champs obligatoires
– Expliquer le format attendu
– Donner des exemples de saisie valide

## Livrables Attendus

À la fin de l’utilisation de ce SKILL, Bob doit produire :
1. **Un fichier Markdown** contenant la documentation complète
2. **Un diagramme Mermaid** de navigation entre écrans
3. **Des représentations d’écrans** (ASCII ou captures)
4. **Une liste de vérification** confirmant l’analyse des sources

## Notes Importantes
**La fiabilité est PRIORITAIRE sur la rapidité**
– Prendre le temps d’analyser chaque source
– Vérifier chaque information avant de la documenter
– En cas de doute, analyser à nouveau le code source

**La documentation doit être autonome**
– Un utilisateur doit pouvoir utiliser l’application avec uniquement ce guide
– Aucune connaissance technique ne doit être requise
– Tous les termes métier doivent être expliqués

**La maintenance est facilitée**
– Les sources analysés sont référencés
– Les informations sont traçables
– Les mises à jour peuvent être faites en réanalysant les sources