Research → plan.md + Quellenverzeichnis

Was macht Research → plan.md + Quellenverzeichnis?

Der Orchestrator eines Drei-Skill-Pakets:

• source-triage: Quellen finden und Zugriff, Erreichbarkeit, Integrität und Bewertung vor dem Lesen klassifizieren.
• research-plan (dieses Skill): Lesen, was erreichbar ist, dann Plan und Quellenverzeichnis schreiben.
• evidence-check: Eine unabhängige Prüfung, ob jede Behauptung echt und belegt ist.

Fehlt ein verwandtes Skill, führe dessen Schritte inline mit diesen Zusammenfassungen aus. Der deterministische Prüfer ist in diesem Skill enthalten: python3 <Skill-Ordner>/scripts/research_checks.py. Es ist reines Python der Standardbibliothek und läuft in der eigenen Code-Sandbox (PDF-Text benötigt pypdf; pip install pypdf falls nicht vorhanden). Verwende es immer, wenn ein deterministischer Check genannt wird. Nur wenn keine Code-Ausführung möglich ist, prüfe manuell und vermerke dies.

Ausgabedateien (feste Namen)

research/<Thema-Slug>/plan.md
research/<Thema-Slug>/sources__<Thema-Slug>__<YYYY-MM-DD>.md   ← menschliche Ansicht
research/<Thema-Slug>/ledger.md                                ← Arbeitszustand, wird während der Arbeit geschrieben
research/<Thema-Slug>/notes/<Zitierschlüssel>.md               ← Notizen pro Quelle
research/<Thema-Slug>/notes/raw/<Zitierschlüssel>.txt          ← Rohtext (API-XML/PDF-Text), wörtlich gespeichert
research/<Thema-Slug>/claims.json                              ← Belegte Behauptungen + Zitate, zur Prüfung

• <Thema-Slug>: 3–6 spezifische Wörter, klein-kebap (starch-fructan-engineering-plants).
• Überschreibe niemals einen früheren Durchlauf. Gleiches Thema: neue datierte Quellendatei + Changelog-Eintrag. Neuer Aspekt: neuer Slug.
• Arbeite im verbundenen Ordner des Benutzers, falls vorhanden, sonst im Arbeitsverzeichnis. Sende beide Hauptdateien am Ende.

Modi

• auto (Standard): keine Pausen; liste deine Entscheidungen am Ende. step: stoppe bei jedem ◆.
• quick: 8–15 Quellen. Vollständige Lektüre von bis zu 5 Top-Quellen; andere sections: (Abstract + Ergebnisse + Diskussion). Gegenbelege: max. 3 Suchen. Schneeball optional.
• deep: 25+ Quellen, Schneeball-Prinzip, parallele Scouts, vollständige Lektüre aller A/B-Quellen.
• update: Der Benutzer hat Dateien heruntergeladen oder um Aktualisierung gebeten → Phase 6.
• Harte Einschränkungen in der Anfrage (ein Bewertungsraster, das 2 Buchkapitel, eine Wortbegrenzung, eine benötigte Datenbank erfordert) sind Anforderungen, keine Vorschläge. Erfülle sie mit überprüften Quellen oder sage klar, welche nicht erfüllt ist.

Phase 0 — Rahmensetzung

Eine Nachricht:

• das Ziel des Plans und wofür er ist (Agent / Skill / MCP / Bericht / Experiment / Entscheidung);
• Umfang, Jahre, Tiefe und Modus;
• harte Einschränkungen;
• 2–6 MECE-Achsen (sich nicht überschneidende Unterfragen).

Erstelle eine Aufgabenliste: Rahmensetzung → Triage → Lesen → Synthese → Schreiben → Prüfen. Gibt es kein Aufgaben-Tool, führe die Liste am Anfang von research/<Slug>/run-notes.md auf. ◆ Prüfpunkt: Achsen + Umfang.

Phase 1 — Triage (source-triage ausführen)

Bibliothek zuerst → entdecken → Integrität für alles, was du nennen wirst → Zugriff + Erreichbarkeit → Bewertung / Rolle / ⭐.

Das Ledger wird während der Arbeit geschrieben. Füge jede Suche und jede klassifizierte Quelle sofort an; Kontext kann während des Durchlaufs verloren gehen, und die Ledger-Datei ist das, was überlebt.

Im Deep-Modus mit Unteragenten sende einen Scout pro Achse parallel. Jeder Scout:

• verwendet ≤15 Tool-Aufrufe;
• schreibt notes/<Achse>.md mit den Abschnitten Takeaway · Zitierte Ergebnisse (mit Links) · Schlussfolgerungen · Lücken;
• fügt seine Kandidaten an das Ledger an.

Ohne Unteragenten führe die Achsen nacheinander aus. ◆ Prüfpunkt: Anzahl nach Zugriffsklasse + ⭐-Shortlist.

Phase 2 — Lesen

• Lies readable/held-Quellen, zuerst die höchstbewerteten. Bevorzuge Roh-Wege (Europe PMC XML via Shell, PDF-Text) und speichere den Text in notes/raw/<Zitierschlüssel>.txt.
• Ein WebFetch-Lesen ist read: full (extracted). Nutze es zum Verständnis, aber Behauptungen, die darauf beruhen, erhalten ⚠ extracted und gelten niemals als „belegt“ durch ein Zitat.
• Bei langen Texten lies in Abschnitten, bis du die Referenzliste erreichst. Der Quick-Modus erlaubt sections:-Lektüre; kennzeichne sie.
• Setze read in jeder Ledger-Zeile: full · sections:<welche> · abstract · metadata.
• Pro Quelle enthält notes/<Zitierschlüssel>.md:
  • WHY (Problem);
  • HOW (Methode, Daten);
  • WHAT (Ergebnisse: Zahlen exakt kopiert, mit einem Abschnitts-/Seitenlocator);
  • LIMITS, jeweils getaggt als author-stated (mit Locator) oder my-inference. Ohne Volltext: limits: not assessed (read: abstract).
• Wenn ein Satz eine Behauptung im Plan tragen wird, kopiere ein wörtliches Zitat von ≥40 Zeichen aus dem Rohtext in claims.json: {"id","claim","source":"notes/raw/<Zitierschlüssel>.txt","quote","locator"}.
• Fülle niemals eine Notiz aus dem Gedächtnis. „Nicht in dem Teil, den ich gelesen habe“ ist eine gültige Antwort.

Phase 3 — Synthese

• Beweismatrix: Quellen × Themen (unterstützt / widerspricht / schweigt). Gruppiere nach Themen, niemals Quelle für Quelle.
• Konvergenz (≥3 stimmen überein) · Divergenz (erkläre durch Methode, Population oder Zeit) · Stille (<2 Quellen: eine Lücke).
• Unabhängige Zählung: „4 Studien (2 unabhängige)". Ein gemeinsamer Datensatz, eine Kohorte, ein Team oder eine Studie zählt einmal.
• Gegenbelegs-Durchlauf: Für die wichtigsten Ergebnisse suche nach Nullergebnissen, fehlgeschlagenen Replikationen und Kritiken. Notiere die Suchbegriffe, auch wenn nichts gefunden wird. Quick-Modus: max. 3 Suchen.
• Negative Behauptungen („niemand hat X gemacht") tragen die dahinterstehenden Suchen bei sich, begrenzt auf das, was gesucht wurde.
• Beitragsprüfung: Was kann der Benutzer mit diesem Plan machen, was er vorher nicht konnte? Welcher ⭐-Download würde ihn am meisten verändern?
• Advocatus-Diaboli-Durchlauf: das stärkste Gegenargument, Cherry-Picking und eine unhinterfragte Prämisse. Verwerfe keinen Einwand, weil er unbequem ist.

Phase 4 — Dateien schreiben

plan.md

• Kopfzeile: Ziel · Wofür es ist · Umfang · Datum · Link zur Quellendatei · Evidence base: N full (raw) · N full (extracted) · N sections · N abstract · N metadata.
• Hauptteil: Was immer die Anfrage benötigt.
• Zitate: <sup>[3](sources__<slug>__<date>.md#s3)</sup>, nummeriert in der Reihenfolge der ersten Verwendung.
• Flags nach einem Zitat:
  • ⚠ abstract-only: nur das Abstract wurde gelesen;
  • ⚠ metadata-only: nur Titel/Verlag bekannt;
  • ⚠ extracted: über WebFetch gelesen, daher ist keine wörtliche Prüfung möglich;
  • ⚠ preprint.
• Abschluss: Offene Fragen · Was die ⭐-Downloads ermöglichen würden · Nicht erfüllte Einschränkungen (falls vorhanden) · Changelog.

sources____.md

# Quellen — <Lesbarer Thema-Titel> (<Datum>)
Plan: [plan.md](./plan.md) · Frage: <eine Zeile> · Modus: <quick|deep> · Durchsucht: <Datenbanken + Daten>
Anzahl: N gesamt · ⭐ X · readable R · free-but-blocked B · paywalled P · non-paper W · excluded E     (gesamt = jede Ledger-Zeile)
Evidence base: <gleiche Aufschlüsselung wie in plan.md>

## ⭐ 1. Zum Download für den lokalen Kontext
| # | Quelle | Typ | Bewertung | Zugriff · Lizenz | Warum wichtig für <das, was gebaut wird> | Wie zu beschaffen | Speichern als | Weiterverbreitung |

## 2. Offen & lesbar (in den Plan eingeflossen)
### <Thema A>
<a id="s1"></a>**[1]** Autoren (Jahr). [Titel](URL). *Verlag / Buchtitel, Seiten*. [DOI](https://doi.org/…) — `gold · CC-BY` · `readable:europepmc-xml` · read: full · Bewertung A · Beleg
(ein Preprint fügt dieser Zeile ein `` `preprint` ``-Label hinzu; der Prüfer verlangt dann `⚠ preprint` auf seinen Zitaten)
- WHY … · HOW … · WHAT … · LIMITS …

## 3. Kostenlos, aber für KI-Agenten blockiert (selbst öffnen)
Eintrag + beobachtete Blockade + direkter Link + etwaige Green Copy.

## 4. Paywalled
Eintrag + Link zur Green Copy oder „keine gefunden" + Abstract-Erkenntnis, falls verwendet.

## 5. Nicht-Paper-Quellen
Nach Art, Stufe T1–T5. Graue Literatur: URL + Zugriffsdatum + Snapshot-Link.

## 6. Ausgeschlossen (und warum)
Ein Bullet pro ausgeschlossenem Eintrag, beginnend mit **Excluded:** <Grund>.

## 7. Suchprotokoll & Zugriffsweg-Bericht

Regeln:

• Jeder Eintrag hat einen <a id="sN">-Anker, der der Nummerierung im Plan entspricht.
• Jede URL ist ein [text](url)-Link, auch in den Kopfzeilen.
• ⭐-Zeilen verweisen auf die Haupt-Eintragsnummer.
• Gruppiert nach Zugriffsklasse, dann nach Thema.

Phase 5 — Prüfen, dann ausliefern

1. Deterministische Prüfungen: führe python3 <Skill-Ordner>/scripts/research_checks.py all research/<slug>/ aus. Korrigiere jeden Fehler (fehlende Anker, fehlende ⚠-Flags, Zählungsabweichungen, Vokabular, Zitate nicht in der Quelle) und führe erneut aus, bis der Check besteht.
2. Beweisprüfung: führe evidence-check aus.
   • Mit Unteragenten: in einem neuen Agenten, dem nur die Dateien gegeben werden.
   • Ohne: eine Prüfung in derselben Sitzung, die jede Datei von der Festplatte neu liest und keine Erinnerung an das Schreiben hat. Kennzeichne sie als same-session (not independent) und schlage vor, dass der Benutzer evidence-check in einem neuen Chat ausführt, bevor er sich darauf verlässt.
3. Stichproben-Öffnen von 3 Links pro Zugriffsklasse. Ein 403/429 von einem Verlag beweist nichts; sage das.

Liefere beide Dateien mit einer Zeile über:

• die Hauptüberschrift des Plans;
• die ⭐-Anzahl;
• wie viele Quellen manuell heruntergeladen werden müssen;
• nicht erfüllte Einschränkungen.

Im Auto-Modus liste auch deine Entscheidungen auf (Achsen, Jahre, Datenbanken, Filter, Grenzen).

Phase 6 — Aktualisierung (nach Benutzer-Download)

1. Gleiche Dateien im Ordner mit den „Speichern als"-Namen ab.
2. Validiere sie (python3 <Skill-Ordner>/scripts/research_checks.py pdf <Dateien>).
3. Lese jede davon, speichere ihren Rohtext und setze held: user und read: full.
4. Bewerte neu, entferne provisorische ?-Bewertungen.
5. Wandle ⚠-Flags in belegte Behauptungen mit Zitaten um oder schreibe die Behauptungen um, denen der neue Text widerspricht.
6. Führe Phase 5 für die geänderten Abschnitte erneut aus.
7. Schreibe eine neue datierte Quellendatei und füge einen Changelog-Eintrag hinzu.

Warnsignale

Gedanke	Realität
„Ich prüfe den Zugriff nach dem Lesen"	Erst Triage, sonst formen Paywall-Abstracts unbemerkt den Plan.
„Es ist OA, also kann ich es lesen"	Teste den Weg. OA-Artikel wurden beim Testen blockiert.
„WebFetch hat mir den Text gegeben"	Es gab eine Model-Extraktion. Nutze es zum Lesen, niemals für Zitate.
„Ich kenne dieses Paper / Kapitel"	Tests produzierten falsche Titel, falsche Bücher und ein nicht existierendes Paper aus dem Gedächtnis. Schlage es zuerst nach.
„Der DOI löst auf, also ist das Kapitel richtig"	Prüfe auch Buchtitel und Seitenzahlen.
„Blockiert, ich probiere einen Mirror"	Niemals. Finde eine legitime Green Copy, sonst liste es für den Benutzer auf.
„Ich schreibe das Ledger am Ende"	Ein Kontext-Reset löscht es. Schreibe während der Arbeit.
„Drei Studien stimmen überein"	Zähle unabhängige Studien; suche nach denen, die anders aussahen.