Imported from divalto/divalto-ia-devkit (plugins/divalto-devkit/skills/pushing-retex-to-github/SKILL.md). Install upstream with npx skills add divalto/divalto-ia-devkit --skill pushing-retex-to-github. Copyright stays with the author.

pushing-retex-to-github

Contenu

• Utilisation rapide
• Configuration initiale
• Comment ca marche
• Scripts disponibles
• Mode degrade
• References

Utilisation rapide

Premiere fois -- configurer le repo cible

py plugin/skills/pushing-retex-to-github/scripts/init_config.py `
    --retex-file "retex/RETEX-skills.md" `
    --repo "divalto/divalto-ia-devkit"

Cree retex/.retex-github.json (config) et retex/.retex-pushed.json (tracking avec toutes les entrees existantes marquees comme "deja poussees" -- pas de backfill).

Pousser les nouvelles entrees a la main

py plugin/skills/pushing-retex-to-github/scripts/push_new_entries.py `
    --retex-file "retex/RETEX-skills.md"

Detecte les R-NNN absents du tracking, cree une issue GitHub par entree, met a jour le tracking. Sortie JSON sur stdout : {"pushed": [...], "skipped": [...], "errors": [...]}.

Toujours passer --retex-file explicitement vers le RETEX du workspace courant. Sur un poste multi-projets, un glob large risque de selectionner le mauvais RETEX-skills.md.

Backfill (pousser TOUTES les entrees existantes)

py plugin/skills/pushing-retex-to-github/scripts/push_new_entries.py `
    --retex-file "retex/RETEX-skills.md" --backfill --yes-i-want-to-push-everything

CHECKPOINT -- Ne lancer --backfill qu'apres validation explicite du collaborateur. Risque de pollution massive du repo si lance par erreur sur un fichier RETEX historique.

Configuration initiale

Prerequis cote partenaire

1. Installer GitHub CLI : voir reference/setup-gh-cli.md
2. S'authentifier : gh auth login (via navigateur ou token)
3. Avoir un acces write au repo cible (ex divalto/divalto-ia-devkit)

Fichiers de configuration

Resolution en cascade (push) : --config explicite -> .retex-github.json local (a cote du RETEX) -> ~/.claude/.retex-github.json global (partage entre workspaces, cree via init_config.py --global). Le tracking .retex-pushed.json reste TOUJOURS local : la numerotation R-NNN est propre a chaque workspace ; un tracking partage creerait des collisions d'ID. Le local surcharge toujours le global.

Format de .retex-github.json

{
  "repo": "divalto/divalto-ia-devkit",
  "labels_default": ["retex"],
  "labels_categorie": {
    "BUG-SKILL": "bug-skill",
    "BUG-DOC":   "bug-doc",
    "SUGGESTION": "suggestion",
    "ENV":        "env",
    "CLAUDE-TOOL": "claude-tool"
  },
  "labels_severite": {
    "CRITIQUE": "severite:critique",
    "HAUTE":    "severite:haute",
    "MOYENNE":  "severite:moyenne",
    "BASSE":    "severite:basse",
    "INFO":     "severite:info"
  }
}

Comment ca marche

Detection automatique (via hook)

Quand le hook plugin/hooks/push_retex_to_github.py est enregistre (PostToolUse sur Edit/Write), chaque modification de RETEX-skills.md declenche en arriere-plan :

Edit RETEX-skills.md
   v
Hook PostToolUse (non bloquant)
   v
py push_new_entries.py --retex-file <path>
   v
Parse les R-NNN
   v
Pour chaque R-NNN absent du tracking ou avec hash modifie :
   - Nouveau -> gh issue create
   - Modifie -> gh issue comment (sur l'issue deja liee)
   v
Update retex/.retex-pushed.json
   v
Log dans retex/.retex-push.log

Mapping RETEX -> Issue GitHub

Voir reference/issue-format.md pour le template exact.

Idempotence

retex/.retex-pushed.json enregistre pour chaque R-NNN :

• Numero de l'issue GitHub creee
• Hash SHA-1 du contenu de l'entree

Sur un nouveau push :

• R-NNN absent du tracking -> gh issue create
• R-NNN present + hash inchange -> skip
• R-NNN present + hash modifie -> gh issue comment sur l'issue existante avec la nouvelle version

Scripts disponibles

Tous les scripts utilisent argparse, sortent JSON sur stdout, et respectent les exit codes : 0 succes, 1 erreur applicative, 2 erreur d'usage.

Mode degrade

gh non installe

Detect: `gh --version` echoue
Action: log "gh CLI absent. Voir reference/setup-gh-cli.md" dans .retex-push.log
        exit 0 (non bloquant), le hook ne fige pas l'edition de RETEX-skills.md

gh non authentifie

Detect: `gh auth status` retourne exit != 0
Action: log "gh non authentifie. Lancer `gh auth login`" dans .retex-push.log
        exit 0 (non bloquant)

Repo inaccessible

Detect: `gh issue create` echoue avec 403 / 404
Action: log l'erreur, marquer l'entree comme "pending" dans tracking
        Au prochain push, retry automatique

Conflit de tracking

Detect: .retex-pushed.json contient R-NNN -> issue 42, mais l'issue 42 a ete fermee/supprimee
Action: re-create + warning dans log

Symptomes courants (diagnostic)

Le push tourne en arriere-plan via le hook : s'il echoue, rien ne le signale a l'ecran (le hook est non bloquant par conception). Pour diagnostiquer quand des RETEX n'apparaissent pas en issues :

Lancer le script a la main (push_new_entries.py --retex-file …) affiche le diagnostic directement ; le hook, lui, reste silencieux (par conception).

References

• reference/setup-gh-cli.md -- Installation et authentification de GitHub CLI cote partenaire
• reference/issue-format.md -- Template exact du corps d'issue et conventions de titre / labels