G1en-114/rtfm-first-skill

RTFM-First

Considérez les manuels fournis par l'utilisateur comme la seule source faisant autorité pour cette tâche. N'écrivez pas de code de mémoire ou à partir d'informations trouvées en ligne.

Règles absolues

1. Lorsqu'un manuel existe, lisez-le avant d'écrire du code ; les noms d'API, paramètres, valeurs par défaut, unités et comportements sont ceux du manuel.
2. Avant de coder, vérifiez la version du manuel avec celle de l'environnement actuel (voir « Scanner l'environnement et vérifier les versions ») et rapportez votre conclusion à l'utilisateur.
3. Lorsque vous citez un fait crucial du manuel, indiquez sa source : .rtfm/<nom>.txt:numéro_de_ligne ou PAGE n.
4. En cas de contradiction entre le manuel, le code ou l'environnement, ne « corrigez » pas immédiatement le code pour correspondre aux conventions en ligne ; arrêtez-vous, expliquez la différence et laissez l'utilisateur décider.
5. S'il n'y a pas de manuel, demandez ou confirmez le chemin du manuel avant de commencer à implémenter quoi que ce soit de mémoire.
6. Avant chaque « correction », vous devez pouvoir pointer vers la règle du manuel qui est violée ; si vous ne pouvez pas fournir de source, vous n'êtes pas autorisé à modifier le code.

Flux de travail

1. Localiser et extraire le manuel

• Si l'utilisateur n'a pas fourni de chemin, cherchez des candidats dans le projet (*.pdf, *.md, docs/**, ou les spécifications mentionnées dans le README) ; s'il y a plusieurs candidats, listez-les et demandez à l'utilisateur de confirmer.
• Les scripts se trouvent dans le répertoire scripts/ situé au même endroit que ce SKILL.md.
• Extrayez le contenu unifié dans .rtmf/ à la racine du projet (s'il s'agit d'un dépôt git, assurez-vous que .gitignore inclut .rtfm/) :
  • PDF : exécutez le script scripts/extract_manual.py <manuel.pdf> .rtmf/<nom>.txt
  • MD/TXT : exécutez le même script, il copiera sous forme de texte.
• S'il y a plusieurs manuels (par exemple, référence API + spécification de protocole + documentation SDK), extrayez-les tous et créez un index pour chacun ; lors des citations, précisez de quel manuel il s'agit.
• Si le PDF est une numérisation (le texte extrait est trop court), signalez qu'une OCR est nécessaire ; ne devinez pas le contenu.
• Si le script indique « aucun extracteur de texte PDF », installez poppler-utils ou pypdf (demandez d'abord l'accord de l'utilisateur pour une installation système) et réessayez ; ne sautez pas le PDF pour écrire de mémoire.
• Lisez d'abord la page de titre / préface / historique des versions, et notez : nom du produit, version du manuel, versions applicables, date, notes de révision.

2. Créer un index

• Exécutez le script scripts/index_manual.py .rtmf/<nom>.txt .rtmf/index.md du skill.
• Pour trouver un sujet, utilisez rg -n sur l'index et le texte intégral ; ne partez pas du principe que le manuel ne contient pas l'information parce que vous ne vous en souvenez pas.

3. Scanner l'environnement et vérifier les versions

• Rassemblez les preuves de l'environnement : fichiers de verrouillage/liste (package.json, pyproject.toml, Cargo.lock, go.mod, requirements*.txt, etc.), --version/-V, pkg-config --modversion, version d'exécution, SDK / chaîne d'outils / identifiant matériel.
• Recherchez la version du manuel sur la couverture, l'historique des versions, le pied de page, les métadonnées.
• Évaluez selon references/version-matching.md : MATCH / COMPATIBLE / MISMATCH / UNKNOWN.
• Écrivez la conclusion dans .rtmf/version-report.md et rapportez-la à l'utilisateur.
• En cas de MISMATCH ou UNKNOWN, arrêtez-vous : demandez à l'utilisateur de fournir le manuel de la version correspondante, ou confirmez explicitement qu'il peut continuer ; après approbation, notez le risque dans les notes.

4. Coder selon le manuel

• Avant de commencer chaque composant/API, lisez entièrement les sections pertinentes ; extrayez les signatures clés, constantes, valeurs par défaut et cas limites dans .rtmf/notes.md avec leur source.
• Structure suggérée pour .rtmf/notes.md : nom et version du manuel, conclusion de vérification (MATCH/COMPATIBLE/MISMATCH/UNKNOWN), extraits par sujet (chacun avec manuel.txt:Lligne ou PAGE n), historique des modifications.
• Copiez les identifiants, chaînes, nombres directement depuis le texte original du manuel pour éviter les erreurs de transcription.
• Pour les points non couverts par le manuel, marquez TODO + source (par exemple, « section X du manuel non spécifiée ») ; ne comblez pas silencieusement avec des informations en ligne ; si vous devez ajouter, demandez d'abord l'accord de l'utilisateur.
• Ce que dit le manuel est ce qui compte : même si cela diffère des « meilleures pratiques » en ligne, ne le « corrigez » pas à plusieurs reprises pour le faire correspondre à la version en ligne, sauf si l'utilisateur le demande ou si des preuves de compilation/de test montrent que la page du manuel ne correspond pas à l'environnement actuel.

5. Validation et finalisation

• Après avoir terminé, passez en revue chaque section par rapport au manuel : chaque API/configuration/comportement utilisé doit avoir une source dans les notes.
• Lancez la compilation/les tests ; en cas d'échec, revenez d'abord aux sections pertinentes du manuel pour trouver des preuves, puis vérifiez l'environnement ; il est interdit de deviner.
• Lors de la livraison, listez brièvement : version du manuel, version de l'environnement, conclusion de la vérification, sources principales, et toute divergence nécessitant la confirmation de l'utilisateur.

Empêcher la boucle de corrections

La raison d'être de ce skill : l'IA ne lit pas le manuel → « corrige » le code de mémoire → se trompe encore → corrige à nouveau, réécrivant sans cesse. Les règles suivantes doivent être respectées :

• Prouvez avant de modifier : avant chaque modification du code/de la configuration, indiquez « la ligne du manuel que l'implémentation actuelle viole » et citez la source ; si vous ne pouvez pas fournir de source, n'apportez aucune modification.
• Une seule raison par modification : ne mélangez pas « ce qui ne semble pas correct » avec « ce qui contredit le manuel » dans une même modification ; les morceaux de code non concernés restent inchangés.
• Si le même phénomène apparaît après avoir été corrigé deux fois : arrêtez les rustines, revenez au manuel, lisez entièrement la section concernée, remettez en doute votre compréhension plutôt que de continuer à deviner.
• En cas de conflit entre le comportement du manuel et les conventions en ligne : suivez le manuel ; ne transformez pas un code « qui fonctionne mais ne respecte pas le manuel » en version en ligne, et vice versa.
• En cas d'erreur, consultez d'abord le manuel : cherchez les sections sur les codes d'erreur, contraintes, cas limites ; si le manuel n'a pas d'entrée correspondante, recherchez ensuite des preuves dans l'environnement ; il est interdit de modifier par intuition.
• Chaque modification doit ajouter une ligne dans l'historique des modifications de .rtmf/notes.md : objectif, ce qui a été changé, source de la justification. Si après deux tours vous ne parvenez toujours pas à la bonne solution, consultez l'historique pour repérer les répétitions.