0x6869726f6b69/claude-skills

Paper Review Loop: Begutachtung → Überarbeitung → erneute Begutachtung

Eine PDF eines wissenschaftlichen Papers wird als Experte begutachtet, das Manuskript gemäß den Hinweisen überarbeitet, das PDF neu erstellt und die überarbeitete Version erneut begutachtet. Dies wird innerhalb einer vom Benutzer festgelegten Zeitbegrenzung so oft wie möglich wiederholt. Am Ende erhält der Benutzer die folgenden drei Dinge:

• Das überarbeitete PDF (endgültige Version) sowie die PDFs jeder Runde
• Die Gutachten jeder Runde (7 Punkte) sowie die Entwicklung der Bewertungen und Hinweise
• Eine Liste der Aufgaben, die nur der Autor erledigen kann (zusätzliche Experimente usw. – hierhin verschoben, um Erfindungen im Text zu vermeiden)

Im Folgenden bezeichnet <skill_dir> das Verzeichnis, in dem sich diese SKILL.md befindet, und <ws> das Arbeitsverzeichnis. Skriptnamen wie loop_state.py sind Kurzformen für python <skill_dir>/scripts/loop_state.py. In Umgebungen ohne python wird python3 verwendet.

0. Zunächst: Zeitbegrenzung erfragen

1. Das Ziel-PDF identifizieren. Falls es nicht in der Nachricht enthalten ist, danach fragen. Prüfen, ob am selben Ort wie die PDF oder als Anhang LaTeX-Quellen (Ordner, .zip, arXiv .tar.gz, .tex) vorhanden sind. Quellen erhöhen die Qualität und Geschwindigkeit der Überarbeitung erheblich.
2. Die Zeitbegrenzung erfragen. Wenn ein Fragetool wie AskUserQuestion vorhanden ist, dieses verwenden; andernfalls per Chat fragen und auf die Antwort warten. Wenn die Zeit bereits in der Startnachricht angegeben ist, diese verwenden und nicht erneut fragen.
   • Frage 1 „Zeitbegrenzung“: Nur Begutachtung (keine Überarbeitungsschleife) / 1 Stunde / 2 Stunden / 3 Stunden (auch andere Angaben wie „30 Minuten“, „5 Stunden“ usw. sind möglich)
   • Frage 2 „Einreichungsort / Bewertungskriterien“ (im selben Fragendialog zusammenfassen, falls bereits bekannt, weglassen): Keine Angabe (Top-Konferenzstandard) / NeurIPS, ICML, ICLR / Journal (Accept / Minor / Major / Reject)
3. Nach Erhalt der Antwort sofort die Uhr starten. Die Einrichtungszeit ist im Budget enthalten.

   python <skill_dir>/scripts/loop_state.py init <ws> --hours 2 --paper <pdf> --venue "<Einreichungsort>"
   

   (--minutes 90 oder --review-only sind ebenfalls möglich)
4. Falls ein Schlafverhinderungstool (z. B. keep-awake für Claude Desktop) vorhanden ist, dieses für die Dauer des Budgets aktivieren. Wenn der PC in den Ruhezustand fällt, wird eine längere Schleife unterbrochen.
5. Dem Benutzer in 2–3 Zeilen mitteilen: Abgabefrist, Arbeitsverzeichnis, dass die Schleife ab sofort ohne Rückfragen autonom läuft und jederzeit unterbrochen werden kann.

1. Einrichtung

Das Arbeitsverzeichnis ist <Verzeichnis der PDF>/<PDF-Name>_review_loop/ (falls dort nicht beschreibbar, dann im Arbeitsverzeichnis).

<ws>/
├── state.json          Timer und Aufzeichnung der Phasen (verwaltet von loop_state.py)
├── original/           Empfangene PDF und Quellen. Werden nicht verändert.
├── src/                Quellen für die Bearbeitung (main.tex, figures/, *.bib)
├── work/               Temporäre Dateien wie Seitenbilder
├── rounds/
│   ├── r01/            paper.pdf(=Original PDF) paper.txt review.md issues.json response.md src/
│   ├── r02/            paper.pdf(1. Überarbeitung) paper.txt review.md issues.json response.md src/ changes.diff
│   └── ...
├── issue_tracker.md    Verlauf der Bewertungen und Hinweisstatus (generiert von loop_state.py summary)
├── author_todo.md      Nur vom Autor lösbare Aufgaben (zusätzliche Experimente usw.)
└── final_report.md

1. loop_state.py start <ws> --round 0 --phase setup
2. PDF in original/ und rounds/r01/paper.pdf kopieren und Text extrahieren: python <skill_dir>/scripts/pdf_tools.py text <ws>/rounds/r01/paper.pdf -o <ws>/rounds/r01/paper.txt
3. Quellen zur Bearbeitung in src/ bereitstellen (im Nur-Begutachtung-Modus nicht erforderlich und daher überspringen).
   • Wenn LaTeX-Quellen vorhanden sind: In src/ kopieren/entpacken (die Datei mit \documentclass und \begin{document} ist das Hauptdokument). Einmal mit build_pdf.py bauen und sicherstellen, dass es durchläuft.
   • Wenn nur eine PDF vorhanden ist: Nach der Anleitung in references/pdf_to_latex.md die LaTeX-Quellen rekonstruieren. Dies ist der aufwändigste Schritt (ca. 20–40 Minuten für 10 Seiten) – den Benutzer kurz darauf hinweisen, dass dies das Budget belastet.
4. python <skill_dir>/scripts/snapshot.py <ws>/src <ws>/rounds/r01
5. loop_state.py end <ws> --round 0 --phase setup

Die Begutachtung von Runde 1 bezieht sich auf das Original-PDF und kann parallel zur Quellenrekonstruktion laufen. Wenn Sub-Agenten verfügbar sind, können der Begutachtungs- und der Rekonstruktionsverantwortliche gleichzeitig gestartet werden.

2. Schleife

Aufgabenverteilung und Begründung

• Begutachtung wird pro Runde einem neuen Sub-Agenten (Agent-Tool) übertragen. Ein Gutachter ohne Kontext des Überarbeiters kann nur anhand dessen beurteilen, was tatsächlich in der PDF steht, nicht, was der Überarbeiter beabsichtigt hat. Eine Selbsteinschätzung im gleichen Kontext würde die Bewertung verfälschen.
• Die Überarbeitung wird ebenfalls einem Sub-Agenten übertragen; der Hauptagent konzentriert sich auf die Orchestrierung (Zeitkontrolle, Start, Validierung, Zusammenfassung). Dadurch schwillt der Kontext des Hauptagenten auch bei stundenlangen Schleifen nicht an, und der gesamte Zustand bleibt in Dateien erhalten.
• Wenn keine Sub-Agenten verfügbar sind, führt der Hauptagent alles selbst nacheinander aus. Auch in diesem Fall muss vor der Begutachtung der Text aus dem neuen PDF neu extrahiert und gelesen werden, um nur das Geschriebene und nicht die Erinnerung zu bewerten.

Runde r (r = 1, 2, …)

(a) Begutachtung

1. loop_state.py start <ws> --round r --phase review
2. Den Sub-Agenten mit dem untenstehenden „Auftragstext für den Gutachter“ starten und auf dessen Abschluss warten.
3. Die Ausgabe validieren: Prüfen, ob review.md die erforderlichen Abschnitte (für r≥2 auch Abschnitt 0) enthält und issues.json als gültiges JSON lesbar ist. Bei Fehlern den gleichen Gutachter zur Korrektur auffordern.
4. loop_state.py end <ws> --round r --phase review, gefolgt von loop_state.py summary <ws> (issue_tracker.md aktualisieren).
5. Dem Benutzer eine einzeilige Fortschrittsmeldung geben. Beispiel: r02 Begutachtung abgeschlossen: Gesamt 3→4, Major offen 5→2, Restzeit 1h12m

(b) Entscheidung über Fortsetzung

1. loop_state.py status <ws> ausführen. Da Claude die verstrichene Zeit nicht fühlen kann, muss die Zeitentscheidung zwingend dieser Ausgabe folgen.
2. Bei NEXT: STOP zu §3 gehen. Die Entscheidung erfolgt unmittelbar nach der Begutachtung, sodass die endgültige PDF immer begutachtet ist.
3. Auch bei CONTINUE kann beendet werden, wenn das neueste issues.json keine Hinweise mit status open / partially_resolved mehr enthält (alle sind resolved oder als [AUTHOR TODO] zurückgestellte needs_author). Wenn alle im Text korrigierbaren Punkte erschöpft sind und weitere Runden nur noch die Formulierung polieren würden, ist dies in final_report zu begründen.

(c) Überarbeitung (entsprechend der Begutachtung von Runde r, Erstellung der PDF für Runde r+1)

1. loop_state.py start <ws> --round r --phase revise. Die in status angegebene revise by-Zeit notieren.
2. Den Sub-Agenten mit dem untenstehenden „Auftragstext für den Überarbeiter“ starten und auf dessen Abschluss warten.
3. Validieren: Prüfen, ob rounds/r{r+1}/paper.pdf und paper.txt vorhanden sind, der Build erfolgreich war und null undefinierte Referenzen enthält, und rounds/r{r}/response.md vorhanden ist. Wenn der Build fehlschlägt, die beschädigten Dateien aus rounds/r{r}/src/ zurückholen und die Änderungen wiederholen. Eine alte PDF darf nicht als überarbeitete Version in die Begutachtung gegeben werden.
4. loop_state.py end <ws> --round r --phase revise → als r+1 zu (a) zurückkehren.

Der Überarbeiter darf nach Ablauf der revise by-Zeit keine neuen Korrekturen mehr beginnen, sondern nur noch den Build abschließen, um Zeit für die nächste Begutachtung zu lassen.

Auftragstext für den Gutachter

Sie sind der Gutachter dieses Papers. Lesen Sie zunächst <skill_dir>/references/reviewer_guide.md und
<skill_dir>/references/review_template.md vollständig und folgen Sie dem Gutachterprofil, den Kriterien und dem Ausgabeformat.

- Begutachtungsobjekt: <ws>/rounds/rNN/paper.pdf (extrahierter Text: <ws>/rounds/rNN/paper.txt)
- Runde: NN
- Hinweise der Vorrunde: <ws>/rounds/r(NN-1)/issues.json   ← nur ab Runde 2
- Einreichungsort / Bewertungsmaßstab: <venue oder „Keine Angabe“>
- Sprache des Gutachtens: Deutsch
- Ausgabe: <ws>/rounds/rNN/review.md und <ws>/rounds/rNN/issues.json
- Hilfsmittel: python <skill_dir>/scripts/pdf_tools.py (mit render können Seiten mit Abbildungen als Bild angezeigt werden)

Die Bewertung darf sich ausschließlich auf den Inhalt dieser PDF stützen. Absichten oder Antwortschreiben des Überarbeiters werden nicht weitergegeben.
Mit [AUTHOR TODO] gekennzeichnete Stellen sind nur Versprechen und daher als ungelöst zu behandeln.
Geben Sie abschließend in vier Zeilen zurück: „Gesamtbewertung / Confidence / Anzahl offener Major-Probleme / Anzahl neuer Hinweise“

Auftragstext für den Überarbeiter

Sie sind der Autor dieses Papers und überarbeiten das Manuskript basierend auf der Begutachtung. Lesen Sie zunächst
<skill_dir>/references/revision_guide.md vollständig und beachten Sie insbesondere die Regel „Keine Fälschungen“.

- Zu bearbeitende Quellen: <ws>/src/ (Hauptdatei: <main>.tex)
- Diese Begutachtung: <ws>/rounds/rNN/review.md, <ws>/rounds/rNN/issues.json
- Verlauf: <ws>/issue_tracker.md (automatisch generiert, daher nur lesen. Nicht bearbeiten)
- Autor-TODO: <ws>/author_todo.md (falls nicht vorhanden, anlegen; ergänzen und aktualisieren)
- Zeit: Bis <revise_by> muss der Build abgeschlossen sein. Die verbleibende Zeit kann mit
  python <skill_dir>/scripts/loop_state.py status <ws> überprüft werden.
- Nach Abschluss:
  1. python <skill_dir>/scripts/build_pdf.py <ws>/src/<main>.tex --out <ws>/rounds/r(NN+1)/paper.pdf
     (Fehler und undefinierte Referenzen auf Null korrigieren)
  2. python <skill_dir>/scripts/pdf_tools.py text <ws>/rounds/r(NN+1)/paper.pdf -o <ws>/rounds/r(NN+1)/paper.txt
  3. python <skill_dir>/scripts/snapshot.py <ws>/src <ws>/rounds/r(NN+1) --prev <ws>/rounds/rNN
  4. <ws>/rounds/rNN/response.md schreiben (Format siehe revision_guide.md)
Geben Sie abschließend zurück: „Bearbeitete Hinweis-IDs / an Autor-TODO übergebene IDs / Build-Ergebnis (Seitenzahl, undefinierte Referenzen, Anzahl AUTHOR TODO)“

Wenn die Rekonstruktion aus einer PDF beauftragt wird: „Lesen Sie <skill_dir>/references/pdf_to_latex.md, rekonstruieren Sie <ws>/original/<Name>.pdf in <ws>/src/, speichern Sie das gebaute PDF in <ws>/rounds/r01/reconstructed.pdf und schreiben Sie die Unterschiede in <ws>/src/RECONSTRUCTION_NOTES.md.“

3. Abschlussverarbeitung

1. loop_state.py finish <ws> --reason "<Abgabefrist / Alle im Text korrigierbaren Hinweise erschöpft / Nur Begutachtung>" → loop_state.py summary <ws>
2. Wenn mindestens eine Überarbeitung stattfand, die neueste PDF als <ws>/<PDF-Name>_revised.pdf kopieren.
3. <ws>/final_report.md schreiben:

# Gutachten- und Überarbeitungsbericht: <Titel des Papers>
- Zeitbegrenzung / Verbrauchte Zeit / Anzahl Runden / Grund für Beendigung
## Verlauf der Bewertungen            (Tabelle aus issue_tracker.md)
## Kernpunkte des Gutachtens zum Original (r01)   (Zusammenfassung der Begründung und Hauptschwächen)
## Hauptpunkte, die durch Überarbeitung gelöst wurden
## Verbleibende Probleme
### Im Text korrigierbar, aber zeitlich nicht abgeschlossen
### Vom Autor zu erledigen (Priorität nach author_todo.md)
## Bewertung der letzten Runde und Bedingungen für Annahme
## Dateiliste

4. Die Antwort an den Benutzer kurz fassen: Anzahl Runden, Bewertungsverlauf, gelöste Hauptpunkte, verbleibende kritische Probleme und Top-3-Autor-TODOs, Dateipfade. Kein vollständiges Gutachten einfügen, sondern auf die Dateien verweisen. Im Nur-Begutachtung-Modus die Kernpunkte des r01-Gutachtens (Begründung, Bewertung, Hauptschwächen, Rebuttal-Fragen) in die Antwort aufnehmen.

Wiederaufnahme nach Unterbrechung

Wenn <ws>/state.json existiert und der Status running ist, mit loop_state.py status <ws> und einer Prüfung des Inhalts von rounds/ die letzte abgeschlossene Phase ermitteln und ab der nächsten Phase fortsetzen. Ein erneutes init setzt die Uhr zurück; daher nur auf ausdrücklichen Wunsch des Benutzers mit --force durchführen.

Prinzipien und ihre Begründung

• Keine Fälschungen: Keine experimentellen Ergebnisse, Zahlen, Daten, Zitate oder Beweise erfinden. Dies ist ein reales Forschungsmanuskript; bereits eine einzige erfundene Zahl würde wissenschaftliches Fehlverhalten darstellen und dem Benutzer ernsthaften Schaden zufügen. Hinweise, die neue Ergebnisse erfordern, werden im Text auf den Umfang der Belege beschränkt; notwendige Experimente werden als [AUTHOR TODO] in author_todo.md verschoben.
• Begutachtungsmaßstab nicht lockern: Auch bei Fortschreiten der Runden nach dem gleichen Maßstab bewerten. [AUTHOR TODO] gilt als ungelöst; bloße Umformulierungen stellen keine neuen Belege dar. Die Bewertung steigt nur, wenn das Problem auf dem Papier tatsächlich gelöst ist. Andernfalls würde diese Schleife nur den Anschein einer Verbesserung erzeugen.
• Zeitentscheidung dem Skript überlassen: Keine Schätzung der verstrichenen Zeit. In jeder Runde status aufrufen.
• Keine Rücksprache mit dem Benutzer zwischen den Runden: Mit Erhalt der Zeitbegrenzung ist die gesamte Schleife genehmigt. Die Berichterstattung beschränkt sich auf eine einzeilige Fortschrittsmeldung; Rücksprache erfolgt nur bei Blockaden (Build nicht reparierbar, PDF nicht lesbar usw.).
• Originaldateien nicht verändern: original/ wird schreibgeschützt behandelt; alle Bearbeitungen erfolgen an der Kopie in src/.