# Rl Analyzer > Ensemble de commandes pour structurer et piloter le cycle d'analyse, de revue, d'implementation et de validation d'une demande ou tache. Commandes disponibles : help, init, best-practices, asking, analysis, review, process, validate, re-process. - Skill: `rivolink/rl-analyzer` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add rivolink/rl-analyzer` - Raw SKILL.md: https://api.skillmd.com/api/skills/rivolink/rl-analyzer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: RivoLink (https://skillmd.com/u/rivolink) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/rivolink/rl-analyzer --- # RL Analyzer Executer la commande **$0**. Identifier la commande parmi les sections ci-dessous et suivre ses instructions. Les arguments supplementaires sont : `$ARGUMENTS`. ## Resolution du parametre Applicable aux commandes qui acceptent `` : - Si le parametre est un fichier de demande (`ask.txt`, `ask.md`), retrouver l'analyse correspondante dans `.notes/claude/outs/` (meme nom sans extension + `-analysis.md`). - Si le parametre est directement un fichier `*-analysis.md`, l'utiliser et retrouver la demande correspondante dans `.notes/claude/asks/` (meme nom sans le suffixe `-analysis`, au format `.txt` ou `.md`). --- ## Commande : help Afficher le message suivant a l'utilisateur : **RL Analyzer** — Commandes disponibles : 1. **init** — Initialise l'environnement de travail du projet. 2. **best-practices** `` — Ajoute des bonnes pratiques. 3. **asking** `` — Cree un fichier de demande a partir d'un prompt. 4. **analysis** `` `` — Analyse une demande sans modifier le code. 5. **review** `` `` — Revue critique de l'analyse. 6. **process** `` `` — Applique les modifications de code. 7. **validate** `` `` — Revue critique des modifications de code. 8. **re-process** `` `` — Corrige le code selon le rapport de validation. **Syntaxe :** `/rl-analyzer [arguments]` **Flux recommande :** ``` asking ──> analysis <──> review ──> process ──> validate <──> re-process ``` - **Boucle 1** : `analysis` et `review` jusqu'a ce que l'analyse soit coherente. - **Boucle 2** : `validate` et `re-process` jusqu'a obtenir le statut "Valide". --- ## Commande : init Initialiser l'environnement de travail du projet. 1. Verifier si le fichier `.gitignore` a la racine du projet existe. Si non, le creer. 2. Verifier si le `.gitignore` contient le bloc suivant. Si absent (en tout ou en partie), l'ajouter ou le completer : ``` # Custom *.rl /.notes ``` 3. Creer l'arborescence suivante (ignorer les dossiers/fichiers qui existent deja) : ``` {project-dir} └── .notes └── claude ├── asks/ ├── docs/ │ └── best-practices.md ├── imgs/ ├── outs/ └── ASK.txt ``` 4. Confirmer a l'utilisateur les actions realisees. --- ## Commande : best-practices Ajouter des bonnes pratiques au fichier de reference du projet. **Arguments :** `` — Description des bonnes pratiques a ajouter. 1. Ouvrir `.notes/claude/docs/best-practices.md`. Si le fichier n'existe pas, le creer avec un titre `# Bonnes pratiques`. 2. Ajouter les bonnes pratiques decrites dans ``, formulees de maniere concise. 3. Organiser les ajouts par sections thematiques si applicable. 4. Confirmer a l'utilisateur les pratiques ajoutees. --- ## Commande : asking Creer un fichier de demande a partir du prompt utilisateur. **Arguments :** - `` — Prompt libre decrivant la demande. **Fichier de sortie :** `.notes/claude/asks/.txt`. **Comportement :** 1. Si le prompt est vide, **demander interactivement** a l'utilisateur de fournir un prompt. Ne pas continuer tant qu'un prompt non vide n'est pas obtenu. 2. **Reformuler** le prompt pour plus de clarte tout en conservant strictement le sens d'origine : corriger la syntaxe, clarifier les tournures ambigues, retirer les typos. Ne pas ajouter d'information absente de l'original. 3. Generer un nom de fichier en **kebab-case** derive du **prompt reformule** (slug) : - Conserver uniquement les caracteres `[a-zA-Z0-9]`, passer en minuscules. - Remplacer tout autre caractere (espaces, ponctuation, accents, symboles) par `-`. - Fusionner les tirets consecutifs, retirer les tirets de debut/fin. - **Raccourcir intelligemment** le slug pour qu'il reste **expressif** tout en ne depassant pas **30 caracteres** (limite appliquee au slug seul, avant tout suffixe) : - Supprimer les mots vides (articles, prepositions, conjonctions) pour ne garder que les mots porteurs de sens. Exemples de mots vides : le, la, les, de, du, des, un, une, au, aux, en, et, ou, pour, dans, sur, avec, par, the, an, of, to, in, on, for, and, or, with. Cette liste est indicative — l'adapter selon le contexte et la langue du prompt. - Si le slug depasse encore la limite, raccourcir en conservant les mots-cles les plus significatifs (techniques, noms propres, verbes d'action) pour preserver le sens global du prompt. Privilegier l'ensemble des mots-cles porteurs de sens sur toute la longueur du prompt, pas seulement ceux du debut. - Toujours couper a une **frontiere de mot** (jamais au milieu d'un mot). - Retrimer les tirets de fin apres raccourcissement. 4. Cible : `.notes/claude/asks/.txt`. 5. **Collision de nom** : si `.txt` existe deja, utiliser une **indexation numerique** incrementale (`-1.txt`, `-2.txt`, ...) jusqu'a obtenir un nom libre. Pas d'ecrasement. 6. Creer le dossier `.notes/claude/asks/` s'il n'existe pas. 7. Ecrire dans le fichier le **prompt reformule** (texte brut, sans en-tete, sans metadonnees). Le texte doit etre **bien formate** selon les regles suivantes : - Limiter chaque ligne a environ **90-100 caracteres**. Les lignes doivent rester assez longues pour etre lisibles, mais ne pas depasser cette limite. - Inserer les retours a la ligne **intelligemment**, en coupant de preference apres une virgule, un point, un point-virgule, deux-points, ou un autre signe de ponctuation. - Ajouter des **lignes vides** entre les idees distinctes pour aerer le texte. - Utiliser des **listes a puces** (`- `) quand le contenu comporte plusieurs points ou elements enumeres, pour structurer le texte. - Ne pas ecrire un bloc de texte continu sur une seule ligne. 8. Afficher a l'utilisateur le resultat formate comme suit, en respectant les sauts de ligne : - Ligne 1 : `Fichier cree :` suivi du chemin `.notes/claude/asks/.txt` - Ligne 2 : vide - Ligne 3 : `Pour lancer l'analyse :` - Ligne 4 : `/rl-analyzer analysis .notes/claude/asks/.txt` **Regles :** - **Ne jamais modifier le code source.** Cette commande ne produit qu'un fichier ask. - **Ne pas declencher l'analyse automatiquement.** Se contenter de la proposer. - **Ne pas ajouter d'en-tete** dans le fichier (pas de date, pas d'auteur, pas de titre). - **Ne pas alterer le sens du prompt** lors de la reformulation. --- ## Commande : analysis Analyser une demande ou une tache sans modifier le code source. **Arguments :** - `` — Chemin vers le fichier de demande (normalement dans `.notes/claude/asks/`, generalement `.txt`, peut aussi etre `.md`). - `` — Informations supplementaires (optionnel). **Fichier de sortie :** `.notes/claude/outs/` avec le meme nom que la source (sans extension), suffixe par `-analysis.md`. - `.notes/claude/asks/feature.txt` → `.notes/claude/outs/feature-analysis.md` - `.notes/claude/asks/feature.md` → `.notes/claude/outs/feature-analysis.md` **Comportement :** 1. Lire et analyser la demande decrite dans ``. 2. Prendre en compte les informations supplementaires fournies dans ``. 3. Si le fichier de sortie existe deja, verifier s'il contient une section **"Rapport de revue"**. Si oui : - Lire chaque incoherence et question identifiee dans le rapport de revue. - Corriger les points concernes dans l'analyse (reformuler, completer ou supprimer les parties incoherentes). - Les questions du rapport de revue sont repondues manuellement par l'utilisateur. Integrer ses reponses dans l'analyse. - Si des questions n'ont pas encore de reponse, les conserver dans la section "Rapport de revue". - Une fois tous les points traites et toutes les questions repondues, supprimer la section "Rapport de revue" de l'analyse mise a jour. 4. Explorer le code source du projet pour comprendre le contexte technique. 5. Produire (ou mettre a jour) une analyse detaillee au format Markdown couvrant : - Comprehension de la demande - Impact sur le code existant - Approche technique recommandee - Points d'attention 6. Ajouter en fin d'analyse une **table QA** avec trois colonnes et 10 lignes de tests : | Intitule | Etat | Screenshot | |----------|------|------------| | Test 1 | | | | ... | | | 7. Enregistrer le resultat dans le fichier de sortie. 8. Afficher a l'utilisateur la proposition de commande suivante selon la logique : - Si c'est la **premiere analyse** (le fichier de sortie n'existait pas avant cette execution) → afficher : - Ligne 1 : `Pour lancer la revue :` - Ligne 2 : `/rl-analyzer review ` - Si le fichier existait et contenait un "Rapport de revue" avec des **questions sans reponse** restantes → ne proposer aucune commande. Afficher : - Ligne 1 : `Des questions du rapport de revue n'ont pas encore de reponse.` - Ligne 2 : `Repondez aux questions dans le fichier, puis relancez :` - Ligne 3 : `/rl-analyzer analysis ` - Sinon (analyse suivante sans questions en suspens) → afficher : - Ligne 1 : `Pour relancer une revue :` - Ligne 2 : `/rl-analyzer review ` - Ligne 3 : vide - Ligne 4 : `Pour lancer le traitement :` - Ligne 5 : `/rl-analyzer process ` - `` est le meme parametre que celui recu par la commande. **Regles :** - **Ne jamais modifier le code source.** Cette commande produit uniquement une analyse. - **Ne jamais remplir** les colonnes Etat et Screenshot de la table QA. Elles sont reservees a une validation manuelle. --- ## Commande : review Effectuer une revue critique d'une analyse existante sans modifier le code source. **Arguments :** - `` — Chemin vers le fichier de demande ou directement vers l'analyse. - `` — Informations supplementaires (optionnel). **Prerequis :** L'analyse correspondante doit exister dans `.notes/claude/outs/`. Si elle est absente, **demander a l'utilisateur** de d'abord produire une analyse. Ne pas continuer sans l'analyse. **Comportement :** 1. Lire la demande originale et l'analyse correspondante. 2. Detecter les **incoherences** entre la demande et l'analyse. 3. Detecter les **incoherences internes** dans l'analyse elle-meme. 4. Detecter les **regressions potentielles** si applicable. 5. Poser des **questions** si des zones d'ombre subsistent. 6. Pour chaque question, proposer **2 a 3 reponses possibles** afin de guider l'utilisateur dans son choix. L'utilisateur reste libre de choisir une proposition ou de formuler sa propre reponse dans le champ "Reponse :". 7. Parmi les propositions, indiquer clairement celle qui est **recommandee** en ajoutant la mention `(recommande)`. Format : **Q1 : [Intitule de la question]** - a) [Proposition 1] - b) [Proposition 2] **(recommande)** - c) [Proposition 3] **Reponse :** 8. Mettre a jour le fichier `*-analysis.md` pour y ajouter une section **"Rapport de revue"** contenant les incoherences et les questions identifiees. Les incoherences restent en texte libre. Si **aucune incoherence**, aucune question et aucune regression potentielle n'est detectee, ajouter quand meme la section avec un statut positif : ``` ## Rapport de revue Aucune incoherence detectee. L'analyse est coherente avec la demande. ``` 9. Afficher a l'utilisateur la proposition de commande suivante : - Ligne 1 : `Pour relancer l'analyse :` - Ligne 2 : `/rl-analyzer analysis ` - `` est le meme parametre que celui recu par la commande. **Regles :** - **Ne jamais modifier le code source.** Cette commande produit uniquement une revue. --- ## Commande : process Realiser les modifications de code en suivant strictement une analyse existante. **Arguments :** - `` — Chemin vers le fichier de demande ou directement vers l'analyse. - `` — Informations supplementaires (optionnel). **Prerequis :** L'analyse correspondante doit exister dans `.notes/claude/outs/`. Si elle est absente, **demander a l'utilisateur** de d'abord produire une analyse. Ne pas continuer sans l'analyse. **Comportement :** 1. Lire l'analyse correspondante. 2. Appliquer les modifications de code decrites dans l'analyse. 3. Respecter les **normes et standards** du code existant dans le projet. 4. Suivre les **bonnes pratiques** definies dans `.notes/claude/docs/best-practices.md` si le fichier existe. 5. Afficher a l'utilisateur la proposition de commande suivante : - Ligne 1 : `Pour lancer la validation :` - Ligne 2 : `/rl-analyzer validate ` - `` est le meme parametre que celui recu par la commande. **Regles :** - **Modifier le code** en suivant strictement l'analyse. - **Ne pas prendre de decisions** en dehors du perimetre de l'analyse. --- ## Commande : validate Effectuer une revue critique des modifications de code sans modifier le code source. **Arguments :** - `` — Chemin vers le fichier de demande ou directement vers l'analyse. - `` — Informations supplementaires (optionnel). **Prerequis :** L'analyse correspondante doit exister dans `.notes/claude/outs/`. Si elle est absente, **demander a l'utilisateur** de d'abord produire une analyse. Ne pas continuer sans l'analyse. **Comportement :** 1. Faire une revue critique des modifications de code realisees. 2. Verifier la **coherence** entre les modifications, la demande et l'analyse. 3. Verifier que les modifications respectent les **bonnes pratiques** definies dans `.notes/claude/docs/best-practices.md` si le fichier existe. 4. Verifier les **regressions potentielles** introduites par les modifications. 5. Mettre a jour l'analyse en ajoutant (ou en mettant a jour) une section **"Rapport de validation"** contenant : - Le statut de validation : **Valide** ou **Non valide**. - Si **Non valide** : les notes, remarques et questions detaillees, suffisamment documentees pour etre traitees. 6. Si une section "Rapport de validation" existe deja : - Verifier si les points precedemment releves ont ete traites. - Supprimer les points resolus. - Conserver les points non resolus dans la version mise a jour de la section. 7. Afficher a l'utilisateur la proposition de commande suivante selon la logique : - Si le statut est **Valide** → ne proposer aucune commande. Afficher : `Tache validee. Le flux est termine.` - Si le statut est **Non valide**, evaluer la nature des problemes : - **Corrections mineures** (erreurs de style, petits bugs, oublis simples, ajustements de nommage, formatage) → afficher : - Ligne 1 : `Pour lancer le re-traitement :` - Ligne 2 : `/rl-analyzer re-process ` - **Problemes majeurs** (logique incorrecte, incoherence avec la demande, approche technique a revoir, regression fonctionnelle) → afficher : - Ligne 1 : `Pour relancer l'analyse :` - Ligne 2 : `/rl-analyzer analysis ` - `` est le meme parametre que celui recu par la commande. **Regles :** - **Ne jamais modifier le code source.** Cette commande produit uniquement un rapport de validation. --- ## Commande : re-process Traiter les corrections identifiees dans le rapport de validation. **Arguments :** - `` — Chemin vers le fichier de demande ou directement vers l'analyse. - `` — Informations supplementaires (optionnel). **Prerequis :** - L'analyse correspondante doit exister dans `.notes/claude/outs/`. Si elle est absente, **demander a l'utilisateur** de d'abord produire une analyse. - L'analyse doit contenir une section **"Rapport de validation"**. Si elle est absente, **demander a l'utilisateur** de d'abord lancer une validation. - Ne pas continuer si l'un de ces prerequis n'est pas rempli. **Comportement :** 1. Lire la section **"Rapport de validation"** dans l'analyse. 2. Traiter chaque point/note identifie dans le rapport. 3. Appliquer les corrections de code necessaires. 4. Respecter les **normes et standards** du code existant dans le projet. 5. Suivre les **bonnes pratiques** definies dans `.notes/claude/docs/best-practices.md` si le fichier existe. 6. Afficher a l'utilisateur la proposition de commande suivante : - Ligne 1 : `Pour relancer la validation :` - Ligne 2 : `/rl-analyzer validate ` - `` est le meme parametre que celui recu par la commande. **Regles :** - **Modifier le code** uniquement pour traiter les points du rapport de validation. - **Ne faire aucune analyse.** Ne pas prendre de decisions en dehors du perimetre du rapport. - **Ne pas modifier la section "Rapport de validation".** Sa mise a jour est le role de la commande validate.