Das hast du am Ende dieses Moduls
Am Ende dieses Moduls hast du eine Aussage in deinem eigenen Projekt, die du auf eine gespeicherte, datierte Quelle zurückführen kannst, und eine Ordnerstruktur, die du wiederverwenden kannst, wenn etwas das nächste Mal geprüft statt geraten werden soll.
Dieses Modul ist optional und folgt auf Von der Idee zum Beleg. Es nimmt die Gewohnheit „erst recherchieren, dann bauen“ aus dem Core und macht daraus etwas, das eine zweite Person prüfen kann, ohne dich zu fragen.
Es läuft nach derselben Disziplin wie ein wiederkehrender Ablauf oder ein aufgeteilter Build: benannter Scope, aufbewahrte Belege, ein Reviewer, der die Dateien öffnet.
Optional: Den Kurs schließt der Core plus der Übernahmetest des Hubs ab.
Was dieses Modul vermittelt
- Was die Evidenz zu vielen Agents gegenüber einem sagt
Zwei Studien, ehrlich zitiert für das, was sie tatsächlich gemessen haben, nicht für das, was gerade bequem wäre. Eine Studie zu klinischer AI von Mount Sinai (npj Health Systems, März 2026) fand, dass orchestrierte Multi-Agent-Setups langsamer nachlassen als ein einzelner Agent, wenn gleichzeitige klinische Aufgaben von 5 auf 80 wachsen. Das ist eine Aussage über Koordinationsaufwand im Verhältnis zum Aufgabenvolumen, kein Claude-Code-Benchmark. Ein Paper von Google Research, Google DeepMind und MIT (arXiv:2512.08296, Dezember 2025) testete 260 Konfigurationen über sechs Benchmarks und fand Gewinne bei parallelisierbaren Aufgaben, Verluste bei sequenziellen. Zusammen stützen sie eine enge Aussage: Ob man auf viele Agents auffächert, hängt von der Struktur der Aufgabe ab, nicht davon, dass mehr Agents immer besser wären. - Das Briefing mit Bestehenstest
„Recherchiere alle Wettbewerber“ ist kein Scope: Es ist ein Thema im Scope-Kostüm. Ein echtes Briefing nennt das Ziel in einem Satz, nennt die Items beim Namen, legt fest, was jeder Agent speichern muss und wo, sagt, welche Quellen erlaubt und welche verboten sind, und endet mit einem Bestehenstest, der sich an den Dateien selbst prüfen lässt. Kein Briefing, keine Agents. - Ein Agent pro benanntem Item
Nie ein Agent, der eine ganze Liste abdecken soll. Jeder Agent bekommt das Ziel, sein eigenes einzelnes Item, sein Ergebnis, die erlaubten und verbotenen Quellen, die Tiefe, den Bestehenstest und den genauen Ordner zum Speichern. Eine Liste, die ein Agent bekommt, wird überflogen; eine Liste, die in benannte Einzelaufträge geteilt wird, wird geprüft. - Rohbelege unverändert aufbewahren
Jeder Agent speichert, was er gefunden hat, so wie gefunden, in einer datierten, benannten Datei: nie eine Paraphrase, nie eine Zusammenfassung als Ersatz für die Quelle. Wo eine Quelle nicht erreichbar ist, gibt es ein datiertes Protokoll des Versuchs, keine Vermutung im Gewand eines Befunds. So lässt sich ein späterer Widerspruch prüfen: Die Rohdatei ist noch da und kann neu gelesen werden. - Zwei Review-Stopps
Stopp 1 prüft die Rohdaten selbst, bevor etwas ausformuliert wird: jedes benannte Item vorhanden oder protokolliert, jede behauptete Datei tatsächlich auf der Platte, nichts erfunden. Stopp 2 prüft den fertigen Bericht gegen dieselben Rohdateien und hinterfragt die Argumentation. Beide Stopps lesen die Dateien, nicht die Zusammenfassungen der Agents davon: Eine Zusammenfassung kann auf eine Weise falsch sein, wie es eine Quelldatei nicht sein kann. - Die README als Papierspur
Eine Datei trägt die Ordnerkarte, die Statusblöcke beider Stopps und ein datiertes Log: es wird ergänzt, nie neu geschrieben. Wer an Tag neun als Reviewer dazukommt, soll mit dieser einen Datei genau wissen, was geprüft ist, was offen ist und was unterwegs überstimmt wurde, ohne jemanden zu fragen.
Die Aufgabe
Für dieses Modul gibt es keinen neuen Snapshot: Das Referenzprojekt endet bei Core 3. Dein eigenes Projekt steht stellvertretend dafür.
Ausgangspunkt
Dein eigenes Projekt plus eine Aussage, ein Vergleichspunkt oder ein Wettbewerbsfakt, den du noch nie wirklich gegen eine Quelle geprüft hast.
Ergebnis
Ein nachvollziehbarer Recherche-Ordner für dieses eine Item: ein Briefing mit Bestehenstest, die unverändert gespeicherte Rohquelle, eine geprüfte Erkenntnis, die ihre Herkunft nennt, und eine README als Papierspur.
Bestanden, wenn
Jede Aussage in deinem Ergebnis auf eine gespeicherte Rohquelle zurückführt, jede Lücke als UNAVAILABLE markiert ist statt stillschweigend gefüllt, und ein Reviewer, der nur die Dateien öffnet (nicht deine Zusammenfassung davon), zum selben Schluss kommt wie du.
Ein Agent oder viele, ehrlich dargestellt
Beide Studien sind Belege für eine enge Aussage und nicht mehr. Keine ist eine Claude-Code-Messung, und keine wird hier als solche zitiert.
| Studie | Was sie tatsächlich gemessen hat | Was sie stützt |
|---|---|---|
| Mount Sinai, npj Health Systems (Nature), März 2026 | Klinische Aufgaben zu Retrieval, Extraktion und Dosierung. Orchestrierte Multi-Agent-Setups lassen langsamer nach als ein einzelner Agent, wenn gleichzeitige Aufgaben von 5 auf 80 wachsen. | Koordinationsaufwand und Aufgabenvolumen beeinflussen sich. Kein Claude-Code-Benchmark. |
| Google Research / Google DeepMind / MIT, arXiv:2512.08296, Dezember 2025 | 260 Konfigurationen über sechs Benchmarks. Gewinne bei parallelisierbaren Aufgaben, Verluste bei sequenziellen. | Die Entscheidung zum Auffächern hängt von der Struktur der Aufgabe ab. |
Gestützt: Ob viele Agents oder einer, hängt von der Struktur der Aufgabe ab. Nicht gestützt: jede Claude-Code-Leistungszahl. Die Regel, der dieses Modul so oder so folgt (ein Agent pro benanntem Item), stammt aus dem, was Recherche überprüfbar macht, nicht aus einer der beiden Studien.
Der Claude-Code-Recherche-Skill in der Anwendung
Drei echte Dateien, kein Snapshot: der Skill und seine beiden Templates, so wie sie hier laufen. Die einzige Änderung für die Veröffentlichung: Die Review-Schritte nennen einen zweiten Reviewer auf einem anderen Modell statt eines bestimmten Tools.
Das Ordner-Template
Jedes Projekt nutzt dieses, ohne Abweichungen. Ein Ordner, der dieselbe Aufgabe unter anderem Namen erfüllt, wird in den passenden zusammengeführt: Dateinamen ändern sich nie.
docs/
README.md paper trail: folder map, stop status, dated log
01_raw_data/
context/ brief, and anything the client provided to explain the work
research/ our external research, saved untouched
sandbox_data/ client data and what we pull (exports, API dumps, samples)
02_verified_insights/ checked findings and reports
03_assets/ Claude Design, prototypes, decksDas Briefing mit seinem Bestehenstest
Kein Briefing, keine Agents. „Recherchiere alle Wettbewerber“ ist kein Scope: Frag nach den Namen.
# Brief: <topic>
- date: YYYY-MM-DD
- requested by:
## Goal
One question, in one sentence. Example: which task-management tools let a small team export its project data.
## Scope
Named items, one agent each. Example: Trello, Asana, Linear.
## Deliverables
- Raw: what each agent must save, and where (`01_raw_data/research/`)
- Verified: the fields every item must end up with (`02_verified_insights/`)
- Output: the report, and who reads it
## Tools
Which tools agents may use.
## Sources
- Allowed:
- Banned:
## Amount
How many sources per item.
## Depth
Snapshot of the page, or the full document.
## Pass test
What "done" means, checkable on the files. Example: every named item has a saved
source document or a dated log of the failed attempt, and every verified field is
filled or marked UNAVAILABLE.Ein Agent pro benanntem Item, Rohbelege aufbewahrt
Jeder Agent bekommt das Ziel, sein eigenes einzelnes Item, sein Ergebnis, die erlaubten und verbotenen Quellen, die Tiefe, den Bestehenstest und den genauen Ordner zum Speichern. Er speichert das Quellmaterial unverändert, benannt nach <source>__<subject>__<topic>__YYYY-MM-DD.ext, und protokolliert das Item als aufgenommen mit seiner Datei oder ausgeschlossen mit einem quellenbasierten Grund. Eine Quelle, die nicht erreichbar war, bekommt ein datiertes Protokoll des Versuchs: nie eine Vermutung.
Zwei Review-Stopps und ein erneuter Lauf, der Abweichungen markiert
Stopp 1 prüft die Rohdateien: jedes benannte Item vorhanden oder protokolliert, jede behauptete Datei auf der Platte, nichts erfunden. Nichts wandert nach 02_verified_insights/, bevor dieser Stopp klar ist. Stopp 2 prüft den fertigen Bericht gegen dieselben Rohdateien und hinterfragt die Argumentation. Dazwischen läuft dasselbe Briefing noch einmal in einem frischen Agent: Mehr als 10 % Abweichung zwischen den beiden Läufen wird im Bericht festgehalten, nicht glattgebügelt.
# <project or topic> research
Workflow: `01_raw_data -> STOP 1 REVIEW -> 02_verified_insights -> STOP 2 CHALLENGE -> final`
## Stop 1: raw data review
```text
status: NOT_STARTED | READY_FOR_REVIEW | ISSUES_FOUND | CLEAR
reviewer_result:
second_reviewer_result:
submitted_on:
decision_on:
```
### Review notes
Added to, never rewritten. One section per pass, dated, with the verdict and the rework list.
## Stop 2: challenge
```text
status: NOT_STARTED | IN_PROGRESS | CLEAR
second_reviewer_result:
submitted_on:
decision_on:
```
## Decisions and overrides
Dated. What was decided, by whom, and the trade-off accepted.
## Log
- YYYY-MM-DD: what happened.Häufige Fehler
| Fehler | Lösung |
|---|---|
| Agents mit einem Thema statt mit Ziel, Scope und Bestehenstest losgeschickt | Schreib jedes Mal zuerst das Briefing. |
| Ein Agent soll die ganze Liste abdecken | Ein Agent pro benanntem Item. |
| Befunde direkt in den Berichtsordner geschrieben | Nichts kommt in 02_verified_insights/, bevor beide Stopps CLEAR sind. |
| Reviewer liest die Zusammenfassungen der Agents | Der Reviewer öffnet die Dateien. |
| Eine Lücke stillschweigend aus einem nahen Fakt gefüllt | Als UNAVAILABLE markieren, plus ein datiertes Protokoll des Versuchs. |
Jede Aussage auf eine Quelle zurückführen
Der kostenlose Recherche-Skill, das Ordner-Template, das er füllt, und die Reviewer-Prompts, die die gespeicherten Dateien prüfen statt der Zusammenfassungen.
Eine Aussage ohne etwas dahinter
„Replit is SOC 2 compliant.“
Wahr oder nicht, niemand kann es prüfen, ohne die Suche zu wiederholen, und nichts sagt, ob es das Produkt oder das Unternehmen dahinter abdeckt.
Dieselbe Aussage, nachvollziehbar
| Was der Skill festhält | |
|---|---|
| Zitat | Der Satz, wortwörtlich von der eigenen Seite des Tools kopiert, keine Zusammenfassung davon. |
| Quelle | Der Link, von dem er stammt, und das Datum der Prüfung. |
| Geltungsbereich | „Covers the builder: stated / not stated“, denn ein Zertifikat, das das Unternehmen hält, deckt das Produkt nicht automatisch ab. |
| Lücken | Zwei Seiten ließen sich nicht laden. Sie wurden als ungelesen markiert statt aufgefüllt, und das Review hat gemerkt, dass eine davon doch lesbar war. |
Mehr dazu
- Core 3 wendet dieselbe Gewohnheit „erst prüfen, dann bauen“ auf einen einzelnen Build an
- Core 2 behandelt die dev-docs-Konvention, neben der die README-Papierspur dieses Moduls steht
- Specialist 4 macht aus einem wiederholten Ablauf wie diesem einen eigenen Skill
- Specialist 5 teilt unabhängige Arbeit auf, so wie dieses Modul die Recherche-Agents aufteilt
