decode

Profil de l'utilisateur

Lire ~/.config/remia-tooling/simple/profil.md (le profil du skill simple, partagé : niveau,
termes à définir d'office, stack, couches). Puis le glossaire propre à ce skill :
~/.config/remia-tooling/decode/glossaire.md (tournures déjà décodées). Fichiers absents : faire
sans, et proposer de les remplir à la fin (jamais sans accord).

Ce que ce skill n'est pas

simple répare ma explication ratée, et raccourcit. decode fait comprendre le texte
d'un autre, et garde tout. L'utilisateur comprend les concepts ; ce qui bloque, ce sont les
raccourcis (idiomes de développeur, tournures de texte rédigé par une IA) et le code qu'il ne
connaît pas par cœur. Une règle « terse » ou « pas de récap » de ses instructions générales ne
s'applique pas ici : la complétude est la consigne.

Protocole

1. La source exacte, jamais de mémoire. Récupérer le texte mot pour mot (API publique de la
forge, fichier, collage) et ce à quoi il répond (notre message précédent, l'issue d'origine) :
sans lui, ses allusions (« your two asides », « as today ») restent opaques.

2. Contexte, 3 à 5 lignes. Qui parle, à quoi il répond, ce qu'on lui avait demandé, avec
les noms réels (fichier, fonction, numéro d'issue).

3. Paragraphe par paragraphe, dans l'ordre, sans en sauter. Pour chacun :

• sa phrase d'ouverture, citée (le paragraphe entier s'il est court) ;
• ce qu'il dit, en français simple, phrases complètes ;
• chaque raccourci décodé dans la phrase même : idiome (« sharp edge », « reached the wire »),
  mot de métier (« caller », « contract », « entry point », « coerce »), sigle — sa définition en
  moins de 15 mots, entre parenthèses ou après un tiret, au premier usage ;
• dans le code, seulement quand ça éclaire l'enjeu : fichier:ligne vérifié par grep -n,
  l'extrait de 1 à 3 lignes qui porte le point, et ce qu'il fait concrètement (un exemple de
  valeur qui entre, ce qui sort) ;
• un principe, un cas réel : toute affirmation abstraite (sécurité, architecture, « qui appelle
  quoi », « d'où viennent les valeurs ») reçoit un exemple tiré du projet de l'utilisateur, avec de
  vraies valeurs (« quand tu ouvres un mail, le plugin reçoit uid=128 du navigateur ; quelqu'un
  peut envoyer uid=128 EVIL »). Un principe sans cas est la première cause de décrochage mesurée,
  bien avant le vocabulaire ;
• un jugement, son critère : quand l'auteur classe quelque chose (faille ou angle coupant, bug ou
  choix, grave ou bénin, « not sacred »), rendre pourquoi il le classe ainsi, pas seulement
  l'étiquette (« pas une faille, parce qu'aujourd'hui rien ne lui passe autre chose que des nombres
  venus du serveur ; un angle coupant, parce que ça deviendrait une faille dès qu'un plugin lui passe
  une valeur du navigateur ») ;
• pour nous, si le paragraphe change quelque chose pour l'utilisateur ou son projet.

Une liste à puces de l'auteur se décode puce par puce. Un bloc de code de l'auteur se lit ligne
par ligne.

Vérifier ce qui est annoncé comme fait. « Fixed on master », « I added a test », « already
merged » : aller lire le vrai commit ou le vrai fichier sur la forge (API publique, raw.), pas une
copie locale d'une autre version. Citer le hash court, la date, et ce que le commit contient de plus
que l'annonce (un détail du correctif, un fichier de test inattendu). Introuvable : le dire.

4. Garder le ton. Un compliment, un refus poli, une réserve, une concession, une question
qui attend une réponse précise : chacun est nommé pour ce qu'il est (« c'est un refus, adouci
par… »). Séparer toujours « il dit » de « j'en déduis » ; aucune intention prêtée sans le texte.

5. Finir par « ce qu'il attend de toi » : questions à répondre, décisions à prendre, gestes
promis de part et d'autre. Si une réponse existe déjà (brouillon), la nommer par son chemin.

6. « Qui a écrit », en 3 à 5 lignes, à la fin. Indices observables seulement : écart d'horodatage
entre un commit et le message (secondes = agent), formules reprises mot pour mot d'un texte à
l'autre, structure et tournures typiques d'un LLM, phrase qui détonne (souvent la part humaine). Une
estimation en pourcentage, donnée comme estimation. Conséquence pratique : si un agent lit, répondre
en anglais simple, précis, point par point.

Forme

• Un fichier dans le projet, à côté de la source quand elle y est (ex. docs/pr/<sujet>-traduit.md),
  sinon dans le dossier de docs du projet ; pas dans le chat : il se relit à côté du texte d'origine.
• Un paragraphe par ligne (aucun retour à la ligne dur au milieu d'une phrase) ; titres ## par
  paragraphe source, numérotés dans l'ordre.
• Deux voix, séparées à l'œil. La traduction (« ce qu'il dit », son ton) est en texte normal.
  Tout ce que j'ajoute et qu'il n'a pas écrit est entre ⟦ et ⟧ : définition d'un raccourci,
  contexte, passage du code, « pour nous », « j'en déduis ». Le marqueur ouvre et ferme dans le même
  paragraphe ; un paragraphe entier d'explication est entièrement entre ⟦ ⟧. Les citations de la
  source restent hors marqueurs. Test : en retirant tout le ⟦…⟧, il reste une traduction fidèle
  et lisible.
• L'ouvrir s'il y a un terminal à côté, avec le decode.nanorc posé à côté de ce SKILL.md (dossier
  de base du skill) : nano --rcfile <dossier du skill>/decode.nanorc <fichier>. Il colore le
  ⟦…⟧ en vert clair, garde les titres (phrase source) en jaune comme le markdown de nano, et règle le confort (retour à la ligne entre les mots, souris, barre de
  position). Le fichier doit finir par -traduit.md.
• Dans le chat : une ligne de verdict (où est le fichier), puis les 1 ou 2 points où le détour par
  le code change la compréhension. Rien d'autre.

Vérification avant d'envoyer

1. Chaque paragraphe de la source a sa section (compter) ? Chaque principe abstrait a son cas réel, chaque jugement son critère ?
2. Chaque idiome ou mot de métier est-il défini à son premier usage, dans la phrase même ?
3. Chaque fichier:ligne cité a-t-il été vérifié par grep -n dans cette session ?
4. Rien de résumé ; tout ajout que l'auteur n'a pas écrit est entre ⟦ ⟧ (et « j'en déduis » s'il s'agit d'une intention) ?

Après chaque /decode : apprendre (toujours avec accord)

• Glossaire — proposer d'ajouter à ~/.config/remia-tooling/decode/glossaire.md les tournures
  décodées cette fois (tournure · sens en français · exemple). Une tournure déjà au glossaire est
  rappelée en 3 mots la fois suivante, plus définie en entier.
• Profil — un terme de métier qui revient : proposer de l'ajouter aux « termes à définir
  d'office » du profil de simple.
• Jamais de secret, de donnée client ni de nom de personne dans le glossaire.