receiving-code-review
Gérer les retours de code review avec rigueur technique
Également disponible depuis: obra,Cygnusfear,Cycleaddict,DYAI2025,davila7,ZhanlinCui,CodingCossack
La code review nécessite une évaluation technique, pas une performance émotionnelle. Cette compétence guide les assistants IA pour vérifier les retours avant d'implémenter, poser des questions de clarification et fournir une opposition raisonnée lorsque les suggestions sont techniquement infondées.
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 "receiving-code-review". Reviewer: Remove the legacy code path for old API versions
Résultat attendu:
Vérification des requirements de compatibilité... Build target est 10.15+, mais cette API nécessite 13+. Le legacy path est toujours nécessaire pour la rétrocompatibilité. Cependant, l'implémentation actuelle a le mauvais bundle ID. Je peux corriger le bundle ID ou nous pouvons abandonner le support pré-13. Quelle direction préférez-vous ?
Utilisation de "receiving-code-review". Reviewer: Fix items 1-6 in the PR
Résultat attendu:
Je comprends les éléments 1, 2, 3 et 6. J'ai besoin de clarification sur les éléments 4 et 5 avant d'implémenter. Pouvez-vous détailler quels changements vous recherchez sur ces deux éléments ?
Utilisation de "receiving-code-review". Reviewer: Add proper error handling with retry logic and exponential backoff
Résultat attendu:
Corrigé. Ajout de Try/Catch avec retry logic (3 tentatives, exponential backoff commençant à 100ms) à l'appel API dans api_service.rb:42-58. Les tests passent.
Audit de sécurité
SûrStatic analysis flagged 24 instances of backtick patterns and 4 blocker patterns, but all are FALSE POSITIVES. The skill file (SKILL.md) is documentation-only markdown containing instructional text for AI behavior. No executable code, network calls, file operations, or cryptographic functions exist. The backtick patterns are markdown code blocks showing workflow examples, not shell execution. Blocker patterns are misidentified text fragments in documentation.
Score de qualité
Ce que vous pouvez construire
Assistant IA Recevant une Review Humaine
Un assistant IA reçoit des retours de code review d'un développeur humain et doit déterminer quels éléments implémenter, lesquels nécessitent clarification et lesquels contester avec un raisonnement technique.
Développeur Junior Apprenant à Répondre aux Reviews
Un développeur junior apprend à répondre aux retours d'un développeur senior avec rigueur technique au lieu d'un accord performatif, en vérifiant les suggestions avant une implémentation aveugle.
Contributeur Externe Gérant les Retours des Mainteneurs
Un contributeur externe reçoit des retours des mainteneurs du projet et doit évaluer si les suggestions correspondent à l'architecture du projet avant d'implémenter.
Essayez ces prompts
J'ai reçu des retours de code review avec 6 éléments. Je comprends les éléments 1, 2, 3 et 6, mais j'ai besoin de clarification sur les éléments 4 et 5 avant de procéder. Pouvez-vous expliquer quels changements vous recherchez sur ces éléments spécifiques ?
Votre suggestion de supprimer la couche de compatibilité legacy casserait le support pour macOS 10.15. L'implémentation actuelle cible 10.15+ mais utilise des APIs qui nécessitent 13+. Dois-je corriger le bundle ID pour maintenir la rétrocompatibilité, ou abandonner complètement le support pré-13 ?
Le reviewer a suggéré d'implémenter un suivi de métriques complet avec stockage base de données, filtres par date et export CSV. J'ai cherché dans le codebase et n'ai trouvé aucun appelant pour cet endpoint. Dois-je le supprimer suivant YAGNI, ou y a-t-il un usage que je manque ?
J'ai contesté votre suggestion, mais après avoir vérifié les résultats de test vous aviez raison. Ma compréhension était erronée car j'avais manqué l'échec du test d'intégration. J'implémente la correction maintenant.
Bonnes pratiques
- Toujours vérifier les retours sur le code réel avant d'implémenter des changements
- Implémenter les changements un par un et tester chacun individuellement pour détecter les régressions tôt
- Contester avec un raisonnement technique lorsque les suggestions casseraient des fonctionnalités existantes
Éviter
- Dire 'Vous avez absolument raison !' ou 'Excellent point !' avant de vérifier le retour
- Implémenter des retours aveuglément sans vérifier si cela casse des fonctionnalités existantes
- Implémenter les éléments 1-3 et 6 en sautant les éléments flous 4-5 sans demander d'abord