aeon-skill-repair
Réparation ciblée d'une seule skill défaillante. Construire un dossier diagnostique, classifier la défaillance, appliquer le playbook correspondant, attacher une recette de vérification.
Inputs
| Param | Description |
|---|---|
target |
Nom de la skill ou chemin SKILL.md. Obligatoire. |
error_output |
Résultat échoué récent (coller depuis le journal d'exécution). Obligatoire si non auto-détectable. |
mode |
repair (défaut) ou dry-run (diagnostic uniquement). |
Sources de diagnostic
- Le fichier skill (frontmatter, sources déclarées, références de variables d'environnement).
- Signature d'erreur (codes HTTP, erreurs API courantes, hits de rate-limit, marqueurs de refus).
- Disponibilité de la source — WebFetch sur les URLs référencées pour détecter les 404, redirections, changements de schéma.
- Intégrité du frontmatter (YAML valide).
Catégories de défaillance et portée de correction
| Catégorie | Détection | Portée de correction |
|---|---|---|
api-change |
404/410, schéma incompatible | Mettre à jour endpoints/payload/headers selon spec en direct. Citer l'URL de la spec. |
rate-limit |
429, "too many requests" | Ajouter backoff ou endpoint de secours. Ne jamais augmenter la limite. |
timeout |
Tué en cours d'exécution, sortie partielle | Organiser le travail par étapes, ajouter early-return sur succès partiel. |
sandbox-limitation |
Curl porteur d'authentification échoue | Convertir en motif prefetch / postprocess. |
prompt-bug |
Hallucination, refus, section requise manquante | Insertion de spécificité en édition minimale. < 30 lignes de diff. |
output-format |
Sortie passe l'exécution mais échoue le parser en aval | Éditer jusqu'à ce que la prochaine exécution satisfasse l'assertion échouée. |
missing-secret |
"API key missing", variable d'env non définie | Aucune modification de code. Nommer la variable manquante pour l'opérateur. Quitter avec REPAIR_DIAGNOSED_NO_FIX. |
config |
Mauvaise config d'entrée (watchlist, fichier de liste) | Corriger les erreurs de forme évidentes. Ne jamais inventer d'entrées. |
unknown |
Aucune des catégories précédentes | Ne pas éditer à l'aveugle. Ajouter le dossier à repair-notes, quitter avec REPAIR_DIAGNOSED_NO_FIX. |
Classes de risque
- LOW — fallback ajouté, commentaire uniquement, < 30 lignes. Auto-appliquée.
- MED — changement de source de données, édition du format de sortie. Auto-appliquée avec recette de vérification.
- HIGH — touche fondamentalement le comportement, change les défauts. Révision opérateur requise, non auto-appliquée.
Recette de vérification (chaque réparation)
1. Re-lancer la skill : <invocation une ligne>
2. Attendu : <signal spécifique à la catégorie — "aucun rate-limit dans la trace" / "≥ 200 mots" / "correspond au motif X">
3. Si toujours échouée : <chemin de secours>Cooldown
Cooldown de 24h par skill — prévient les boucles de réparation sur les corrections qui n'ont pas tenu. État dans repair-history.json local.
Règles
- Une cible par exécution. Ne jamais regrouper des réparations non liées.
- Principe d'édition minimale. Petits diffs.
- Ne jamais modifier la configuration de variables d'env. Les secrets manquants sont signalés à l'opérateur.
- À l'intérieur d'un repo git : branche + diff, jamais directement vers main.