Que fait article-review-panel ?
Version : 1.0
Produit jusqu'à trois fichiers de révision à côté d'un brouillon d'article technique, chacun rédigé par un personnage expert différent : un expert du domaine (exactitude des affirmations techniques), un éditeur (structure, clarté, audience, adéquation à la plateforme) et un statisticien (si les données soutiennent les conclusions). Chaque fichier utilise le même format Bon / Erroné / Nécessite plus d'explications afin que l'auteur puisse agir dessus. La source de vérité est constituée des données brutes, scripts et notes présents dans le dossier du brouillon, jamais du résumé qu'en fait le brouillon lui-même.
Règles critiques (à lire en premier)
- Lisez l'intégralité du dossier avant d'écrire un mot. Le brouillon, ses notes, les brouillons de premier commentaire, les articles frères, les scripts de benchmark et les fichiers de résultats bruts. Une révision qui ne lit que le brouillon ne peut pas détecter un brouillon qui cite mal ses données.
- Vérifiez chaque nombre mentionné par le brouillon. Recalculez-le à partir des données brutes ou
marquez-le comme non vérifié. Citez le fichier et la valeur :
results_gc.json: 173 → 166 MB. - « Erroné » signifie erroné, pas une préférence de style. Une affirmation sans preuve dans le dossier, un nombre qui contredit les données, une conclusion que l'analyse ne soutient pas, ou une phrase que la plateforme rendra cassée. Les goûts personnels vont sous « Nécessite plus d'explications ».
- Chaque élément « Erroné » est accompagné d'une correction concrète : un texte de remplacement, la commande qui testerait l'affirmation, ou la suppression.
- Chaque expert reste dans son domaine. Référencez les autres fichiers (« l'exactitude technique
se trouve dans
REVIEW-…-JVM.md») au lieu de répéter leurs conclusions. - Expertise statistique : analysez, ne regardez pas. Exécutez
scripts/paired_stats.pysur les données brutes. Ne concluez jamais « bruit » ou « aucun effet » sans un intervalle de confiance et un effet minimum détectable. - Respectez le budget de longueur. Comptez les caractères du brouillon par rapport à la limite de la plateforme (LinkedIn : 3 000) et dites ce que chaque ajout doit coûter.
- Signalez la confidentialité. Noms internes, identifiants de tickets, hôtes, clients ou chiffres de production : dites qu'ils nécessitent une validation Com/Service Juridique. Ne placez jamais de données restreintes (membre, réclamations, santé, identifiants) dans une révision ou une recherche.
Tableau « Lire d'abord »
| Source | Chemin | Que faut-il en extraire |
|---|---|---|
| Le brouillon | le fichier nommé par l'utilisateur | Chaque affirmation factuelle, chaque nombre, chaque commande, l'accroche (premiers ~210 caractères), l'appel à l'action, nombre de caractères |
| Notes de l'auteur | fichiers *.md frères (notes de données, premier commentaire, articles frères) | Les réserves et corrections de l'auteur que le brouillon a omises ; texte répété entre articles frères |
| Scripts de benchmark | *.py, *.sh, Dockerfiles dans le dossier | Ordre d'exécution (aléatoire ? en blocs ?), ce que chaque métrique mesure réellement et quand elle est échantillonnée |
| Résultats bruts | *.json, *.csv, *.log | Les nombres à recalculer ; taille de bloc pour l'appariement |
| Guide d'expertise domaine | references/domain-lens.md | La checklist du domaine ; la section JVM est le domaine travaillé |
| Guide d'expertise éditoriale | references/editorial-lens.md | Règles de la plateforme (Markdown LinkedIn, pli, limite) et la checklist structure |
| Guide d'expertise statistique | references/statistics-lens.md | La recette d'analyse et les signaux méthodologiques standard |
| Leçons passées | ~/.claude/skill-memory/article-review-panel.md (à créer s'il manque) | Retours des exécutions précédentes ; appliquez-les avant de rédiger |
Flux de travail
Phase 1. Inventaire
Listez le dossier. Lisez le brouillon et chaque note, script et fichier de résultat. Comptez les caractères du brouillon. Construisez une liste d'affirmations : chaque nombre et chaque assertion factuelle, avec sa ligne.
Phase 2. Choisir les expertises
Par défaut, les trois. Exécutez uniquement l'expertise nommée par l'utilisateur (« agis en statisticien »). Pour l'expertise domaine, prenez le domaine de l'utilisateur (« JVM », « Kubernetes », « Postgres ») ou déduisez-le du brouillon et dites lequel vous avez choisi.
Phase 3. Vérifier
Recalculez chaque affirmation à partir des données brutes. Pour les benchmarks, exécutez :
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> --list
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> \
--block-size <variants per round> --pair <A>:<B> [--pair ...] --metrics <m1,m2>
Cherchez dans le dossier des preuves pour chaque affirmation qualitative (« ne démarre pas », « ignoré silencieusement »). Pas de preuve signifie « Erroné : non testé », avec la commande de test.
Phase 4. Écrire un fichier par expertise
Écrivez dans le dossier du brouillon, nommé REVIEW-<NOM-DU-BROUILLON>-<EXPERTISE>.md avec EXPERTISE en
JVM/<DOMAINE>, EDITORIAL, STATISTIQUES. Suivez le format de sortie ci-dessous et
le guide d'expertise dans references/.
Phase 5. Noter et rapporter
Exécutez evals.md via un sous-agent évaluateur avec un contexte propre (donnez-lui uniquement
evals.md, le brouillon et les fichiers de révision). Corrigez chaque échec et réévaluez.
Ensuite, rapportez à l'utilisateur : une ligne par expertise avec l'élément « Erroné » le plus
important, et les chemins. Ajoutez toute nouvelle leçon donnée par l'utilisateur à
~/.claude/skill-memory/article-review-panel.md (la plus récente en premier ; créez-le s'il manque).
Format de sortie
# Révision de <fichier brouillon> : <nom de l'expertise>
Point de vue du relecteur : <persona>. <Ce qui a été vérifié par rapport à quoi.>
## Verdict
<2–4 phrases : publiable ou non, le point le plus fort, le nombre de correctifs obligatoires.>
## Bon
- **<Affirmation en gras>.** <Preuve, avec fichier et nombre.>
## Erroné : <à corriger avant publication | les conclusions ne découlent pas des données>
### 1. <Énoncé d'une ligne du défaut>
<Ce que dit le brouillon, ce que disent les données, pourquoi c'est important.>
Correction suggérée : <texte, commande ou suppression>.
## Nécessite plus d'explications
### N. <Sujet>
<Ce qui manque et une ligne suggérée.>
## Points mineurs
- **<Étiquette>:** <une ou deux phrases>.
Le fichier statistiques ajoute une section Comment l'analyse a été réalisée après l'en-tête, et une liste Recommandations de nouvelles exécutions à la fin.
Exemple travaillé
Entrée :
agis en tant qu'ingénieur JVM expérimenté et révise POST-1-DEFAULT-CDS-EN.md dans ~/aot-exploration/linkedin-cds, puis en tant qu'éditeur, puis en tant que statisticien
Étapes suivies par Claude :
- Lit le post,
DADOS-POST.md, le brouillon de premier commentaire, le post 2,bench*.pyetresults*.json. Compte 2 623 des 3 000 caractères. - Expertise domaine : confirme que ZGC mappe
classes_nocoops.jsa; ne trouve aucun fichier mentionnantAOTCache, donc l'affirmation « la JVM ne démarre même pas » est marquée Erroné avec une commande de test. - Expertise éditoriale : l'accroche de 87 caractères tient au-dessus du pli ; quatre commandes entourées de backticks seront rendues littéralement sur LinkedIn (Erroné).
- Expertise statistique : voit
random.shuffle(order)dans la boucle des rounds, donc exécutepaired_stats.py --block-size 12. Le décalage groupé est de −2,1 % [−3,2 %, −1,5 %], donc « c'est du bruit » est Erroné. Le « +2 % » provenait d'une comparaison de médianes non appariées. - Écrit trois fichiers
REVIEW-POST-1-*.md, les évalue avecevals.md, rapporte.
Sortie (fichier statistiques, extrait) :
### 1. « Temps de démarrage : −4 % à +2 %. C'est du bruit. » n'est pas ce que disent les données
| Configuration | Décalage apparié | IC 95 % | Plus rapide avec CDS | p exacte |
|---|---|---|---|---|
| Série | −69 ms | [−104, −49] | **10/10** | **0,002** |
| **Groupé, 50 paires** | **−2,1 %** | **[−3,2 %, −1,5 %]** | **39/50** | n/d |
La conclusion correcte est « un effet réel mais faible : environ 2 %, soit 20 à 70 ms »,
pas « bruit ».
La sortie complète des trois fichiers de cette exécution est résumée dans references/examples.md.
Fichiers de référence
references/domain-lens.md: checklist de l'expert domaine ; domaine travaillé JVM/CDS/AOT.references/editorial-lens.md: checklist de l'éditeur et règles de la plateforme LinkedIn.references/statistics-lens.md: recette d'analyse et signaux méthodologiques standard.references/examples.md: l'exécution sur le post CDS, constat par constat.evals.md: contrôles réussite/échec. Exécutez via un évaluateur à contexte propre avant de remettre.~/.claude/skill-memory/article-review-panel.md: journal des leçons, la plus récente en premier, privé à cette machine (voirmemory.md). Lisez-le avant de rédiger.
Scripts
scripts/paired_stats.py: analyse appariée A/B utilisant uniquement la bibliothèque standard (Wilcoxon exact, permutation de signe, Hodges-Lehmann, IC bootstrap, MDE, décalage groupé, et contrôles de dérive et d'ordre).--listaffiche les variantes et métriques ;--self-testexécute 8 contrôles.
Quand NE PAS utiliser cette compétence
- Réviser du code, une branche ou une PR. Utilisez diegourban:gh-pr-review, diegourban:branch-review ou /code-review.
- Vérifier le comportement réel d'une base de code. Utilisez diegourban:fact-checker.
- Écrire ou réécrire le post lui-même. Ayez une conversation directe ; cette compétence ne fait que réviser.
- Un deck ou des diapositives. Révisez le contenu avec cette compétence uniquement si l'utilisateur le demande ; construisez avec create-slide-deck.