Was macht Dokumenten-Review-Skill?

Bereitstellung von Artikeln/Dokumenten auf Cloudflare Pages mit Unterstützung für Inline-Textannotationen. Reviewer wählen Text aus und fügen Kommentare hinzu. Kommentare werden in Cloudflare D1 persistent gespeichert. Der Agent kann Feedback lesen und darauf aufbauend iterieren. Dieser Skill ist immer passwortgeschützt.

Voraussetzungen

Cloudflare-Anmeldedaten: $HOME/.openclaw/credentials/cloudflare.json
Cloudflare-API-Token muss die Berechtigung D1 Edit besitzen
Die D1-Datenbank wird automatisch von deploy.sh erstellt — Manuelle Erstellung oder Übergabe von DB-Parametern ist verboten

Wichtige Regeln

Der Projektname muss auf -review enden — deploy.sh erzwingt dies
Jede Review-Seite erhält eine eigene D1-Datenbank — Namensschema review-<Projektname>, automatisch erstellt, Wiederverwendung verboten
Persistenzverzeichnis: $HOME/.openclaw/published-content/<Projektname>/ — enthält meta.json, content.html, index.html
content.html ist das Build-Artefakt — bei erneuter Bereitstellung aus der Quelldatei neu generieren, nicht direkt content.html bearbeiten

Arbeitsablauf

1. Für Review bereitstellen (Erstveröffentlichung)

Quelldatei festlegen, semantisches HTML-Content erstellen (siehe HTML-Content-Regeln unten) → als content.html speichern

render.js ausführen, um mit Theme zu umhüllen → erzeugt index.html:

node references/render.js \
  --input /tmp/<Projektname>/content.html \
  --output /tmp/<Projektname>/index.html \
  --theme editorial

Bereitstellen (Annotation-Injection + D1-Erstellung ist vollautomatisch):
```
bash scripts/deploy.sh <Projektname> /tmp/<Projektname>
```

Nach der Bereitstellung sofort meta.json aktualisieren (deploy.sh erstellt automatisch initiales meta.json, der Agent muss Quellinformationen ergänzen):

python3 -c "
import json
meta_path = '$HOME/.openclaw/published-content/<Projektname>/meta.json'
with open(meta_path) as f: meta = json.load(f)
meta['source'] = '<Quelldateipfad, z. B. /path/to/your/source/file.md>'
meta['sourceType'] = '<markdown|pdf|text|generated>'
meta['theme'] = '<tatsächlich verwendetes Theme>'
with open(meta_path, 'w') as f: json.dump(meta, f, indent=2, ensure_ascii=False)
"

Passwortgeschützt mit benutzerdefiniertem Passwort

bash scripts/deploy.sh <Projektname> /tmp/<Projektname> --password <Passwort>

Das Bereitstellungsskript erledigt automatisch:

Erstellt eine dedizierte D1-Datenbank mit dem Namen review-<Projektname> (1:1 pro Projekt, niemals wiederverwendet)
Erstellt die Tabellen für Annotationen und Kommentare
Kopiert functions/api/annotations.js von references/annotations-api.js
Kopiert functions/_middleware.js von references/middleware-template.js
Setzt PAGE_PASSWORD über wrangler pages secret put (Passwort niemals im Quellcode)
Generiert wrangler.toml mit der D1-Bindung
Speichert content.html, index.html und meta.json persistent in $HOME/.openclaw/published-content/<Projektname>/

⚠️ Manuelle Übergabe von db-name oder db-id ist verboten. Das Skript verwaltet alles automatisch und stellt sicher, dass jede Review-Seite eine eigene D1-Datenbank hat.

Passwortverwaltung:

Erste Bereitstellung: --password-Parameter angeben, oder automatisch generieren lassen
Passwort wird als Cloudflare Secret gespeichert, nicht in meta.json oder Quellcode
Passwort ändern: deploy.sh <Projektname> --change-password <NeuesPasswort> (aktualisiert automatisch Secret + stellt neu bereit + aktualisiert meta.json)
Erneute Bereitstellung erfordert keine erneute Passworteingabe (Secret bleibt über Bereitstellungen hinweg bestehen)

2. Feedback lesen

D1 nach allen Annotationen und Kommentaren abfragen (DB-Name ist immer review-<Projektname>):

npx wrangler d1 execute review-<Projektname> --remote --command "
  SELECT a.text as highlighted, c.author, c.text as comment, c.created_at
  FROM comments c JOIN annotations a ON c.annotation_id = a.id
  ORDER BY c.created_at
"

Feedback dem Benutzer als Tabelle präsentieren.

3. Iterieren (Erneute Bereitstellung)

Wenn der Benutzer Änderungen basierend auf dem Review-Feedback wünscht:

$HOME/.openclaw/published-content/<Projektname>/meta.json lesen — source-Pfad und sourceType abrufen
D1-Feedback lesen (wie in Abschnitt 2)
Je nach sourceType entscheiden, wie aktualisiert wird:
- markdown/text: Quelldatei vom source-Pfad erneut lesen → content.html neu generieren
- pdf: Quelldatei noch vorhanden → neu extrahieren, sonst $HOME/.openclaw/published-content/<Projektname>/content.html verwenden
- generated: $HOME/.openclaw/published-content/<Projektname>/content.html als Basis für Änderungen verwenden
Mit demselben Theme rendern → index.html
Mit exakt demselben Projektnamen erneut bereitstellen:
```
bash scripts/deploy.sh <Projektname> /tmp/<Projektname>
```
- Gleicher Projektname → gleiche DB → Annotationsdaten bleiben erhalten
- Bei erneuter Bereitstellung muss --password übergeben werden, um das ursprüngliche Passwort beizubehalten, sonst wird ein neues Passwort generiert, das alte Secret überschreibt

⚠️ Erneute Bereitstellung muss denselben Projektnamen verwenden. Namensänderung = neue Seite + neue DB, alte Daten gehen verloren.

Bereits verarbeitete Annotationen verschwinden automatisch (hervorgehobener Text stimmt in der neuen Seite nicht mehr überein).

4. Bereinigung (Entfernen)

Beim Löschen eines Projekts müssen sowohl die D1-Datenbank als auch das lokale Persistenzverzeichnis bereinigt werden, keine Rückstände hinterlassen.

# 1. Pages-Projekt löschen
npx wrangler pages project delete <Projektname>

# 2. Zugehörige D1-Datenbank löschen (Namensschema festgelegt auf review-<Projektname>)
npx wrangler d1 delete review-<Projektname>

# 3. Lokales Persistenzverzeichnis löschen
rm -rf $HOME/.openclaw/published-content/<Projektname>

Erst wenn alle drei Schritte abgeschlossen sind, gilt die Bereinigung als abgeschlossen.

meta.json-Schema

{
  "type": "review",
  "project": "my-report-review",
  "source": "/path/to/your/source/file.md",
  "sourceType": "markdown",
  "theme": "editorial",
  "dbName": "review-my-report-review",
  "dbId": "uuid-here",
  "created": "2026-04-12T13:20:00+08:00",
  "lastDeployed": "2026-04-12T15:30:00+08:00"
}

sourceType-Werte:

markdown — .md-Datei aus knowledge-base oder anderen Pfaden (häufigster Fall)
pdf — PDF-Datei
text — Reine Textdatei
generated — Direkt im Gespräch generiert, keine Quelldatei

Umgebungseinrichtung

Alle wrangler-Befehle benötigen:

source <(python3 -c "
import json
with open('$HOME/.openclaw/credentials/cloudflare.json') as f:
    c = json.load(f)
print(f'export CLOUDFLARE_ACCOUNT_ID={c[\"account_id\"]}')
print(f'export CLOUDFLARE_API_TOKEN={c[\"api_token\"]}')
")

Hinweise

Das Passwort wird als Cloudflare Secret (PAGE_PASSWORD) gespeichert, niemals im Quellcode oder meta.json
Kommentare werden standardmäßig mit dem Autorennamen "Reviewer" gespeichert (kein Login erforderlich)
D1 Free Tier: 5M Lesevorgänge/Tag, 100K Schreibvorgänge/Tag — völlig ausreichend
Der Abgleich von Annotationen erfolgt textbasiert; bei Änderungen am Quelltext verschwinden alte Hervorhebungen automatisch
Der persistente Zustand befindet sich in $HOME/.openclaw/published-content/<Projektname>/ — wird von allen Agenten gemeinsam genutzt
Theme-Dateien werden von cloudflare-pages synchronisiert — themes/ oder render.js hier nicht direkt bearbeiten. Änderungen in cloudflare-pages/references/ vornehmen, dann bash scripts/sync-themes.sh ausführen (vom cloudflare-pages-Skill)

HTML-Content-Regeln

Bei der Generierung von HTML-Inhalten für Review-Seiten sind diese Regeln strikt zu befolgen:

Nur semantisches HTML

Reines semantisches HTML ausgeben — keine <style>-Tags, keine Inline-Styles, keine <html>/<head>/<body>-Wrapper
Standard-Tags verwenden: <h1>-<h4>, <p>, <table>, <ul>/<ol>, <blockquote>, <details>, <hr>

Strukturelle Konventionen

<table> für Vergleiche, Bewertungen, Datentabellen
<blockquote> für wichtige Erkenntnisse oder Zitate
<details><summary> für einklappbare Abschnitte
<div class="toc"> für Inhaltsverzeichnis
<p class="meta"> für Metadatenzeilen (Datum, Autor etc.)
<div class="footer"> für Fußzeilentext

Badge-Klassen

<span class="badge badge-green">Bestanden</span> — positiv
<span class="badge badge-yellow">Warnung</span> — Vorsicht
<span class="badge badge-red">Nicht bestanden</span> — negativ

Komponentenbibliothek (Wichtig — Muss verwendet werden)

Bei der Generierung von content.html müssen die folgenden Komponenten aktiv eingesetzt werden, um dem Inhalt eine visuelle Gliederung zu geben. Ein reines <p> + <ul>-Layout ist nicht ausreichend.

Callout-Boxen — Hervorhebung wichtiger Informationen

<div class="callout">Standard-Callout: Allgemeine wichtige Informationen</div>
<div class="callout callout-conclusion"><strong>Fazit:</strong> Kernaussage und endgültige Empfehlung</div>
<div class="callout callout-warning"><strong>Achtung:</strong> Risiken, Bedenken, zu beachtende Probleme</div>
<div class="callout callout-important"><strong>Wichtig:</strong> Schlüsseldaten, nicht zu ignorierende Fakten</div>

Pfadkarten — Optionen/Weg-Vergleiche

<div class="path-card">
  <div class="path-label">Option A</div>
  <p>Beschreibung...</p>
</div>
<div class="path-card recommended">
  <div class="path-label">Option B (Empfohlen)</div>
  <p>Beschreibung...</p>
</div>

Argumentationskette — Logische Schlussfolgerungen

<div class="reasoning-chain">
  <ol>
    <li>Erster Schritt der Argumentation...</li>
    <li>Zweiter Schritt der Argumentation...</li>
    <li>Daraus folgt die Schlussfolgerung...</li>
  </ol>
</div>

Aktionspunkte — Handlungsempfehlungen

<div class="action-items">
  <ol>
    <li><strong>Kurzfristig (innerhalb 1 Woche):</strong> Konkrete Aktion...</li>
    <li><strong>Mittelfristig (innerhalb 1 Monats):</strong> Konkrete Aktion...</li>
  </ol>
</div>

Abschließende Empfehlung — Dunkler Block

<div class="final-rec">
  <p><strong>Abschließende Empfehlung:</strong> Ein-Satz-Kernergebnis, am Ende des Dokuments als Abschluss.</p>
</div>

Schlagwörter — Tags

<div class="keywords">
  <span class="kw">Tag 1</span>
  <span class="kw">Tag 2</span>
</div>

Abschnittstrenner — Kapiteltrennung (am besten mit magazine/refined-Theme)

<div class="section-divider"><span class="num">Abschnitt 01</span></div>

Haftungsausschluss — Disclaimer am Ende

<p class="disclaimer">Dieser Bericht wurde von einer KI erstellt, dient nur zu Informationszwecken und stellt keine professionelle Beratung dar.</p>

Qualitätsstandards für Inhalte

Bei der Generierung von content.html ist Folgendes zu beachten:

Jeder h2-Abschnitt enthält mindestens 1 Komponente (callout / path-card / table / reasoning-chain usw.)
Wichtige Schlussfolgerungen müssen mit callout-conclusion hervorgehoben werden, nicht in normalen Absätzen versteckt
Bei Vergleichen path-card oder table verwenden, nicht nur reine Textaufzählungen
Am Ende muss final-rec stehen (wenn der Inhalt eine klare Schlussfolgerung/Empfehlung enthält)
TOC muss mit <div class="toc"> umschlossen sein, nicht mit nacktem <ul>

Verfügbare Themes

editorial — Analyse-Stil für längere Texte (Serifen-Schriftart für Fließtext + serifenlose Überschriften, warmgrauer Hintergrund, tiefblaue Akzente, 740px schmale Spalte). Am besten für tiefgehende Analysen, Forschungsberichte. Funktionen: Callout-Boxen, Pfadkarten, Argumentationsketten, Aktionspunkte.
magazine — Magazin-Stil für lange Artikel (Playfair Display-Überschriften + DM Sans-Fließtext, dunkler Hero-Header, roter Akzent, „Abschnitt 01“-Nummerierung, *** Trennlinien). Am besten für wirkungsvolle redaktionelle Beiträge, visuell beeindruckende Berichte. Erfordert Google Fonts.
swiss — Schweizer Internationaler Stil (IBM Plex Mono-Fließtext + Instrument Serif-Überschriften, reines Weiß, Schwarz+Rot+Blau, Rasterlayout, 900px). Am besten für extrem saubere, rationale, technische Dokumente. Erfordert Google Fonts.
refined — Hochwertiger, eleganter Stil (Cormorant Garamond Serifen-Fließtext + Outfit serifenlose Labels, cremefarbener Hintergrund mit Pergament-Textur, Gold + Salbeigrün + Rosa, zentriertes Layout, 700px). Am besten für Premium-Whitepapers, Executive Briefs. Erfordert Google Fonts.

Theme-Auswahl

Wenn der Benutzer ein Theme angibt (z. B. „grau“/„das graue“/„editorial Style“, „magazine style“/„Magazin-Stil“/„das schwarze“, „swiss Style“/„das weiße“/„minimalistisch“, „refined“/„gold“/„edel“/„fancy“), verwende dieses Theme.
Wenn der Benutzer kein Theme angibt, automatisch basierend auf dem Inhaltstyp auswählen:
- editorial: tiefgehende Analysen, lange Argumentationen, Schul-/Produktvergleiche, Recherche-Briefings, formelle Berichte, Bewertungen — Standardauswahl
- magazine: wirkungsvolle redaktionelle Beiträge, die von einer dramatischen visuellen Präsentation profitieren
- swiss: extrem saubere, rationale, technische Dokumente, technische Spezifikationen, Vergleiche, Datenzusammenfassungen
- refined: Premium-Whitepapers, Executive Briefs, Dokumente mit luxuriösem Gefühl, risikoreiche Analysen
Bei Unsicherheit Standardwert editorial verwenden.

FuzzyTG/Dokumenten-Review-Skill

Was ist Dokumenten-Review-Skill?

In Ihrer bevorzugten KI fragen

Dokumentation