Revue de code ouverte

Une skill 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 lancer une revue, vérifiez 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é, installez-le d'abord :

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

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

Option A — Variables d'environnement (priorité la plus haute, recommandé 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

Arrêtez-vous ici et demandez à l'utilisateur de fournir les identifiants — ne jamais inventer ni coder en dur les clés API.

Flux de travail

Étape 1 : Recueillir le contexte métier

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

Étape 2 : Lancer la revue de code

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

ocr review --audience agent --background "business context here" [user-args]

Gestion des arguments :

• Contexte de fond (RECOMMANDÉ) : utiliser --background "context" ou -b "context" pour fournir un contexte métier améliorant la qualité de la revue
• Par défaut (pas d'arguments utilisateur) : revue des changements staged, unstaged et untracked (mode workspace)
• Commit spécifique : utiliser --commit ou -c pour revuer un commit par rapport à son parent
• Comparaison de branches : utiliser --from <ref> et --to <ref> pour revuer le diff entre deux refs
• Timeout : le timeout par défaut est 10 minutes par fichier ; ajustez avec --timeout <minutes>
• Concurrence : la concurrence par défaut est 8 workers de fichier ; réduisez avec --concurrency <n> si des rate limits sont atteints
• Mode aperçu : utiliser --preview ou -p pour voir un aperçu des fichiers qui seront revus sans exécuter le LLM
• Installation : si la commande ocr n'est pas trouvée, installez-la avec npm i -g @alibaba-group/open-code-review

Patterns 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 : Classifier et rapporter

Pour chaque commentaire de la sortie de revue, classifier 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 correctifs nécessitant une implémentation manuelle
• Basse : Probablement des faux positifs, manquant de contexte suffisant, ergotages ou suggestions insignifiantes

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

Étape 4 : Corriger

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

• Si l'utilisateur a explicitement demandé "review and fix" ou similaire, procédez aux corrections automatiques
• Si l'utilisateur a seulement demandé "review" sans intention de correction, demandez la permission avant d'appliquer des changements

Lors de la correction des problèmes et suggestions :

• Se concentrer sur les éléments de priorité Haute et Moyenne
• Appliquer les correctifs directement au code quand c'est sûr et bien défini
• Pour les correctifs complexes nécessitant une intervention manuelle, décrire clairement ce qui doit être fait
• Toujours vérifier les correctifs 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 (les deux à 0 signifient que le positionnement a échoué)
• suggestion_code : Suggestion de correctif optionnelle
• existing_code : Snippet de code original optionnel
• thinking : Processus de raisonnement du LLM optionnel

Après filtrage des commentaires par priorité, présentez les résultats en utilisant ce modèle :

## Résultats de la revue de code

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

### Haute priorité

- **`path/to/file.java:42`** — Brève description
  > Recommandation : Comment corriger

### Priorité moyenne

- **`path/to/file.ts:88`** — Brève description
  > Recommandation : Comment corriger (le cas échéant)

Si la revue n'a trouvé aucun problème après filtrage, déclarez simplement : "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 correctifs nécessitant une implémentation manuelle
• Basse : Ignorées silencieusement (probablement faux positifs, manque de contexte, ergotages ou suggestions insignifiantes)

Gestion des commentaires mal positionnés :

Quand start_line et end_line sont tous les deux 0, le commentaire n'a pas pu 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 en fonction du contexte du commentaire
4. Appliquer le correctif ou la suggestion au bon endroit

Règles de revue personnalisées

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

1. Drapeau --rule <path> (priorité la plus haute)
2. <repo>/.opencodereview/rule.json
3. ~/.opencodereview/rule.json
4. Valeurs par défaut système intégrées (priorité la plus basse)

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

Format du fichier de règles :

{
  "rules": [
    {
      "path": "**/*.java",
      "rule": "All new methods must validate required parameters for null",
      "merge_system_rule": true
    },
    {
      "path": "**/*mapper*.xml",
      "rule": "Check SQL for injection risks and missing closing tags"
    }
  ]
}

Pour voir un aperçu de la règle qui s'applique à un fichier avant de revuer :

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 compte — ocr review opère sur le repo Git du répertoire courant. Utiliser --repo /path/to/repo pour exécuter depuis ailleurs.
• Les fichiers untracked sont revus en mode workspace — l'exécution de ocr review inclut les changements staged, unstaged et untracked. Stagez sélectivement si vous voulez une portée plus restreinte.
• Les gros diffs peuvent atteindre les limites de tokens — les fichiers avec des diffs très volumineux peuvent être tronqués. Le MAX_TOKENS par défaut est 58888 par requête.
• La phase de planning se déclenche à 50 lignes — les diffs dépassant 50 lignes changées exécutent une phase d'analyse des risques supplémentaire avant la revue principale. Cela ajoute de la latence mais améliore la qualité.
• Ne pas passer --audience human — cela diffuse l'UI de progression qui pollue la sortie. Toujours utiliser --audience agent.
• La langue des commentaires suit la configuration — définissez la config 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érifiez le succès en controlant :

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érifiez les avertissements stderr pour les 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