rainearcher/quiver

Perplexity Deep Research

Rufen Sie die Perplexity Agent API (POST /v1/agent) auf, um mehrstufige Browsing-Recherche mit Quellenangaben durchzuführen. Vor dem API-Aufruf erfordert dieses Skill eine strukturierte Aufnahme- und Plan-Genehmigungsschleife, damit der Agent die richtigen Quellen verwendet, den richtigen Kontext hat und einen Bericht in einem überfliegbaren Format zurückgibt.

Methodik

Dieses Skill ist eine programmatische Umsetzung des Growth-Unhinged-Deep-Research-Playbooks für GTM: https://www.growthunhinged.com/p/deep-research-for-gtm. Die fünf Empfehlungen des Artikels sind 1:1 auf die folgenden Schritte abgebildet:

Artikel-Empfehlung	Umgesetzt durch
Umfassenden Kontext bereitstellen (Ziel, GTM/Produkt, Einschränkungen, bevorzugte Quellen)	Schritt 1 – Aufnahme in fünf Dimensionen
Zuerst einen Forschungsplan anfordern, dann vor der Ausführung genehmigen	Schritt 2 – Plan-Genehmigungs-Gate (keine API-Ausgaben ohne Genehmigung)
Auf qualitativ hochwertige Quellen verweisen; Primärquellen vor Sekundärquellen bevorzugen; alles zitieren	Format-Block – Quellentabelle, Primärquellen-Priorität, Inline-Zitate erforderlich
Berichtsformat festlegen; Zusammenfassungen und Tabellen vor Prosa (Pyramidenprinzip)	Format-Block – TL;DR zuerst, Vergleichstabellen, Schlussfolgerungen vor Hintergrund
Den Prompt strukturieren (<goal>, <context>, <sources>, <instructions>)	--instructions-Block-Layout

Der Output-Budget-Check pro Aufruf (Schritt 2.5) und die sequenzielle Mehrfachaufruf-Planung (Schritt 2.6) sind Ergänzungen zum Artikel, um den stillen Trunkierungsfehlermodus zu verhindern, der bei großen GTM-Plänen (Hook-Bibliotheken, 30-Tage-Kalender, Anbieter-Matrizen) regelmäßig auftritt.

Voraussetzungen

• PERPLEXITY_API_KEY muss in der Umgebung verfügbar sein (einen erhalten Sie unter https://www.perplexity.ai/account/api)
• curl und jq müssen installiert sein

Führen Sie den Preflight-Check einmalig bei der ersten Verwendung aus, um zu überprüfen, ob alles eingerichtet ist:

bash ./scripts/check-setup.sh

Er gibt ✓/✗ für jede Anforderung und einen Kopier-Einfügen-Fix für alles, was fehlt. Exit 0, wenn alles bereit ist. Wenn ein Check fehlschlägt, zeigen Sie die Ausgabe dem Benutzer an und stoppen Sie – versuchen Sie nicht, das API-Skript auszuführen, bis der Preflight bestanden ist.

Wann verwenden

• Benutzer fragt explizit nach "Deep Research", "Advanced Research" oder "Perplexity Research"
• Benutzer benötigt eine quellenbasierte Zusammenfassung (Unternehmen, Person, Ereignis, Technologie, Regulierung)
• Fragen, die mehrstufiges Browsen und Synthese über viele Quellen hinweg erfordern
• Fragen, die sehr aktuelle Informationen mit Inline-Zitaten erfordern

NICHT verwenden für:

• Einfache Faktenabfragen ("Was ist der aktuelle Preis von X") – stattdessen WebSearch / WebFetch verwenden (günstiger, schneller)
• Einfache binäre Vergleiche ("Ist Tool A oder B besser") – eine einzelne WebSearch-Runde reicht normalerweise aus
• Authentifizierte oder Paywall-Inhalte (Perplexity kann sich nicht einloggen)
• Schnelle Code-Änderungen oder Fragen, die aus der Codebasis beantwortet werden können – Inline ist schneller
• Überprüfung einer bestimmten Tatsache, zu der Sie bereits Kontext haben – WebFetch ist präzise genug

Workflow (VERPFLICHTEND – Schritte nicht überspringen)

Deep-Research-Aufrufe kosten echtes Geld und dauern 2–5 Minuten. Ein schlechter Aufruf verschwendet beides. Befolgen Sie immer diese Schleife:

Schritt 0 – Setup überprüfen (nur beim ersten Durchlauf)

Wenn dies der erste Aufruf im Projekt ist, führen Sie bash ./scripts/check-setup.sh aus und fahren Sie nur fort, wenn der Exit-Code 0 ist. Wenn ein fehlendes Tool oder ein nicht gesetzter Schlüssel gemeldet wird, zeigen Sie die Lösung an und stoppen Sie. Diesen Schritt bei nachfolgenden Durchläufen in derselben Sitzung überspringen.

Schritt 1 – Die ursprüngliche Anfrage prüfen, dann NACH dem fragen, was fehlt

Lesen Sie zuerst die ursprüngliche Anfrage des Benutzers und bestimmen Sie, welche der fünf Kontextdimensionen unten bereits beantwortet sind, welche teilweise beantwortet sind und welche vollständig fehlen. Fragen Sie nicht erneut nach Dingen, die der Benutzer Ihnen bereits mitgeteilt hat.

Die fünf Dimensionen:

1. Ziel & Motivation – was sie erreichen wollen, wie die Ausgabe verwendet wird (Entscheidung, Dokument, Pitch, Strategie), bereits durchgeführte Vorarbeiten.
2. Produkt-/Situationskontext – das Unternehmen/Produkt/die Rolle, wie es funktioniert, relevante Setup-Details (Größe, Stadium, GTM, Zielgruppe).
3. Einschränkungen – Budget, Fristen, Personalbestand, rechtliche/Compliance-Auflagen, ausgeschlossene Optionen, No-Gos.
4. Bevorzugte Quellen – benannte Experten/Ersteller, Publikationstypen (wissenschaftlich, Primär-/Regierungsdaten, Foren, Analysten, SEC-Einreichungen, GitHub usw.), erlaubte vs. blockierte Domains, Aktualitätsfenster.
5. Umfangsgrenzen – was explizit nicht zum Umfang gehört, Annahmen, die der Agent NICHT treffen soll.

Entscheiden Sie, ob Sie fragen:

• Wenn alle fünf Dimensionen ausreichend beantwortet sind → Klärung überspringen und direkt zu Schritt 2 (Plan entwerfen) gehen. Stellen Sie keine Fragen, nur um zu bestätigen, was Sie bereits wissen.
• Wenn eine oder mehrere Dimensionen fehlen oder mehrdeutig sind → Verwenden Sie AskUserQuestion, um nur nach den Lücken zu fragen, in einem einzigen konsolidierten Block. Listen Sie explizit auf, was Sie bereits verstanden haben (damit der Benutzer Sie korrigieren kann) und was Sie noch benötigen.
• Wenn der Benutzer sagt "Einfach los" / "Vertraue deinem Urteil" → gehen Sie zu Schritt 2 und listen Sie Ihre Annahmen für jede fehlende Dimension im Plan auf, damit der Benutzer sie dort noch korrigieren kann.

Tendieren Sie zu weniger Fragen. Eine gut spezifizierte einleitige Anfrage benötigt oft keine Klärung – gehen Sie direkt zum Plan.

Schritt 2 – Einen Forschungsplan entwerfen und genehmigen lassen

Vor dem API-Aufruf erstellen Sie einen Forschungsplan in Ihrer Antwort und bitten Sie den Benutzer, ihn zu genehmigen oder zu bearbeiten. Der Plan muss Folgendes enthalten:

• Forschungsfragen – die spezifischen Unterfragen, die der Agent beantworten wird
• Methodik – wie es Optionen bewerten/vergleichen wird, welchen Rahmen es verwendet
• Quellenstrategie – welche Quellentypen priorisiert werden, welche vermieden werden, etwaige Domain-Filter oder Aktualitätsfenster
• Berichtsstruktur – Abschnittsüberschriften, die der endgültige Bericht verwenden wird
• Liefergegenstände – gibt es über Prosa hinaus Tabellen, Vergleichsmatrizen, Vorlagen, Checklisten, Code-Snippets?
• Offene Annahmen – alles, worüber Sie raten und das der Benutzer korrigieren sollte

Warten Sie auf ausdrückliche Genehmigung ("sieht gut aus", "los", "führe es aus", Änderungen am Plan usw.), bevor Sie fortfahren. Wenn der Benutzer den Plan bearbeitet, bestätigen Sie vor der Ausführung erneut.

Schritt 2.5 – Ausgabebudget-Check (VERPFLICHTEND – verhindert Trunkierung)

Das advanced-deep-research-Preset hat eine praktische Ausgabeobergrenze von etwa ~16k Tokens / ~10k Wörtern pro Antwort. Pläne, die diese Grenze überschreiten, werden stillschweigend abgeschnitten – im Inhaltsverzeichnis aufgeführte Abschnitte erscheinen einfach nicht, und große Liefergegenstände (Hook-Bibliotheken, N-Tage-Kalender, Anti-Pattern-Kataloge) werden mitten in der Tabelle abgeschnitten. Sie MÜSSEN vor der Ausführung ein Budget gegen diese Obergrenze kalkulieren.

Ausgabebudget pro Aufruf (harte Grenzen):

Element	Max pro Aufruf
Hauptabschnitte (H2)	8
Große Tabellen (6+ Zeilen, 4+ Spalten)	4
Aufgelistete Bibliotheken/Kataloge (Hooks, Vorlagen, Beispiele, Ideen)	10 Elemente insgesamt über alle Bibliotheken
Langformatige Liefergegenstände (N-Tage-Kalender, Shot-by-Shot-Skripte, vollständige Playbooks)	1
Gesamtprosa (ohne Tabellen)	~4.000 Wörter

Rote Flaggen, die bedeuten, dass Ihr Plan für einen Aufruf zu groß ist:

• Inhaltsverzeichnis hat >8 Abschnitte
• Plan verspricht "25+ Hooks" / "30-Tage-Kalender" / "20 Vorlagen" zusammen mit mehreren Matrizen
• Plan fordert mehrere große Liefergegenstände im selben Aufruf an (z.B. Hook-Bibliothek UND Content-Kalender UND Shot-by-Shot-Vorlage UND Anti-Pattern-Katalog)
• Plan deckt >1 unterschiedliche Zielgruppensegmente oder >1 unterschiedliches Ziel in der Tiefe ab

Wenn der Plan ins Budget passt → fahren Sie mit Schritt 3 fort.

Wenn der Plan das Budget überschreitet → teilen Sie ihn in einen sequenziellen Mehrfachaufruf-Plan auf (siehe "Mehrfachaufruf-Planung" unten) und präsentieren Sie diesen dem Benutzer zur Genehmigung.

Schritt 2.6 – Mehrfachaufruf-Planung (für große Umfänge ODER abhängige Forschung)

Es gibt zwei separate Gründe, um in mehrere sequenzielle Aufrufe aufzuteilen, und beide verwenden dieselbe Mechanik:

(A) Budgetgetriebene Aufteilung – der Plan überschreitet die Ausgabeobergrenze pro Aufruf aus Schritt 2.5. Teilen Sie in fokussierte Aufrufe auf, jeder mit EINEM primären Liefergegenstand.

(B) Abhängigkeitsgetriebene Aufteilung – Der Umfang von Aufruf N hängt von den Ergebnissen von Aufruf N-1 ab. Beispiel: Eine Landschaftserhebung von Anbietern (Aufruf 1) bestimmt, welche 3 Anbieter Deep Dives erhalten (Aufrufe 2–4). Hier geht es nicht um die Größe – sondern darum, dass spätere Aufrufe auf das reagieren können, was frühere Aufrufe zutage fördern. Versuchen Sie nicht, alles im Voraus zu planen, wenn Sie die Antwort nicht kennen, bevor Sie Aufruf 1 ausgeführt haben.

Regeln für jede Mehrfachaufruf-Aufteilung:

1. Führen Sie Aufrufe sequenziell aus, nicht parallel – jeder Aufruf sollte auf vorherige Ausgaben verweisen oder darauf aufbauen können.
2. Jeder Aufruf muss EINEN primären Fokus auf einen Liefergegenstand haben.
3. Jeder Aufruf muss innerhalb des Budgets pro Aufruf aus Schritt 2.5 bleiben.
4. Jeder Aufruf muss einzeln wertvoll sein – erstellen Sie keine Aufrufe, die nur in Kombination Sinn ergeben.
5. Fügen Sie in die --instructions jedes nachfolgenden Aufrufs die wichtigsten Ergebnisse aus vorherigen Aufrufen ein (nicht den vollständigen Bericht – nur die tragenden Schlussfolgerungen, ~200–400 Wörter) unter einer PRIOR FINDINGS (do not re-research)-Überschrift, damit der Agent keine Schritte verschwendet, um bereits Abgedecktes noch einmal zu recherchieren.
6. Nach Abschluss jedes Aufrufs Read die Ausgabe, überprüfen Sie, ob nichts abgeschnitten wurde (prüfen Sie, ob jeder Abschnitt im Inhaltsverzeichnis des Aufrufs vorhanden ist und keine Tabellen mitten in einer Zeile enden), und fassen Sie es dem Benutzer kurz zusammen, bevor Sie den nächsten Aufruf starten.

Präsentieren Sie die Aufteilung wie folgt:

Dieser Plan benötigt N sequenzielle Aufrufe, weil <Budget-/Abhängigkeitsgrund>:
  Aufruf 1 – <Fokus>  (~$X, ~3 Min)
  Aufruf 2 – <Fokus>  (~$X, ~3 Min)
  ...
Geschätzte Gesamtkosten: $X. Genehmigen Sie die Aufteilung oder sagen Sie mir, was gestrichen werden soll.

Warten Sie vor der Ausführung eines Aufrufs auf die ausdrückliche Genehmigung der Aufteilung. Wenn der Benutzer die Aufteilung bearbeitet, bestätigen Sie erneut.

Schritt 3 – Die Forschung durchführen

Nach der Genehmigung rufen Sie das Skript auf. Übergeben Sie den genehmigten Plan + Kontext + Formatanforderungen über --instructions. Verwenden Sie die Flags --domains und --recency, wenn der Benutzer sie angegeben hat.

Übergeben Sie immer --topic <slug>, damit die Ausgabe in einem Themen-Unterverzeichnis unter ./docs/research/ landet. Überprüfen Sie vor dem Aufruf die vorhandenen Unterverzeichnisse (ls docs/research/) und verwenden Sie entweder einen vorhandenen Slug, der zum Forschungsbereich passt, oder erstellen Sie einen neuen kurzen Kebab-Case-Slug. Wenn Sie ein neues Thema erstellen, wählen Sie etwas Dauerhaftes – einen Slug, den Sie auch für die nächsten 3–5 Berichte im selben Bereich verwenden würden, keine einmalige Phrase aus der aktuellen Frage. Gute Slug-Formen: vendor-comparison, competitor-analysis, regulation-update, <product-area>. Schlechte Slug-Formen: doppler-vs-vault-2026 (zu spezifisch und datumsabhängig).

Das Skript befindet sich unter ./scripts/research.sh (relativ zu dieser SKILL.md). Wenn es von einem Agenten aufgerufen wird, verwenden Sie diesen relativ zum Skill angegebenen Pfad – er wird sowohl bei npx skills-Installationen als auch bei Claude Code /plugin-Installationen korrekt aufgelöst.

bash ./scripts/research.sh \
  --preset advanced-deep-research \
  --output ./docs/research \
  --topic <topic-slug> \
  --instructions "$(cat <<'EOF'
<fügen Sie hier den genehmigten Plan + Kontext + Formatanforderungen ein>
EOF
)" \
  "<die Forschungsfrage, verfeinert aus dem genehmigten Plan>"

Schritt 4 – Den Bericht lesen und zusammenfassen

Das Skript gibt den Markdown-Pfad aus. Read Sie diese Datei immer, bevor Sie Bericht erstatten.

Trunkierungsprüfung (obligatorisch):

1. Bestätigen Sie, dass jeder Abschnitt, der im eigenen Inhaltsverzeichnis des Berichts aufgeführt ist, tatsächlich im Textkörper vorhanden ist.
2. Bestätigen Sie, dass keine Tabelle mitten in einer Zeile und keine Aufzählungsliste mitten in einem Element endet.
3. Bestätigen Sie, dass die Abschnitte "Quellen", "Wo Quellen sich widersprechen" und "Vertrauen & Lücken" am Ende vorhanden sind.

Wiederherstellungs-Workflow bei Trunkierung. Wenn einer dieser Punkte fehlt → wurde die Ausgabe abgeschnitten. Gehen Sie wie folgt vor:

1. Identifizieren Sie genau, was fehlt. Vergleichen Sie das Inhaltsverzeichnis des Berichts mit seinem Textkörper. Listen Sie die fehlenden Abschnitte, unvollständigen Tabellen (notieren Sie die letzte vollständige Zeile) und abgeschnittenen Listenelemente (notieren Sie das letzte vollständige Element) auf.
2. Quantifizieren Sie die verbleibende Arbeit. "X Abschnitte, Y Elemente, Z Zeilen werden noch benötigt."
3. Schlagen Sie einen fokussierten Folgeaufruf mit einem Umfang vor, der in das Budget pro Aufruf passt. Versuchen Sie NICHT, denselben Umfang erneut – er wird wieder abgeschnitten.
4. Fügen Sie PRIOR FINDINGS in die --instructions des Folgeaufrufs ein – fügen Sie eine ~200–400-Wörter-Zusammenfassung der abgeschlossenen Abschnitte ein, damit der Agent sie nicht noch einmal recherchiert. Sagen Sie explizit "Decken Sie X, Y, Z nicht erneut ab; konzentrieren Sie sich nur auf A, B, C."
5. Teilen Sie dem Benutzer mit, was abgeschnitten wurde, und zeigen Sie den Folgeplan, bevor Sie ihn ausführen.

Geben Sie an: Wichtige Erkenntnisse, die USD-Kosten aus dem Bericht, etwaige bemerkenswerte Quellenkonflikte und gegebenenfalls eine Trunkierungsmarkierung.

Leistungsstarke Muster

Diese Muster verbessern zuverlässig die Ausgabequalität. Verwenden Sie sie in Schritt 2 beim Entwerfen des Plans.

Zitieren Sie spezifische Experten oder Frameworks in Ihrer Anfrage

Die Nennung von 3–6 relevanten Experten, Autoren, Erstellern oder benannten Frameworks in der Anfrage gibt dem Agenten konkrete Quellen, nach denen er suchen und die er vergleichen kann. Der Bericht wird zu einem Vergleich bekannter Standpunkte und nicht zu einer anonymen Synthese.

Beispiel-Anfragefragmente:

• "Vergleichen Sie die Frameworks, die von , und für ... verwendet werden"
• "Gemäß der Methodik von bewerten Sie ..."
• "Gleichen Sie die Ansätze ab, die von (in <Buch/Blog>) vs. empfohlen werden ..."

Funktioniert am besten, wenn die Experten regelmäßig veröffentlichen (Papiere, Videos, Beiträge, Vorträge) – der Agent kann ihr Primärmaterial abrufen.

Quantifizierte Liefergegenstände angeben

Anstatt nach "einer guten Anzahl von Beispielen" zu fragen, geben Sie die genaue Anzahl und Form an. Dies schließt den Umfang ein, verhindert Abweichungen und zeigt an, wenn Sie über dem Budget liegen (Querverweis zu Schritt 2.5).

Gute Liefergegenstands-Spezifikationen:

• "Eine Vergleichsmatrix: 8 Zeilen (einer pro Anbieter), 5 Spalten (Preis, Latenz, Authentifizierung, SDKs, Compliance)"
• "Eine Bibliothek mit genau 10 Vorlagen, gruppiert in 3 Kategorien"
• "Eine 14-Tage-Sequenz mit einem Eintrag pro Tag"

Vermeiden Sie: "eine umfassende Bibliothek", "mehrere Beispiele", "viele Optionen" – das sind Einladungen zur Trunkierung oder zum Schwanken.

Kontext in --instructions vorladen, nicht in der Anfrage

Die Anfrage sollte eine knappe 1–2-Satz-Phrase bleiben. Alles über die Situation des Benutzers, Einschränkungen, frühere Entscheidungen oder Quellenpräferenzen kommt in --instructions. Dadurch bleiben die Suchanfragen des Agenten fokussiert, während die Synthese in Ihrem Kontext verankert bleibt.

Erforderliche Formatanweisungen (immer in --instructions einfügen)

Jeder Durchlauf muss diese Formatanforderungen in die --instructions-Zeichenfolge einbetten, damit der Bericht überfliegbar und vertrauenswürdig ist:

UMFANGS- & GRÖSSENBESCHRÄNKUNG (zuerst lesen – dieser Bericht darf ~4.000 Wörter Text (ohne Tabellen) und insgesamt 8 Hauptabschnitte (H2) nicht überschreiten. Wenn die Antwort länger ist, priorisieren Sie: TL;DR, dann Schlussfolgerungen, dann Kernanalyse, dann Hintergrund. Jeder Abschnitt jenseits von 8 oder Wörter jenseits von ~4.000 wird stillschweigend abgeschnitten.)

TL;DR (oben):
- Ein kurzer Absatz, der die Antwort auf die Forschungsfrage zusammenfasst.
- Eine Liste der 3–5 wichtigsten Ergebnisse mit Emoji-Markern.

HINTERGRUND & KONTEXT (wenn nötig):
- Kurzer einleitender Kontext (ein Absatz) – NICHT "Ground einchecken" aus der Anfrage wiederholen.

ANALYSE / ERGEBNISSE:
- Verwenden Sie nach Möglichkeit Tabellen anstelle von Absätzen.
- Verwenden Sie für jedes Thema einen eigenen Abschnitt (H2).
- Nähern Sie sich allen Themen unvoreingenommen.
- Wenn die Quellen sich widersprechen, halten Sie die widersprüchlichen Ansichten fest (

…

[truncated for translation]