duongphuhiep/dakubo-skills

Utilisez lorsque l'utilisateur souhaite répondre à une remarque de révision de code en ajoutant un commentaire éclairant dans le code source, afin que le relecteur comprenne le raisonnement et ne formule pas la même remarque à nouveau. Se déclenche sur « répondre à la remarque #N », « ajouter un commentaire pour répondre à l'inquiétude du relecteur », « documenter pourquoi nous avons fait X » ou toute demande de résolution d'une constatation de révision via une explication dans le code plutôt qu'une modification de code.

Qu'est-ce que dakubo-skills ?

Cette compétence automatise la résolution de remarques de révision de code en insérant un commentaire explicatif directement dans le code source, à l'endroit approprié. Elle est conçue pour les développeurs utilisant des agents IA comme Claude Code, Cursor ou Codex dans le cadre de workflows de révision de code (notamment avec les outils Dakubo). L'objectif est d'éviter que les mêmes remarques ne se reproduisent lors de futures révisions, en documentant le raisonnement derrière une décision de conception, un compromis assumé ou le contexte général. La compétence analyse la remarque (généralement issue d'un tableau `dakubo-display-pr-remarks`), lit le fichier concerné, identifie la construction ciblée (méthode, bloc, champ, ligne), puis rédige un commentaire court (1 à 4 lignes) placé juste au-dessus de cette construction ou en ligne. Le commentaire ne mentionne ni le relecteur ni le numéro de la PR, et ne répète pas le code existant. L'utilisateur peut fournir l'explication ou celle-ci peut être déduite du contexte de la conversation.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/duongphuhiep/dakubo-skills/tree/HEAD/package/skills/dakubo-answer-review-remark-in-code

Documentation

Répondre à une remarque de révision

Résoudre une remarque de révision de code en insérant un commentaire explicatif au bon endroit dans le code source, afin que les futurs relecteurs ne soulèvent pas la même préoccupation.

Entrées

Déduire les deux entrées du contexte de la conversation. Demander seulement en cas d'ambiguïté.

Entrée 1 — La remarque. Une constatation d'un relecteur : généralement une ligne de tableau avec un emplacement (fichier:ligne) et une description de la préoccupation. Le tableau provient généralement de la compétence dakubo-display-pr-remarks ou dakubo-review-commit-range. Si aucun tableau n'est présent dans la conversation et que l'une de ces compétences est disponible, l'utiliser pour créer le tableau. Sinon, demander la remarque à l'utilisateur.

Entrée 2 — L'explication. La réponse du développeur : pourquoi le code est correct en l'état, la décision de conception derrière celui-ci, le compromis accepté ou le contexte général que le relecteur a manqué. Cela ne contredit pas nécessairement directement la remarque — cela peut simplement changer la perspective du relecteur.

Processus

Lire le fichier à l'emplacement spécifié dans l'Entrée 1.
Identifier la construction exacte que la remarque cible (méthode, bloc, champ, ligne).
Rédiger un commentaire qui :
- Capture l'essence de l'Entrée 2 (le raisonnement / la décision / le contexte).
- Est concis — une à quatre lignes maximum.
- Ne mentionne pas le relecteur, la PR ou le numéro de la remarque (les commentaires survivent aux révisions).
- Ne répète pas ce que le code dit déjà — ajouter uniquement le POURQUOI qui n'est pas évident à la lecture.
- Répond à la préoccupation de la remarque si cela rend l'explication plus claire, mais cela reste facultatif.
Placer le commentaire immédiatement au-dessus de la construction ciblée, ou en ligne si un commentaire en fin de ligne s'intègre naturellement.
Appliquer la modification.

Sortie

Confirmer le fichier et la ligne où le commentaire a été ajouté. Une phrase suffit.

Ce qu'il ne faut PAS faire

Ne pas réécrire le code sauf si l'utilisateur le demande explicitement.
Ne pas écrire un commentaire qui se contente de reformuler ce que fait le code.
Ne pas faire référence à « le relecteur a dit… » ou « PR #N » à l'intérieur du commentaire.
Ne pas ajouter un commentaire de plus d'environ 4 lignes ; si l'explication nécessite plus, elle appartient à un document de conception ou à un message de commit, pas à un commentaire en ligne.