Deep-Review-Äquivalent: Aufteilung → parallele Verifikation → Falsifikation → Synthese
Dieses Skill repliziert die öffentlich bekannte Architektur von Googles Deep Review (dem Paper Assistant Tool, PAT, das auf STOC, ICML, NeurIPS, ICLR für Autoren getestet wurde) mit Claude-Subagenten. Ziel ist es, Autoren vor der Einreichung auf echte Fehler hinzuweisen (Beweislücken, Rechenfehler, numerische Inkonsistenzen, Behauptungen, die stärker sind als die Belege, fehlende Vergleiche) – und diese nachvollziehbar und priorisiert darzustellen. Es werden keine Punkte vergeben.
Überblick über die Schritte und ihre Begründung
| Schritt | Verantwortlich | Begründung |
|---|---|---|
| 1. Aufnahme | Skript | Sowohl Text als auch Seitenbilder werden benötigt. Extraktionsbedingte Verzerrungen in Formeln und Tabellen werden durch Bilder kompensiert |
| 2. Segmentierung & Budgetzuweisung | Du (der Orchestrator) | Konzentration der Rechenleistung auf dichte Beweisabschnitte; Einleitung und verwandte Arbeiten werden oberflächlicher behandelt |
| 3. Parallele Tiefenprüfung | Subagenten (Segment × Perspektive, Lens) | Begrenzung des Kontextes pro Agent für tiefes Lesen; unabhängige Perspektiven erhöhen die Abdeckung |
| 4. Abgleich & Deduplizierung | Skript | Mechanische Prüfung, ob wörtliche Zitate tatsächlich im Papier existieren; Zusammenfassen identischer Probleme |
| 5. Falsifikationsprüfung | Subagent | Fehlersuche führt mit zunehmenden Läufen zu mehr Fehldetektionen; eine skeptische, unabhängige Perspektive stellt die Genauigkeit wieder her |
| 6. Synthese | Subagent | Bestimmung des Schweregrads, Priorisierung, Längenkontrolle, Overall Feedback |
| 7. Berichterstellung | Skript → Du (Orch.) | Erstellung von report.md / report.html; prägnante Zusammenfassung der wichtigsten Punkte |
Die wissenschaftliche Fundierung (welche Erkenntnisse aus welcher Literatur stammen) ist in references/research_basis.md dokumentiert.
Im Folgenden bezeichnet <skill_dir> das Verzeichnis, in dem diese SKILL.md liegt, <ws> das Arbeitsverzeichnis, und deep_review.py ist die Kurzform für python <skill_dir>/scripts/deep_review.py. Falls python nicht verfügbar ist, wird python3 verwendet.
0. Initialisierung: Tiefe und Fokus festlegen
- Identifiziere das zu prüfende Dokument. PDF ist am besten (ermöglicht Seitenbilder). Markdown-, TXT- und TeX-Dateien werden ebenfalls akzeptiert, erlauben aber keine Überprüfung von Abbildungen und Formeln mittels Bildern. Falls nur LaTeX-Quellen vorliegen und das Projekt gebaut werden kann, erstelle ein PDF und verwende dieses.
- Frage Tiefe und Fokus mittels eines Fragewerkzeugs (z.B.
AskUserQuestion) in einer einzigen Abfrage ab. Falls dies nicht verfügbar ist, stelle die Fragen im Chat. Frage nicht nach Informationen, die bereits aus der Startnachricht hervorgehen. Bei Anweisungen wie „Mach einfach“ oder „Überlass mir“ beginne mit Standard-Tiefe und ohne Fokus.- Frage 1 „Tiefe“:
Standard (empfohlen)/Quick/Deep(Ergänze die folgende Tabelle als Erklärung) - Frage 2 „Schwerpunkte“ (Mehrfachauswahl möglich):
Keine/Beweise / Formeln/Experimente / Statistik/Neuheit / Verwandte Arbeiten(Freitext für Konferenz oder spezifische Angaben möglich)
- Frage 1 „Tiefe“:
| Tiefe | Anzahl Segmente | Traces pro Segment | Perspektiven (Lenses) | Falsifikationsumfang | Ungefähre Anzahl Agenten | Geschätzte Zeit |
|---|---|---|---|---|---|---|
| quick | 2–4 | 1 | L0 (Synthese) | Major-Funde und solche ohne eindeutige Lokalisierung | 4–8 | 10–20 Min |
| standard | 4–8 | High 2, andere 1 | L1, L2, L3 | Major-Funde und solche ohne eindeutige Lokalisierung | 10–20 | 20–45 Min |
| deep | 5–12 | High 3, Medium 2, Light 1 | L1, L2, L3 | Zusätzlich Minor-Funde aus Formeln, Statistik, numerischen Werten; Kritik | 20–40 | 45–90 Min |
Die tatsächliche Zeit variiert stark mit der Länge des Papiers.
- Falls der Anschein besteht, dass der Benutzer ein fremdes Manuskript als Gutachter prüfen möchte, weise ihn darauf hin, die KI-Nutzungsrichtlinien der Zielkonferenz oder des Zieljournals zu beachten (viele Herausgeber und Konferenzen verbieten die Eingabe von Manuskripten in KI-Tools während des Review-Prozesses). Bei Autoren, die ihr eigenes Manuskript prüfen, ist dieser Hinweis nicht erforderlich.
1. Aufnahme
python <skill_dir>/scripts/deep_review.py init <Pfad zum Dokument> --depth standard --focus "<Fokus, falls vorhanden, sonst weglassen>" --venue "<Zielkonferenz, falls vorhanden, sonst weglassen>" --lang de
- Das Arbeitsverzeichnis wird unter
<Verzeichnis des Dokuments>/<Dokumentname>_deep_review/erstellt (falls nicht schreibbar, im aktuellen Verzeichnis; mit--wskann es explizit angegeben werden) - Es werden erstellt:
paper.txt(mit=== Page N ===-Trennern),pages/page_NNN.png(150 dpi),pages.json,config.json - Die ausgegebene Seitenübersicht (Wortanzahl, Anteil mathematischer Symbole, Anzahl Gleichungsnummern, Anzahl Theoreme / Beweise, Überschriften, Abbildungs- und Tabellenunterschriften) wird im nächsten Schritt verwendet
- Lies alle
WARN-Meldungen. Falls der Text (z.B. bei gescannten PDFs) unzureichend ist, ergänze die Aufgabenanweisungen für die Agenten um den Hinweis, sich hauptsächlich auf die Seitenbilder zu stützen - Die Berichtssprache wird mit
--lang(ja/en) festgelegt und sollte der Benutzersprache entsprechen. Zitate bleiben im Original
2. Segmentierung und Budgetzuweisung
Erstelle anhand der Seitenübersicht die Datei <ws>/segments.json. Wenn der Inhalt einer Seite allein aufgrund der Überschrift nicht klar ist, kannst du die entsprechende Seite in paper.txt überfliegen (ein vollständiges Lesen ist nicht nötig).
Regeln:
- Logische Zusammenhänge gliedern (z.B. Theorie, Methode, Experimente, Einleitung). Überschneidungen sind erlaubt, die Segmente müssen nicht aufeinanderfolgen. Beispiel: „Aussage von Theorem 3 in Sec. 3“ und „Beweis in Anhang B“ gehören in dasselbe Segment.
- Alle Seiten müssen einem Segment zugeordnet werden (dies wird von
plangeprüft). - Track (Tiefe) basierend auf Informationsdichte festlegen:
high: Haupttheorem und sein Beweis, zentrale Herleitungen, Kern eines Algorithmus, der die Korrektheit behauptet. Falls die Hauptaussage des Papiers in experimentellen Ergebnissen liegt, dann auch die zugehörigen Tabellen und Abbildungen.medium: Methodenbeschreibung, Experimente, zusätzliche Experimente im Anhang.light: Einleitung, verwandte Arbeiten, Discussion / Conclusion.none: Referenzen, Danksagungen etc. (Begründung (reason) erforderlich. Referenzen werden von Perspektive L3 geprüft).
high-Segmente sollten maximal 8–10 Seiten umfassen (bei Länge aufteilen).theme:intro/related_work/discussion/other/method/algorithm/system/theory/appendix_proofs/experiments/analysis/appendix_experiments/references.- In
noteskann ein Hinweis für den prüfenden Agenten notiert werden (z.B. „dieses Segment stützt Behauptung X, hängt von Definition Y in Abschnitt Z ab“).
{
"segments": [
{"id": "S1", "title": "Einleitung und Beiträge", "pages": "1-2", "theme": "intro", "track": "light",
"notes": "Beiträge C1–C3 als Aufzählung auf S.2"},
{"id": "S2", "title": "Hauptsatz und Beweis", "pages": "4-5,13-16", "theme": "theory", "track": "high",
"notes": "Beweis von Theorem 2 (S.5) in Anhang B (S.13–16). Annahmen sind Assumption 1–3 auf S.3"},
{"id": "S3", "title": "Vorgeschlagener Algorithmus", "pages": "3-4", "theme": "algorithm", "track": "medium"},
{"id": "S4", "title": "Experimente", "pages": "6-9", "theme": "experiments", "track": "medium"},
{"id": "S5", "title": "Verwandte Arbeiten / Fazit", "pages": "9-10", "theme": "related_work", "track": "light"},
{"id": "S6", "title": "Referenzen", "pages": "11-12", "theme": "references", "track": "none",
"reason": "Referenzen werden stichprobenartig von Lens L3 geprüft"}
]
}
Erzeuge anschließend den Prüfplan:
python <skill_dir>/scripts/deep_review.py plan <ws>
In plan.json werden die zu startenden Agenten aufgelistet (Task-ID, verantwortliches Segment, Track, Traces = Perspektive, Seiten, Ausgabepfad, empfohlener effort). Bei Fehlern korrigiere segments.json und führe den Befehl erneut aus.
Gib eine einzeilige Rückmeldung an den Benutzer: Aufteilung abgeschlossen: 6 Segmente (High 1 • Medium 2 • Light 2), 9 Prüfagenten werden parallel gestartet
3. Parallele Tiefenprüfung
Starte alle Tasks aus plan.json parallel in einer einzigen Nachricht mit dem Agent-Tool. Überschreitet die Anzahl 10, starte sie in Wellen von ca. 8. Jeder Task hat einen effort-Wert; falls das Agent-Tool eine effort-Spezifikation unterstützt, starte die Tasks mit diesem Wert (um mehr Rechenleistung auf High-Track-Segmente zu konzentrieren).
Aufgabenanweisung für Segmentprüfer (kind: segment):
Du bist ein „Segmentprüfer“ des Deep Review. Lies zuerst die folgenden Referenzen vollständig durch und befolge die darin beschriebenen Schritte und Ausgabeformate.
<skill_dir>/references/segment_reviewer.md
<skill_dir>/references/checklists.md (die für dein Theme relevanten Abschnitte)
<skill_dir>/references/schemas.md §1 und §4
- Volltext des Papiers: <ws>/paper.txt („=== Page N ===“ kennzeichnet die Seitenzahl) Seitenbilder: <ws>/pages/page_NNN.png
- Originaldokument: <ws>/<input_copy aus config.json>
- Task: <T03> Segment: <S2> „<Titel>“ Seiten: <4-5,13-16> Theme: <theory (proof)>
- Track: <high> Trace: <B — Gegenbeispiele, Grenzen, Annahmen>
- Notizen zum Segment: <notes, oder „keine“>
- Benutzerdefinierter Fokus: <focus, oder „keine“> Zielkonferenz: <venue, oder „keine“>
- Ausgabe: <ws>/<candidates/T03_S2_B.json>
- Hilfsmittel: python <skill_dir>/scripts/pdf_tools.py (zum Zuschneiden oder Rendern mit --grid für Vergrößerung von Abbildungen/Formeln)
Nutze den gesamten Text als Kontext, konzentriere deine Kritik aber auf die dir zugewiesenen Seiten. Ein anderes Teammitglied prüft dasselbe Segment aus einer anderen Perspektive.
Tasks, die mehrere Light-Track-Segmente bündeln, listen alle Segmente im Segment-Feld auf.
Aufgabenanweisung für Perspektiven-Prüfer (Lenses) (kind: lens):
Du bist ein „Perspektiven-Prüfer (Lens)“ des Deep Review (<L2 Neuheit / Bedeutung>). Lies zuerst die folgenden Referenzen vollständig durch und befolge die für deine Perspektive relevanten Schritte und Ausgabeformate.
<skill_dir>/references/lens_reviewers.md
<skill_dir>/references/checklists.md (§6–§8)
<skill_dir>/references/schemas.md §1 und §4
- Volltext des Papiers: <ws>/paper.txt Seitenbilder: <ws>/pages/page_NNN.png
- Task: <T08> Lens: <L2>
- Benutzerdefinierter Fokus: <…> Zielkonferenz: <…>
- Ausgabe: <ws>/<candidates/T08_L2.json> (schreibe auch overall_notes)
Betrachte das gesamte Papier aus der Perspektive deiner Lens. Eine tiefe, segmentbezogene Prüfung wird von anderen Teammitgliedern durchgeführt.
Warte, bis alle Agenten abgeschlossen sind, und führe dann plan erneut aus, um zu prüfen, ob alle Tasks mit [done] markiert sind. Fehlende Tasks starte genau einmal neu. Falls sie dann immer noch fehlen, fahre fort und informiere den Synthese-Agenten, damit er dies in den Limitations vermerkt.
Gib eine einzeilige Rückmeldung an den Benutzer: Prüfung 9/9 abgeschlossen
4. Zusammenführung und Deduplizierung
python <skill_dir>/scripts/deep_review.py merge <ws>
- Für jeden Kandidaten wird geprüft, ob das wörtliche Zitat im Papier existiert (
exact/fuzzy/not_found), und die zugehörige Seite wird notiert. Ähnliche Kandidaten werden zu Clustern (K01, …) zusammengefasst und inmerged.jsongeschrieben. - Das Feld
supportgibt die Anzahl der Tasks an, die dasselbe Problem unabhängig voneinander gefunden haben. Je mehr unabhängige Funde, desto wahrscheinlicher ist das Problem echt. - Die Batchs für die Falsifikationsprüfung (V01, …) werden ausgegeben. Warnungen wie
invalidodermissing outputswerden notiert und dem für die entsprechende Datei verantwortlichen Agenten zugeordnet.
Gib eine einzeilige Rückmeldung an den Benutzer: 64 Kandidaten → auf 38 reduziert, 9 werden der Falsifikationsprüfung unterzogen
5. Falsifikationsprüfung
Starte die verify_tasks aus merged.json parallel in einer einzigen Nachricht.
Aufgabenanweisung für Falsifikationsprüfer:
Du bist ein „Falsifikationsprüfer“ des Deep Review. Lies zuerst die folgenden Referenzen vollständig durch.
<skill_dir>/references/verifier.md
<skill_dir>/references/schemas.md §2
- Volltext des Papiers: <ws>/paper.txt Seitenbilder: <ws>/pages/page_NNN.png
- Zu prüfende Cluster: <K01, K04, K07> aus <ws>/merged.json (zugehörige Seiten: <…>)
- Ausgabe: <ws>/verdicts/<V01>.json
Gehe für jeden Kandidaten zunächst von der Annahme aus, dass das Papier korrekt ist, und versuche, den Kandidaten zu widerlegen. Bestätige (`confirmed`) nur diejenigen Kandidaten, die du unabhängig reproduzieren kannst (d.h. mit konkreten Belegen wie Nachrechnungen, Gegenbeispielen, widersprüchlichen Stellen im Papier etc.).
Nach Abschluss:
python <skill_dir>/scripts/deep_review.py collate <ws>
Die Datei collated.json enthält die Prüfergebnisse, verknüpft mit den Clustern. Einträge mit refuted oder cannot_locate sollten gelöscht werden.
Gib eine einzeilige Rückmeldung an den Benutzer: Falsifikationsprüfung abgeschlossen: 5 bestätigt, 2 plausibel, 2 Fehldetektionen
6. Synthese
Aufgabenanweisung für den Synthese-Agenten:
Du bist der „Synthese-Agent“ des Deep Review. Lies zuerst die folgenden Referenzen vollständig durch.
<skill_dir>/references/synthesis.md
<skill_dir>/references/schemas.md §3 und §4
- Eingabe: <ws>/collated.json (Kandidaten, Prüfergebnisse, Lenses-Befunde, Perspektivenverteilung), <ws>/paper.txt,
<ws>/pages/, <ws>/config.json (Tiefe, Fokus, Zielkonferenz, Sprache)
- Ausgabe: <ws>/findings.json
- Führe nach Abschluss folgenden Befehl aus und korrigiere die Ausgabe, bis keine Fehler mehr auftreten:
python <skill_dir>/scripts/deep_review.py render <ws> --check
- Berichtssprache: <Deutsch> Benutzerdefinierter Fokus: <…> Zielkonferenz: <…>
- Anmerkungen: <Fehlende Tasks etc., die in die Limitations aufgenommen werden sollen, oder „keine“>
Nur bei Deep-Tiefe: Kritik-Agent. Nachdem der Synthese-Agent seine Arbeit beendet hat, beauftrage einen separaten Subagenten mit Folgendem:
Du bist der „Kritik-Agent“ des Deep Review. Überprüfe die Datei <ws>/findings.json (Entwurf des Synthese-Agenten) anhand von <ws>/paper.txt und <ws>/pages/. Lies zuerst <skill_dir>/references/synthesis.md §8 und prüfe alle Einträge auf die dort genannten Kriterien (Genauigkeit von Zitaten und Stellenangaben, Konkretheit, Angemessenheit des Schweregrads, Existenz externer Referenzen, Ton, Länge). Überprüfe alle Major-Einträge selbst. Suche keine neuen Funde. Schreibe das Ergebnis als Liste von „ID · Problem · Korrekturvorschlag“ in <ws>/critique.md.
Sobald critique.md erstellt ist, beauftrage den Synthese-Agenten (per SendMessage oder durch einen neuen Start) mit: „Lies critique.md, übernimm die berechtigten Korrekturen in findings.json und führe render --check aus, bis es fehlerfrei ist.“
Abschließend:
python <skill_dir>/scripts/deep_review.py render <ws>
Es werden report.md und report.html erstellt. Der HTML-Bericht ermöglicht das Filtern nach Major / Minor / Suggestions und das Umschalten zwischen Berichts- und Seitenreihenfolge.
7. Berichterstattung an den Benutzer
Lies findings.json und fasse die Ergebnisse kurz zusammen. Zitiere nicht den gesamten Bericht.
- Anzahl (Major / Minor / Suggestions) und Anzahl der durch die Falsifikationsprüfung ausgeschlossenen Fehldetektionen
- Alle Major Concerns, jeweils in einer Zeile (ID, Stelle, Kernaussage)
- Fazit (bottom_line) in 1–2 Sätzen
- Dateien:
report.html(im Browser öffnen),report.md, Arbeitsverzeichnis - Hinweis: Es handelt sich um KI-generierte Hinweise. Vor Änderungen am Manuskript sollte jeder Hinweis vom Autor überprüft werden.
Schlage nächste Schritte vor: Vertiefung eines bestimmten Hinweises, erneute Prüfung nach Überarbeitung, punktbewertetes Review mit Revisionsschleife (paper-review-loop).
Folgeaktionen
- Vertiefung (z.B. „Mehr Details zu MJ2“): Starte einen einzelnen Segmentprüfer mit dem entsprechenden Bereich als Zuständigkeit, Track high und Trace B (Gegenbeispiele). Integriere das Ergebnis in
findings.json→render. - Erneute Prüfung einer überarbeiteten Version: Führe den gesamten Prozess mit dem neuen PDF in einem neuen Arbeitsverzeichnis ab Schritt 1 durch. Gib dem Synthese-Agenten den Pfad zur vorherigen
findings.jsonund lasse ihn im Feldpreviousden Status der einzelnen Punkte dokumentieren. - Wiederaufnahme nach Unterbrechung: Prüfe die vorhandenen Dateien im Arbeitsverzeichnis (segments.json → plan.json mit
[done]→ merged.json → verdicts/ → collated.json → findings.json) und setze den Prozess beim letzten abgeschlossenen Schritt fort. Verwendeinit --forcenur, wenn der gesamte Prozess von vorne beginnen soll (dies löscht die vorherigen Ergebnisse).
Aufruf durch andere Skills
Skills wie review2revise-loop können dieses Skill als Teil eines iterativen Review-Prozesses aufrufen. Wenn der Aufrufer Eingabe, Arbeitsverzeichnis (--ws), Tiefe, Fokus, Zielkonferenz und eine vorherige findings.json spezifiziert:
- Stelle die Fragen aus §0 nicht. Verwende die angegebenen Werte.
- Führe die Schritte §1–§6 wie beschrieben durch und erstelle
findings.json,report.mdundreport.html. Wenn eine vorherigefindings.jsonangegeben wurde, füge dem Auftrag des Synthese-Agenten das Feldprevioushinzu. - Gib für §7 nur eine einzeilige Meldung mit den Anzahlen (Major / Minor / Suggestions) zurück und kehre zum aufrufenden Skill zurück. Schlage keine nächsten Schritte vor.
- Die Kriterien, die Tiefe und die Obergrenze für die Anzahl der Funde bleiben unverändert. Sie werden nicht zugunsten des aufrufenden Skills gelockert.
Umgebungen ohne Subagenten-Unterstützung
Der Ablauf bleibt identisch, aber du führst alle Tasks selbst nacheinander aus. Um die geringere Unabhängigkeit zu kompensieren, beachte Folgendes:
- Empfehle dem Benutzer die Tiefe „quick“ (oder „standard“ auf Wunsch).
- Lese vor jedem Task die zugewiesenen Seiten aus
paper.txtund den Seitenbildern noch einmal und verlasse dich nicht auf das Gedächtnis. - Beurteile jeden Task ausschließlich aus der Perspektive der entsprechenden Anleitung (z.B. segment_reviewer.md).
- Führe die Falsifikationsprüfung durch, ohne die beim Erstellen der Kandidaten verwendete Argumentation anzusehen; beurteile nur anhand der entsprechenden Stellen im Papier.
Prinzipien und ihre Begründung
- Keine nicht verifizierbaren Aussagen: Zitate müssen wörtlich sein, Formeln/Tabellen werden anhand von Bildern geprüft, Berechnungen werden mit Code reproduziert, externe Referenzen werden auf ihre Existenz geprüft. Ein Bericht mit Fehldetektionen verschwendet die Zeit des Autors und untergräbt das Vertrauen in echte Funde.
- Priorität vor Quantität: Major-Einträge konzentrieren sich auf Aussagen, die das Papier im Kern betreffen. Die Obergrenze für die Anzahl der Funde wird eingehalten. Übermäßige Detailbesessenheit und zu lange Berichte sind bei KI-Reviews am unbeliebtesten.
- Keine Punktevergabe: Deep Review konzentriert sich auf Fehler und Verbesserungsvorschläge; es werden keine subjektiven Punkte vergeben. LLM-generierte Punktzahlen sind tendenziell zu optimistisch und instabil. Falls Punkte gewünscht sind, verwende das Skill paper-review-loop.
- Die Entscheidung verbleibt beim Menschen: Dieses Werkzeug ist für Autoren vor der Einreichung gedacht und ersetzt nicht das menschliche Review. Die finale Entscheidung liegt beim Autor und den Gutachtern.
- Vertraulichkeit des Manuskripts wahren: Verwende in Websuchanfragen keine Textstellen aus dem Manuskript oder unveröffentlichte Titel. Sende das Manuskript nicht an externe Dienste.
- Die Originaldatei nicht verändern: Alle Arbeiten finden innerhalb von
<ws>statt.