Safe refactor
Skill sharklandy/claude-code-starter-kit/skills/process/safe-refactor
Skills, subagents et templates /goal//loop//schedule prêts à l'emploi pour Claude Code — installables en une commande via /plugin marketplace add
npx -y skills add sharklandy/claude-code-starter-kit --skill safe-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guardrail before any non-trivial refactor: confirm sufficient test coverage exists first. Trigger whenever asked to refactor, restructure, clean up, or rewrite existing code without changing its behavior.
SKILL.md
2.7 KB, as published. Nobody here has run it
<!-- Skill générique de la "vague 2" (par opposition aux skills orientés cas d'usage de la vague 1) -->
Garde-fou avant un refactor (générique)
- Identifier précisément le périmètre du refactor (fichiers, fonctions, modules concernés) avant toute modification.
- Vérifier qu'une couverture de tests suffisante existe déjà sur ce
périmètre :
- Lancer la suite de tests existante et confirmer qu'elle passe avant toute modification (état de référence).
- Identifier si les chemins de comportement significatifs du périmètre (cas nominal, cas limites principaux, cas d'erreur) sont couverts par au moins un test — pas seulement si un fichier de test existe.
- Si la couverture est insuffisante : ne pas refactorer à l'aveugle. Proposer d'abord d'ajouter des tests de caractérisation — des tests qui décrivent le comportement actuel du code tel qu'il est réellement (pas tel qu'il devrait être), pour disposer d'un filet de sécurité avant de changer la structure interne.
- Effectuer le refactor par petites étapes vérifiables, en relançant la suite de tests (existante + tests de caractérisation ajoutés) après chaque étape plutôt qu'une seule fois à la toute fin.
- Confirmer en fin de refactor qu'aucun comportement observable n'a changé, sauf si un changement de comportement était explicitement demandé et documenté séparément du refactor lui-même.
Gotchas
- Un refactor "pur" qui change accidentellement un comportement observable (ordre d'itération, message d'erreur exact, format de sortie) casse parfois des consommateurs externes qui dépendaient de ce détail non documenté — traiter tout changement observable comme un signal d'alerte, pas comme un détail d'implémentation sans conséquence.
- Une couverture de tests élevée en pourcentage de lignes ne garantit pas une couverture des cas limites réels — ne pas se fier uniquement au pourcentage rapporté par l'outil de couverture pour juger qu'un refactor est sûr.
- Les zones trop risquées pour un refactor sans supervision humaine se
repèrent par deux signaux : la mémoire de projet des subagents
code-revieweretbug-investigator(.claude/agent-memory/) quand elle existe, et une forte densité de commitsfixrécents sur les mêmes fichiers dansgit log. En présence de l'un des deux, demander avant de refactorer.