Was macht Artikel-Review-Panel?
Version: 1.0
Erzeugt bis zu drei Review-Dateien neben einem technischen Entwurf, jeweils verfasst von einer anderen Experten-Persona: einem Domain-Experten (Korrektheit der technischen Behauptungen), einem Redakteur (Struktur, Klarheit, Zielgruppe, Plattform-Eignung) und einem Statistiker (ob die Daten die Schlussfolgerungen stützen). Jede Datei verwendet die gleiche Gliederung aus Gut / Falsch / Erklärungsbedarf, sodass der Autor direkt handeln kann. Die Wahrheitsquelle sind die Rohdaten, Skripte und Notizen im Ordner des Entwurfs, niemals dessen eigene Zusammenfassung.
Kritische Regeln (zuerst lesen)
- Lies den gesamten Ordner, bevor du ein Wort schreibst. Den Entwurf, seine Notizen, erste Kommentarentwürfe, Schwesterbeiträge, Benchmark-Skripte und Roh-Ergebnisdateien. Eine Überprüfung, die nur den Entwurf liest, kann nicht erkennen, dass der Entwurf seine Daten falsch zitiert.
- Überprüfe jede Zahl, die der Entwurf nennt. Berechne sie aus den Rohdaten neu oder markiere sie als nicht verifiziert. Zitiere Datei und Wert:
results_gc.json: 173 → 166 MB. - „Falsch“ bedeutet falsch, nicht eine Stilpräferenz. Eine Behauptung ohne Beleg im Ordner, eine Zahl, die den Daten widerspricht, eine Schlussfolgerung, die die Analyse nicht stützt, oder ein Satz, den die Plattform fehlerhaft darstellt. Geschmacksfragen gehören unter „Erklärungsbedarf“.
- Jeder „Falsch“-Punkt enthält eine konkrete Korrektur: einen Ersatztext, den Befehl, der die Behauptung testen würde, oder die Streichung.
- Jede Linse bleibt in ihrem Bereich. Verweise auf die anderen Dateien („Technische Korrektheit in
REVIEW-…-JVM.md“), anstatt deren Ergebnisse zu wiederholen. - Statistiker-Linse: analysieren, nicht schätzen. Führe
scripts/paired_stats.pyauf den Rohdaten aus. Ziehe nie „Rauschen“ oder „kein Effekt“ ohne Konfidenzintervall und kleinste nachweisbare Effektgröße. - Respektiere das Längenbudget. Zähle die Zeichen des Entwurfs gegen das Plattformlimit (LinkedIn: 3.000) und sage, was jede Hinzufügung kosten muss.
- Kennzeichne Vertrauliches. Interne Namen, Ticket-ID, Hosts, Kunden- oder Produktionszahlen: sage, dass sie eine Freigabe durch Kommunikation/Recht benötigen. Gib niemals geschützte Daten (Mitglieder, Ansprüche, Gesundheitsdaten, Zugangsdaten) in ein Review oder eine Suche.
Tabelle „Zuerst lesen“
| Quelle | Pfad | Was zu extrahieren ist |
|---|---|---|
| Der Entwurf | die vom Benutzer genannte Datei | Jede Faktenbehauptung, jede Zahl, jeder Befehl, der Aufhänger (erste ~210 Zeichen), der Call-to-Action, Zeichenanzahl |
| Autorennotizen | Geschwister-*.md-Dateien (Datennotizen, erster Kommentar, Schwesterbeiträge) | Die eigenen Einschränkungen und Korrekturen des Autors, die der Entwurf weggelassen hat; wiederholter Text zwischen Schwesterbeiträgen |
| Benchmark-Skripte | *.py, *.sh, Dockerfiles im Ordner | Ausführungsreihenfolge (randomisiert? blockweise?), was jede Metrik wirklich misst und wann sie erfasst wird |
| Roh-Ergebnisse | *.json, *.csv, *.log | Die neu zu berechnenden Zahlen; Blockgröße für Paarungen |
| Leitfaden Domain-Linse | references/domain-lens.md | Die Domain-Checkliste; der JVM-Abschnitt ist die ausgearbeitete Domain |
| Leitfaden Redaktions-Linse | references/editorial-lens.md | Plattformregeln (LinkedIn-Markdown, Fold, Limit) und die Struktur-Checkliste |
| Leitfaden Statistik-Linse | references/statistics-lens.md | Das Analyse-Rezept und die methodischen Standard-Flaggen |
| Bisherige Lektionen | ~/.claude/skill-memory/article-review-panel.md (anlegen, falls nicht vorhanden) | Feedback aus früheren Durchläufen; vor dem Verfassen anwenden |
Arbeitsablauf
Phase 1. Bestandsaufnahme
Liste den Ordner auf. Lies den Entwurf und jede Notiz-, Skript- und Ergebnisdatei. Zähle die Zeichen des Entwurfs. Erstelle eine Behauptungsliste: jede Zahl und jede Faktenbehauptung mit ihrer Zeile.
Phase 2. Linsen auswählen
Standardmäßig alle drei. Führe nur die vom Benutzer genannte Linse aus („verhalte dich wie ein Statistiker“). Für die Domain-Linse übernimm das Fachgebiet vom Benutzer („JVM“, „Kubernetes“, „Postgres“) oder leite es aus dem Entwurf ab und nenne, welches du gewählt hast.
Phase 3. Verifizieren
Berechne jede Behauptung aus den Rohdaten neu. Für Benchmarks führe aus:
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 <varianten pro runde> --pair <A>:<B> [--pair ...] --metrics <m1,m2>
Durchsuche den Ordner nach Belegen für jede qualitative Behauptung („startet nicht“, „wird stillschweigend ignoriert“). Kein Beleg bedeutet „Falsch: nicht getestet“, mit dem Testbefehl.
Phase 4. Eine Datei pro Linse schreiben
Schreibe in den Ordner des Entwurfs, benannt REVIEW-<ENTWURFSSTAMM>-<LINSE>.md mit LINSE in JVM/<DOMAIN>, EDITORIAL, STATISTICS. Folge dem untenstehenden Ausgabeformat und dem Linsen-Leitfaden in references/.
Phase 5. Bewerten und melden
Führe evals.md über einen Bewertungs-Subagenten mit sauberem Kontext aus (gib ihm nur evals.md, den Entwurf und die Review-Dateien). Behebe jeden Fehler und bewerte erneut. Melde dann dem Benutzer: eine Zeile pro Linse mit dem wichtigsten „Falsch“-Punkt und den Pfaden. Füge jede neue Lektion, die der Benutzer gibt, zu ~/.claude/skill-memory/article-review-panel.md hinzu (neueste zuerst; anlegen, falls nicht vorhanden).
Ausgabeformat
# Review von <Entwurfsdatei>: <Linsenname>
Prüfperspektive: <Persona>. <Was gegen was geprüft wurde.>
## Fazit
<2–4 Sätze: veröffentlichungsfähig oder nicht, das Stärkste, die Anzahl der zwingenden Korrekturen.>
## Gut
- **<Fette Behauptung>.** <Beleg, mit Datei und Zahl.>
## Falsch: <muss vor Veröffentlichung korrigiert werden | die Schlussfolgerungen folgen nicht aus den Daten>
### 1. <Einzeilige Beschreibung des Fehlers>
<Was der Entwurf sagt, was die Daten sagen, warum es wichtig ist.>
Vorschlag zur Korrektur: <Formulierung, Befehl oder Streichung.>
## Erklärungsbedarf
### N. <Thema>
<Was fehlt und ein Vorschlag für eine Zeile.>
## Kleinere Punkte
- **<Label>:** <ein oder zwei Sätze.>
Die Statistikdatei fügt einen Abschnitt Wie die Analyse durchgeführt wurde nach der Kopfzeile und eine Liste Empfohlene Wiederholungen am Ende hinzu.
Ausgearbeitetes Beispiel
Eingabe:
verhalte dich wie ein erfahrener JVM-Ingenieur und überprüfe POST-1-DEFAULT-CDS-EN.md in ~/aot-exploration/linkedin-cds, dann als Redakteur, dann als Statistiker
Schritte, die Claude unternimmt:
- Liest den Beitrag,
DADOS-POST.md, den ersten Kommentarentwurf, Beitrag 2,bench*.pyundresults*.json. Zählt 2.623 von 3.000 Zeichen. - Domain-Linse: bestätigt, dass ZGC
classes_nocoops.jsamapped; findet keine Datei, dieAOTCacheerwähnt, daher wird die Behauptung „JVM startet nicht einmal“ als Falsch mit einem Testbefehl gekennzeichnet. - Redaktions-Linse: der 87 Zeichen lange Aufhänger passt above the fold; vier Backtick-Befehle werden auf LinkedIn wörtlich dargestellt (Falsch).
- Statistik-Linse: sieht
random.shuffle(order)innerhalb der Runden-Schleife, führt daherpaired_stats.py --block-size 12aus. Der gepoolte Shift beträgt −2,1 % [−3,2 %, −1,5 %], also ist „das ist Rauschen“ falsch. Die „+2 %“ kamen aus dem Vergleich ungepaarter Mediane. - Schreibt drei
REVIEW-POST-1-*.md-Dateien, bewertet sie mitevals.md, meldet.
Ausgabe (Statistikdatei, Auszug):
### 1. „Startzeit: −4 % bis +2 %. Das ist Rauschen.“ ist nicht, was die Daten sagen
| Setup | Gepaarter Shift | 95 %-KI | Schneller mit CDS | Exakter p-Wert |
|---|---|---|---|---|
| Serial | −69 ms | [−104, −49] | **10/10** | **0,002** |
| **Gepoolt, 50 Paare** | **−2,1 %** | **[−3,2 %, −1,5 %]** | **39/50** | n. v. |
Die korrekte Schlussfolgerung ist „ein echter, aber kleiner Effekt: etwa 2 % oder 20–70 ms“, nicht „Rauschen“.
Die vollständige Drei-Dateien-Ausgabe dieses Durchlaufs ist in references/examples.md zusammengefasst.
Referenzdateien
references/domain-lens.md: Domain-Experten-Checkliste; ausgearbeitete Domain JVM/CDS/AOT.references/editorial-lens.md: Redakteurs-Checkliste und LinkedIn-Plattformregeln.references/statistics-lens.md: Analyse-Rezept und methodische Standard-Flaggen.references/examples.md: Der CDS-Beitragsdurchlauf, Punkt für Punkt.evals.md: Bestanden/nicht bestanden-Prüfungen. Vor der Auslieferung mit einem bereinigten Kontext-Bewerter durchführen.~/.claude/skill-memory/article-review-panel.md: Lektionsprotokoll, neueste zuerst, privat auf diesem Rechner (siehememory.md). Vor dem Verfassen lesen.
Skripte
scripts/paired_stats.py: Nur auf Stdlib basierende gepaarte A/B-Analyse (exakter Wilcoxon, Vorzeichenwechsel, Hodges-Lehmann, Bootstrap-KI, MDE, gepoolter Shift, Drift- und Reihenfolgeprüfungen).--listzeigt Varianten und Metriken;--self-testführt 8 Prüfungen durch.
Wann dieser Skill NICHT verwendet werden soll
- Überprüfung von Code, einem Branch oder einem PR. Verwende diegourban:gh-pr-review, diegourban:branch-review oder /code-review.
- Überprüfung, wie eine Codebase wirklich funktioniert. Verwende diegourban:fact-checker.
- Schreiben oder Umschreiben des Beitrags selbst. Führe ein direktes Gespräch; dieser Skill überprüft nur.
- Ein Deck oder Folien. Überprüfe den Inhalt mit diesem Skill nur, wenn der Benutzer darum bittet; erstelle mit create-slide-deck.