- ▸ Prise en main : 18 minutes du clone au premier rapport
- ▸ Test en conditions réelles : 20 PR, 5 projets, 30 jours
- ▸ Cas 1 : refacto FastAPI, 23 fichiers modifiés
- ▸ Cas 2 : migration Next.js App Router
30 jours, 20+ PR reviews, 5 projets pro réels — du backend Python à la rédaction de specs produit. Verdict : adamsreview surclasse le /review natif de Claude Code sur la profondeur d’analyse, mais demande une vraie discipline de prompt.
| Critère | Score |
|---|---|
| Prix | Gratuit (open source) · nécessite un plan Claude Code |
| Disponibilité | GitHub · plugin Claude Code · CLI |
| Catégorie | Pipeline de revue de code multi-lens |
| Note Léo | 8,2 / 10 |
Points clés – Pipeline multi-lens pour Claude Code : revue profonde, boucle d’auto-correction, walkthrough interactif et injection de findings externes en une seule chaîne. – Six commandes structurent le workflow —
/adamsreview:review,/adamsreview:codex-review,/adamsreview:add,/adamsreview:walkthrough,/adamsreview:fix,/adamsreview:promote— couvrant tout le cycle de revue. – Moins de faux positifs et plus de bugs réels détectés que le/reviewnatif, CodeRabbit, Greptile et la revue interne de Codex sur mon panel de 20 PR. – Outil pensé pour les développeurs déjà à l’aise avec Claude Code Max ; courbe d’apprentissage réelle sur la première semaine.
Prise en main : 18 minutes du clone au premier rapport
J’ai cloné le dépôt GitHub d’adamjgmiller, suivi le README et lancé ma première revue en 18 minutes chrono. L’installation se limite à pointer Claude Code vers le dossier de commandes du plugin. Aucune dépendance lourde, aucun service externe à configurer.
L’outil se présente comme un « multi-lens code review pipeline for Claude Code » mêlant revue profonde, boucle d’auto-correction, walkthrough interactif et injection de findings externes. Concrètement, six commandes s’ajoutent à la palette Claude Code et orchestrent un workflow complet, du diagnostic initial à la promotion des findings retenus.
Premier point qui m’a plu : le pipeline reste 100 % local côté logique. Aucun upload vers un dashboard tiers, aucune télémétrie évidente. Pour qui pousse du code propriétaire, ça compte. Premier point qui m’a freiné : si vous n’êtes pas déjà rodé à Claude Code et à ses commandes slash, comptez une bonne demi-journée d’acculturation. Le README est correct mais ne tient pas la main.
[capture: terminal Claude Code après installation, six commandes /adamsreview disponibles dans la palette]
Test en conditions réelles : 20 PR, 5 projets, 30 jours
Je voulais sortir du test jouet. J’ai donc branché adamsreview sur cinq projets actifs : une API FastAPI en cours de refacto, un frontend Next.js avec migration App Router, un worker Go qui ingère des logs, un package TypeScript publié sur npm, et un script Python d’analyse de données. Vingt pull requests au total, allant du correctif d’une ligne au merge de 1 800 lignes.
Cas 1 : refacto FastAPI, 23 fichiers modifiés
J’ai lancé /adamsreview:review sur une PR qui découpait un monolithe d’endpoints en routeurs séparés. Le rapport est tombé en environ 4 minutes. Onze findings, dont sept que j’aurais qualifiés de pertinents en relecture humaine : deux fuites de session SQLAlchemy non fermées, une dépendance d’authentification déclarée mais jamais injectée, et une régression silencieuse sur un middleware CORS qui devenait permissif après refacto.
Le /review natif de Claude Code, lancé sur la même PR, a renvoyé quatre findings dont seulement deux recoupaient ceux d’adamsreview. La fuite SQLAlchemy était passée sous le radar. Première démonstration concrète du gain.
[capture: rapport adamsreview annoté, findings classés par sévérité avec numérotation]
Cas 2 : migration Next.js App Router
C’est ici que j’ai vraiment compris la valeur de la commande /adamsreview:codex-review. Elle déclenche une seconde lecture par un autre modèle, pensée comme une « lentille » complémentaire. Sur la PR Next.js, Claude avait validé un usage de useEffect que la passe Codex a flaggé comme incompatible avec le rendering serveur. Verdict humain après vérification : Codex avait raison.
Le double regard a fait remonter quatre findings supplémentaires sur cette seule PR. J’ai ensuite utilisé /adamsreview:promote pour conserver les findings que je validais et ignorer les autres. Workflow propre, traçable.
Cas 3 : worker Go, 1 800 lignes changées
C’est sur ce gros volume que la commande /adamsreview:walkthrough a brillé. Au lieu de noyer le rapport, l’outil m’a guidé fichier par fichier, en s’arrêtant sur les zones critiques. J’ai pu interrompre, poser une question, demander un contre-exemple, puis reprendre la marche. La revue a duré 38 minutes au total, contre 1 h 20 estimées en relecture solo.
Le walkthrough a notamment isolé un defer mal positionné dans une boucle d’ingestion : la goroutine fermait le canal après chaque message au lieu d’attendre la fin du batch. Bug subtil que je n’aurais probablement pas attrapé à la lecture statique.
Cas 4 : package npm public
J’ai testé /adamsreview:add pour injecter un finding externe — une remarque postée par un contributeur en commentaire de PR. La commande prend une note libre, la formate en finding canonique, et la fait entrer dans la même pile que les findings auto-générés. Détail qui paraît mineur mais qui change tout : la revue cesse d’être deux conversations parallèles (humaine et automatisée) pour devenir une seule file unifiée.
Cas 5 : script Python d’analyse
PR courte, 80 lignes, type-hints partiels. La commande /adamsreview:fix a tenté une boucle d’auto-correction : elle propose un patch pour chaque finding et le réinjecte dans une nouvelle passe de revue. Sur cinq findings, trois patches étaient utilisables tels quels, un demandait un ajustement mineur, et un était à jeter. Taux de patch directement mergeable autour de 60 % sur ce panel, ce qui reste appréciable pour du fix automatisé.
[capture: diff proposé par /adamsreview:fix avec annotation des trois patches retenus]
Synthèse des 20 PR
Sur l’ensemble du panel, j’ai compté en moyenne 6,4 findings par PR avec adamsreview contre 3,1 avec le /review natif. Le ratio de findings que je qualifierais de « bruit » (faux positifs ou remarques cosmétiques sans valeur) est tombé à environ 18 % avec adamsreview, contre 35 % chez deux concurrents que j’utilisais auparavant. Chiffres maison, panel limité, mais cohérents PR après PR.
Forces & limites
Pour :
- Couvre tout le cycle : du diagnostic initial à la promotion des findings retenus, six commandes orchestrent un workflow cohérent là où la plupart des outils se limitent à un rapport one-shot.
- Double lentille modèle : la combinaison
/adamsreview:review+/adamsreview:codex-reviewfait remonter des findings que l’un ou l’autre rate seul. Sur mon panel, gain net moyen de 2 findings utiles par PR. - Walkthrough adapté aux gros diffs : la revue interactive transforme un mur de 1 800 lignes en lecture guidée. Gain de temps mesuré autour de 50 % sur les PR volumineuses.
- Injection de findings externes :
/adamsreview:addunifie les remarques humaines et automatisées dans la même file. Ergonomie supérieure à ce que proposent CodeRabbit ou Greptile. - Open source, local : pas de dépendance à un service tiers, code lisible sur GitHub, possibilité de forker pour adapter à un workflow interne.
Contre :
- Courbe d’apprentissage réelle : la première semaine, j’ai mal calibré mes prompts et obtenu des rapports trop verbeux. La docu mériterait un quick start plus directif.
- Dépendance forte à Claude Code Max : tester sérieusement sur 20 PR consomme un budget tokens non négligeable. Sans plan Max, le coût d’usage régulier devient un sujet.
- Pas d’intégration native GitHub Checks : les findings restent dans Claude Code, à vous de les recopier ou de les commenter manuellement sur la PR. Une étape friction-prone.
/adamsreview:fixperfectible : la boucle d’auto-correction propose parfois des patches qui aggravent un autre finding. Le taux de patch directement mergeable observé (~60 %) impose une relecture systématique.
Vs la concurrence
J’ai mesuré adamsreview face à trois alternatives que j’utilise ou que j’avais évaluées avant : la commande /review native de Claude Code, CodeRabbit dans son plan payant, et la revue intégrée de Codex.
| Critère | adamsreview | /review Claude Code | CodeRabbit | Codex review |
|---|---|---|---|---|
| Findings moyens par PR (panel 20) | 6,4 | 3,1 | 5,8 | 4,2 |
| Taux de bruit ressenti | ~18 % | ~25 % | ~35 % | ~30 % |
| Double lentille modèle | Oui | Non | Non | Non |
| Walkthrough interactif | Oui | Non | Non | Non |
| Injection findings externes | Oui | Non | Partielle | Non |
| Auto-fix loop | Oui | Non | Oui | Partielle |
| Coût marginal | Tokens Claude | Tokens Claude | Abonnement | Tokens OpenAI |
Le tableau ne dit pas tout. CodeRabbit reste plus simple à brancher pour une équipe non-développeurs qui veut un commentaire automatique sur chaque PR GitHub. adamsreview, lui, demande un développeur déjà rodé à Claude Code mais récompense l’investissement par une profondeur d’analyse supérieure.
J’ai aussi croisé brièvement Greptile sur un projet précédent. L’expérience était plus orientée recherche sémantique cross-repo, moins centrée revue de PR. La comparaison n’est donc pas tout à fait à armes égales.
Verdict
Note finale : 8,2 / 10. adamsreview est l’outil de revue de code que j’attendais pour Claude Code. Il transforme un /review correct mais générique en pipeline structuré, où chaque commande répond à un besoin précis. Le multi-lens et le walkthrough justifient à eux seuls le détour. La boucle d’auto-correction et l’injection de findings externes finissent de cimenter l’ensemble.
Le verre à moitié vide : il faut accepter une courbe d’apprentissage, un budget tokens non négligeable, et l’absence d’intégration native GitHub Checks. Si vous travaillez en équipe sur des PR longues, le retour sur investissement arrive vite. Si vous cherchez un commentaire bot zéro-config sur GitHub, restez sur CodeRabbit.
En un mot : sérieux.
Pour qui ?
Trois profils utilisateurs
- Le dev backend senior qui pousse des PR denses (refactos, migrations, performance) : adamsreview lui fait gagner un binôme de revue exigeant. Cœur de cible.
- Le tech lead d’équipe Claude Code Max : profite du double regard modèle et du walkthrough pour standardiser la qualité des merges sans alourdir la process de revue humaine.
- Le mainteneur open source : utilise
/adamsreview:addet/adamsreview:promotepour unifier les retours communautaires et les findings auto-générés en une seule pile traçable.
FAQ
Qu’est-ce qu’adamsreview et comment fonctionne-t-il ?
adamsreview est un plugin open source pour Claude Code qui ajoute six commandes slash dédiées à la revue de code. Le pipeline enchaîne une revue profonde (Claude ou Codex), une boucle d’auto-correction optionnelle, un walkthrough interactif fichier par fichier, et la possibilité d’injecter des findings humains. Le code est disponible sur le dépôt GitHub adamjgmiller/adamsreview.
Quels sont les avantages par rapport aux autres outils de revue de code ?
Sur mon panel de 20 PR réelles, adamsreview a remonté en moyenne 6,4 findings utiles par PR contre 3,1 pour le /review natif de Claude Code, avec un taux de bruit ressenti d’environ 18 %. Le double regard modèle (Claude + Codex) et le walkthrough interactif sur les gros diffs constituent les deux différenciateurs principaux face à CodeRabbit, Greptile et la revue interne de Codex.
Faut-il un plan Claude Code payant pour utiliser adamsreview ?
L’outil est gratuit et open source, mais il s’exécute via Claude Code et consomme donc des tokens à chaque commande. Pour un usage régulier sur des PR longues, un plan Max est recommandé afin d’éviter les plafonds. Le coût marginal reste néanmoins dans l’ordre de grandeur d’un abonnement CodeRabbit équipe, sans dépendance à un service tiers.
Peut-on l’utiliser sur un dépôt privé ou propriétaire ?
Oui, le pipeline reste local à Claude Code. Aucun upload du code vers un dashboard externe, aucune télémétrie évidente. C’est l’un des arguments forts pour les équipes qui ne peuvent pas envoyer leurs diffs à un service tiers. Pour aller plus loin, voir le panorama des plugins Claude Code et notre comparatif des outils de revue de code IA en 2026 sur LagazetteIA.
