Compétences receiving-code-review
📦

receiving-code-review

Sûr

Gérer les retours de revue de code avec vérification technique

Également disponible depuis: Cygnusfear,DYAI2025,Cycleaddict,davila7,CodingCossack,obra

La revue de code nécessite une évaluation technique, pas une performance émotionnelle. Cette compétence fournit un modèle structuré pour vérifier les retours de revue avant implémentation, assurant l'exactitude technique plutôt que le confort social.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "receiving-code-review". Reviewer: Remove legacy code

Résultat attendu:

Checking compatibility requirements... Build target is 10.15+, this API needs 13+. Current implementation has wrong bundle ID. Options: fix bundle ID or drop pre-13 support. Which do you prefer?

Utilisation de "receiving-code-review". Reviewer: Implement metrics tracking with database, date filters, CSV export

Résultat attendu:

Searched codebase - no code calls this endpoint. Recommend removal per YAGNI. Is there expected usage I should know about?

Utilisation de "receiving-code-review". Partner: Fix items 1-6

Résultat attendu:

I understand items 1, 2, 3, and 6. I need clarification on items 4 and 5 before proceeding with implementation.

Audit de sécurité

Sûr
v1 • 2/24/2026

All static analysis findings are false positives. The skill file (SKILL.md) is a markdown documentation file containing instructional text, not executable code. Backticks detected are markdown code block delimiters, not shell command execution. No actual cryptographic operations, network calls, or command injection vectors exist in this skill.

1
Fichiers analysés
214
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Réponse aux revues multi-éléments

Lors de la réception d'une liste de 6+ éléments de retour, clarifier d'abord les éléments peu clairs, puis implémenter par ordre de priorité (problèmes bloquants en premier), en testant chaque changement individuellement pour détecter rapidement les régressions

Scepticisme envers les réviseurs externes

Lorsque des réviseurs externes suggèrent des changements sans contexte complet, vérifier l'exactitude technique pour votre codebase, vérifier les changements cassants, et contester avec des preuves lorsque la suggestion est erronée

Filtrage de fonctionnalités YAGNI

Lorsque les réviseurs suggèrent d'implémenter des fonctionnalités 'correctement' avec base de données, filtres et exports, utiliser grep sur le codebase d'abord pour confirmer l'usage réel avant d'ajouter une complexité inutile

Essayez ces prompts

Clarifier les retours peu clairs 
I received code review feedback with items 1-6. I understand items 1, 2, 3, and 6, but items 4 and 5 are unclear. Before implementing anything, I need clarification on what exactly is expected for items 4 and 5.
Vérifier la suggestion d'un réviseur externe 
A reviewer suggested changing X to Y. Let me verify: Is this technically correct for this codebase? Does it break existing functionality? What was the reason for the current implementation? I'll check the code and tests before proceeding.
Contester avec un raisonnement technique 
I understand your suggestion to do X, but this would break Y because of Z. The current implementation handles edge case A and B. If we change this, we need to also update C and D. Should I proceed with the full scope or keep the current approach?
Vérification YAGNI pour les demandes de fonctionnalités 
You suggested implementing X with full database support, date filters, and CSV export. I searched the codebase and found no callers of this endpoint. Should I remove it entirely per YAGNI, or is there usage I'm missing?

Bonnes pratiques

  • Toujours clarifier tous les éléments peu clairs avant d'implémenter une partie des retours
  • Vérifier les suggestions par rapport au comportement réel du codebase, pas seulement la logique de surface
  • Contester avec un raisonnement technique spécifique, pas de la défensive ou de l'émotion

Éviter

  • Dire 'Vous avez absolument raison !' ou 'Excellent point !' avant vérification
  • Implémenter les retours immédiatement sans vérifier la réalité du codebase
  • Implémenter plusieurs éléments en lot sans tester chaque changement individuellement

Foire aux questions

Que dois-je faire lorsque les retours de revue sont peu clairs ?
Arrêter immédiatement et demander des clarifications sur les éléments peu clairs avant d'implémenter quoi que ce soit. Les éléments peuvent être liés, et une compréhension partielle conduit à une mauvaise implémentation.
Comment contester la suggestion d'un réviseur ?
Utiliser un raisonnement technique avec des preuves spécifiques. Référencer les tests fonctionnels, le comportement du code ou les exigences de compatibilité. Poser des questions spécifiques plutôt que de faire des déclarations défensives.
Que faire si le réviseur a raison et que j'ai contesté ?
Énoncer la correction factuellement : 'Vous aviez raison - j'ai vérifié X et cela fait Y. Implémentation en cours.' Éviter les longues excuses ou les explications excessives sur pourquoi vous avez contesté.
Dois-je remercier les réviseurs pour leurs retours ?
Non. Les actes parlent plus fort. Corrigez simplement le problème et montrez ce qui a changé. Si vous vous surprenez à écrire 'Merci', supprimez-le et énoncez plutôt la correction.
Comment gérer les suggestions d'implémenter des fonctionnalités 'correctement' ?
D'abord utiliser grep sur le codebase pour l'usage réel. Si aucun code n'appelle le endpoint ou la fonctionnalité, suggérer la suppression selon YAGNI. Implémenter complètement uniquement s'il y a un usage confirmé.
Dans quel ordre dois-je implémenter des retours multi-éléments ?
Après avoir clarifié tous les éléments, implémenter dans cet ordre : problèmes bloquants d'abord (cassures, sécurité), puis corrections simples (fautes de frappe, imports), puis corrections complexes (refactoring, logique). Tester chaque correction individuellement.

Détails du développeur

Auteur

ZhanlinCui

Licence

MIT

Dépôt

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/receiving-code-review

Réf

main

Structure de fichiers

📄 SKILL.md