Revue de Code Ouverte

Cette compétence du plugin Codex reflète intentionnellement la compétence canonique présente dans skills/open-code-review/SKILL.md. Maintenir les deux fichiers synchronisés lors de la mise à jour des instructions de l'agent OCR ; un lien symbolique est évité car l'installation du plugin ne matérialise que le sous-arbre du plugin.

Une compétence pour invoquer open-code-review (ocr) — un CLI de revue de code IA open-source qui lit les diffs Git et génère des commentaires de revue structurés au niveau des lignes.

Vérification des prérequis

Avant de commencer une revue, vérifier l'environnement :

# 1. Vérifier que le CLI est installé
which ocr || echo "NOT INSTALLED"

# 2. Vérifier la connectivité LLM
ocr llm test

Si ocr n'est pas installé, l'installer d'abord :

npm install -g @alibaba-group/open-code-review

Si ocr llm test échoue, l'utilisateur doit configurer un LLM. Les guider avec l'une de ces options :

Option A — Variables d'environnement (priorité la plus élevée, recommandée pour CI) :

export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=<api-key>
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true

Option B — Configuration persistante :

ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token <api-key>
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true

S'arrêter ici et demander à l'utilisateur de fournir les identifiants — ne jamais inventer ni coder en dur les clés API.

Flux de travail

Étape 1 : Rassembler le contexte métier

Analyser la cible de la revue (commits, branche ou changements) pour extraire un contexte métier concis. Passer ce contexte via --background pour améliorer la qualité de la revue.

Étape 2 : Exécuter la revue de code

Exécuter la commande OCR avec les drapeaux appropriés. Toujours passer le contexte métier via --background quand disponible :

ocr review --audience agent --background "contexte métier ici" [args-utilisateur]

Gestion des arguments :

• Contexte de fond (RECOMMANDÉ) : utiliser --background "contexte" ou -b "contexte" pour fournir le contexte métier pour une meilleure qualité de revue
• Par défaut (aucun argument utilisateur) : revue des changements en staging, en dehors du staging et non tracés (mode workspace)
• Commit spécifique : utiliser --commit ou -c pour reviser un commit unique contre son parent
• Comparaison de branche : utiliser --from <ref> et --to <ref> pour reviser diff entre deux refs
• Timeout : le timeout par défaut est 10 minutes par fichier ; ajuster avec --timeout <minutes>
• Concurrence : la concurrence par défaut est 8 workers de fichiers ; réduire avec --concurrency <n> si les limites de taux sont atteintes
• Mode aperçu : utiliser --preview ou -p pour apercevoir quels fichiers seront reviewés sans exécuter le LLM
• Installation : si la commande ocr n'est pas trouvée, l'installer en exécutant npm i -g @alibaba-group/open-code-review

Modèles d'invocation courants :

Mode de sortie :

• Toujours utiliser --audience agent pour supprimer l'UI de progression et émettre uniquement le résumé final

Étape 3 : Classer et rapporter

Pour chaque commentaire de la sortie de la revue, classer par priorité et rapporter tous les problèmes à l'utilisateur :

• Haute : Bugs évidents, problèmes de sécurité, erreurs claires ou suggestions bien fondées avec des propositions de correction précises
• Moyenne : Préoccupations raisonnables mais dépendant du contexte, suggestions de style/performance ou corrections nécessitant une implémentation manuelle
• Basse : Faux positifs probables, manque de contexte suffisant, pointillages ou suggestions sans sens

Rapporter tous les commentaires groupés par niveau de priorité.

Étape 4 : Corriger

Avant d'appliquer les corrections, vérifier si l'utilisateur a demandé des corrections automatiques :

• Si l'utilisateur a explicitement demandé « revue et correction » ou similaire, procéder aux corrections automatiques
• Si l'utilisateur n'a demandé que « revue » sans intention de correction, demander la permission avant d'appliquer des modifications

Lors de la correction des problèmes et suggestions :

• Se concentrer sur les éléments de priorité haute et moyenne
• Appliquer les corrections directement au code quand c'est sûr et bien défini
• Pour les corrections complexes nécessitant une intervention manuelle, décrire clairement ce qui doit être fait
• Toujours vérifier les corrections avec l'utilisateur avant de faire un commit

Format de sortie

Chaque commentaire contient :

• path : Chemin du fichier
• content : Texte du commentaire de revue
• start_line / end_line : Plage de lignes (tous les deux 0 signifie que le positionnement a échoué)
• suggestion_code : Suggestion de correction optionnelle
• existing_code : Extrait de code original optionnel
• thinking : Processus de raisonnement LLM optionnel

Après filtrage des commentaires par priorité, présenter les résultats à l'aide de ce modèle :

## Résultats de la revue de code

**Fichiers reviewés** : N
**Problèmes trouvés** : X haute priorité / Y priorité moyenne

### Haute priorité

- **`chemin/vers/fichier.java:42`** — Brève description
  > Recommandation : Comment corriger

### Priorité moyenne

- **`chemin/vers/fichier.ts:88`** — Brève description
  > Recommandation : Comment corriger (si applicable)

Si la revue n'a trouvé aucun problème après filtrage, simplement indiquer : « Revue terminée — aucun problème trouvé dans N fichiers. »

Classification des priorités :

• Haute : Bugs évidents, problèmes de sécurité, erreurs claires ou suggestions bien fondées avec des propositions de correction précises
• Moyenne : Préoccupations raisonnables mais dépendant du contexte, suggestions de style/performance ou corrections nécessitant une implémentation manuelle
• Basse : Ignorées silencieusement (faux positifs probables, manque de contexte, pointillages ou suggestions sans sens)

Gestion des commentaires mal positionnés :

Quand start_line et end_line sont tous les deux 0, le commentaire n'a pas réussi à localiser la position exacte dans le fichier. Dans ces cas :

1. Lire le contenu du commentaire pour comprendre le problème
2. Examiner le fichier cible mentionné dans le commentaire
3. Identifier la section de code pertinente basée sur le contexte du commentaire
4. Appliquer la correction ou la suggestion au bon endroit

Règles de revue personnalisées

Si l'utilisateur souhaite des règles spécifiques au projet, OCR les résout dans cet ordre de priorité :

1. Drapeau --rule <chemin> (le plus élevé)
2. <repo>/.opencodereview/rule.json
3. ~/.opencodereview/rule.json
4. Défauts système intégrés (le plus bas)

Par défaut, la première règle utilisateur correspondante remplace la règle système intégrée. Définir merge_system_rule: true sur une entrée de règle quand la règle système correspondante et la règle utilisateur doivent être toutes les deux incluses.

Format du fichier de règles :

{
  "rules": [
    {
      "path": "**/*.java",
      "rule": "Toutes les nouvelles méthodes doivent valider les paramètres requis pour null",
      "merge_system_rule": true
    },
    {
      "path": "**/*mapper*.xml",
      "rule": "Vérifier SQL pour les risques d'injection et les balises fermantes manquantes"
    }
  ]
}

Pour apercevoir quelle règle s'applique à un fichier avant de revoir :

ocr rules check src/main/java/com/example/Foo.java

Pièges

• Le LLM doit être configuré en premier — ocr review échouera bruyamment si aucun LLM n'est accessible. Toujours exécuter ocr llm test avant la première revue.
• Le répertoire de travail est important — ocr review opère sur le repo Git du répertoire courant. Utiliser --repo /chemin/vers/repo pour exécuter depuis ailleurs.
• Les fichiers non tracés sont reviewés en mode workspace — exécuter ocr review sans arguments inclut les changements en staging, hors staging, et non tracés. Stager de manière sélective si vous voulez une portée plus étroite.
• Les diffs volumineux peuvent atteindre les limites de tokens — les fichiers avec très gros diffs peuvent être tronqués. Le MAX_TOKENS par défaut est 58888 par demande.
• Phase de plan déclenchée à 50 lignes — les diffs dépassant 50 lignes modifiées exécutent une phase supplémentaire d'analyse des risques avant la revue principale. Cela ajoute de la latence mais améliore la qualité.
• Ne pas passer --audience human — il diffuse en continu l'UI de progression qui pollue la sortie. Toujours utiliser --audience agent.
• La langue des commentaires suit la configuration — définir la configuration language à English ou Chinese (par défaut : Chinese) pour contrôler la langue des commentaires de revue.

Validation

Après la fin de la revue, vérifier le succès en vérifiant :

1. La commande s'est terminée avec le code 0
2. Des commentaires ont été générés (ou le message « No comments generated » apparaît)
3. Les avertissements (le cas échéant) sont affichés dans stderr

Si des erreurs se sont produites, vérifier les avertissements stderr pour plus de détails sur les fichiers qui ont échoué et pourquoi.

Références

• Documentation complète : https://github.com/alibaba/open-code-review
• Package NPM : https://www.npmjs.com/package/@alibaba-group/open-code-review
• Suivi des problèmes : https://github.com/alibaba/open-code-review/issues