Synthèse automatique
Analyse la conversation en cours pour identifier où une skill a mal fonctionné, en diagnostiquer la cause racine et proposer des correctifs ciblés du fichier SKILL.md.
Points forts
- Compare explicitement le comportement attendu (lu dans le fichier de skill) et le comportement réel observé, sous forme de tableau avant/après
- Fournit un catalogue de symptômes fréquents (étapes sautées, piège CSO de la description, arrêt prématuré, format de sortie erroné) associés à leurs causes probables
- Propose chaque correction sous forme de diff avec un « pourquoi » explicable, puis demande l'accord de l'utilisateur avant d'appliquer
- Inscrit la réparation dans une boucle itérative : une cause racine à la fois, puis re-test de la skill
Limites
- Repose entièrement sur la conversation courante : si la skill a tourné dans une autre session, il n'y a plus de preuves à analyser
- N'applique aucune correction sans validation, ce qui ajoute des allers-retours manuels
- Suppose que le problème vient des instructions de la skill et non du modèle, ce qui peut passer à côté de limites réelles du modèle
À utiliser juste après qu'une skill a sauté des étapes, produit un format inattendu ou s'est arrêtée trop tôt, pendant que la trace de la conversation est encore disponible.
À éviter pour créer une skill de zéro, corriger un bug applicatif classique, ou diagnostiquer une exécution qui n'a pas eu lieu dans la session en cours.
Analyse de sécurité
SûrThe skill only instructs analyzing conversation history, reading skill files, diagnosing issues, and proposing fixes with explicit user approval before any changes. It does not include destructive commands, network exfiltration, obfuscation, or any instruction to disable safety. No meaningful execution risk is present.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
/heal-skill ~/.claude/skills/release-notes/SKILL.md — it wrote the notes but skipped the checklist at the end entirely. Figure out why and show me the fix.The skill I just ran stopped before creating any files. Can you trace what it actually did versus what the skill says, find the root cause, and propose a diff?/heal-skill — something went wrong in this session but I'm not sure which skill was active. Detect it from the conversation and confirm with me before diagnosing.description: Diagnose and fix a skill that didn't work correctly in the current session argument-hint: [optional: path to skill file]
/heal-skill — Skill Self-Repair
Analyze the current conversation to find where a skill misbehaved, diagnose the root cause, and propose targeted fixes.
When to Use
After running a skill that:
- Skipped steps it should have followed
- Followed the description instead of the body (CSO trap)
- Stopped too early or went too far
- Produced wrong output format
- Missed context it should have loaded
- Behaved differently than intended
Process
1. Identify the skill
If $ARGUMENTS is provided, read that file. Otherwise, analyze the conversation to detect which skill was running. Look for:
/command-nameinvocations- Skill descriptions that appeared in system context
- Workflow patterns that match known skills
Ask the user to confirm: "It looks like [skill-name] didn't work as expected. Is that right?"
2. Gather evidence
From the conversation, extract:
What was expected — what the skill file says should happen (read the actual skill file)
What actually happened — trace Claude's actual behavior step by step:
- Which steps were followed?
- Which steps were skipped or altered?
- Where did behavior diverge from the skill's instructions?
The gap — specific delta between expected and actual behavior
Present this as a before/after comparison:
Expected (from skill): Actually happened:
1. Ask for intent 1. Asked for intent ✓
2. Configure frontmatter 2. Skipped — jumped to writing ✗
3. Write body 3. Wrote body (partial) ~
4. Quality checklist 4. Skipped entirely ✗
5. Create files 5. Created files ✓
3. Diagnose root cause
Common failure modes to check:
| Symptom | Likely Cause | |---------|-------------| | Steps skipped | Description summarizes workflow (CSO trap) — Claude shortcuts | | Wrong workflow chosen | Description too vague, triggers on wrong queries | | Stopped too early | No success criteria defined | | Output format wrong | No template or example provided | | Context not loaded | File references too deep or ambiguous | | Inconsistent behavior | Conflicting instructions between sections | | Over-executed | No clear stopping point or "wait for user" gate |
Ask: "Does this diagnosis match what you saw?"
4. Propose fixes
For each root cause, show the specific edit:
## Fix 1: CSO Trap in description
File: ~/.claude/skills/my-skill/SKILL.md, line 3
Before:
description: Dispatches subagent per task with code review between tasks
After:
description: Use when executing implementation plans with independent tasks
Why: The old description leaked workflow details, causing Claude to
follow the description as a shortcut instead of reading the full skill.
Show all proposed fixes as diffs. Include the "why" for each — the user needs to understand the fix, not just apply it.
5. Apply with approval
Ask: Which fixes should I apply?
- All fixes — apply everything
- Pick and choose — list fixes by number, let user select
- None — just keep the diagnosis, fix manually
After applying fixes, suggest: "Want to test the skill again to verify the fix?"
Principles
- Evidence first — always trace actual behavior from the conversation before diagnosing
- One root cause at a time — don't propose 10 fixes at once. Find the primary failure, fix it, re-test
- The skill is the bug — if Claude didn't follow the skill, the skill's instructions weren't clear enough. Don't blame the model, fix the instructions
- Show your work — every fix needs a "why" that the user can evaluate
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/skill-self-repair-mryiqinq/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/skill-self-repair-mryiqinq' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/skill-self-repair-mryiqinq/download' --output '.skill-downloads/skill-self-repair-mryiqinq/SKILL.md.part' && mv '.skill-downloads/skill-self-repair-mryiqinq/SKILL.md.part' '.skill-downloads/skill-self-repair-mryiqinq/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.
Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/skill-self-repair-mryiqinq/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.