doc-sync
Vérifier que la documentation IdeaVim correspond aux modifications du code
La documentation dérive souvent après les mises à jour du code et crée des exemples cassés pour les utilisateurs. Cette compétence fournit un flux de travail structuré pour comparer la documentation avec le code fonctionnel et identifier les écarts.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "doc-sync". Vérifier les exemples de mappages obsolètes dans README.md
Résultat attendu:
- Deux exemples avec des paramètres supprimés trouvés dans la section mappages
- README.md devrait référencer le nouveau nom MappingScope au lieu de l'ancien nom
- Aucun autre problème détecté dans le fichier README
Utilisation de "doc-sync". Vérifier doc/ideavim-api.md après la version 2.0
Résultat attendu:
- 5 signatures API identifiées comme ayant changé dans la version 2.0
- 3 noms de paramètres dans les exemples doivent être mis à jour pour correspondre aux nouvelles signatures
- 1 bloc de code utilise une méthode supprimée qui a été supprimée
Utilisation de "doc-sync". Vérifier si CONTRIBUTING.md correspond au flux de travail git actuel
Résultat attendu:
- Toutes les commandes git dans CONTRIBUTING.md correspondent au flux de travail de la branche actuelle
- Aucun écart trouvé entre les étapes documentées et le comportement git réel
Audit de sécurité
SûrAll 35 static findings are FALSE POSITIVES. The static analyzer misidentified markdown documentation text as security threats. SKILL.md is pure documentation containing workflow instructions and example bash commands shown as documentation - no executable code exists. The skill-report.json already correctly assessed this as safe with no risk factors.
Facteurs de risque
🌐 Accès réseau (1)
📁 Accès au système de fichiers (1)
⚙️ Commandes externes (18)
Score de qualité
Ce que vous pouvez construire
Audit post-version
Confirmer que la documentation reflète les modifications récentes de l'API après la fin d'un cycle de publication.
Revue de docs avant PR
Valider les exemples et les noms de paramètres avant de soumettre les modifications de documentation.
Tri de régression
Vérifier si les problèmes de documentation signalés correspondent à de véritables modifications de l'API dans le code.
Essayez ces prompts
Vérifier doc/ideavim-mappings.md par rapport au code actuel et lister les écarts trouvés.
J'ai modifié MappingScope.kt. Identifier la documentation affectée et proposer des mises à jour spécifiques.
Auditer tous les fichiers dans doc/ pour les exemples obsolètes et résumer les conclusions dans un rapport.
Valider tous les exemples utilisant map(), nmap() et vmap() par rapport aux signatures API actuelles dans le code.
Bonnes pratiques
- Commencer par une implémentation fonctionnelle pour établir une vérité de base avant de comparer les docs
- Prioriser les éléments API supprimés ou renommés lors de la vérification de la dérive de documentation
- Garder les mises à jour minimales et alignées avec le style et la terminologie de la documentation existante
Éviter
- Mettre à jour la formulation lorsque le comportement sous-jacent est toujours exact
- Sauter la vérification des paramètres nommés dans les exemples de code
- Supposer que la documentation est correcte sans vérifier l'implémentation fonctionnelle