Home | Blog | Guide

Cross-Tool-Suche: Warum die Codebase der falsche Ort ist

Die meisten Entwicklerentscheidungen leben außerhalb des Codes. So bauen Sie eine Tool-übergreifende Suche über Slack, Linear, GitHub und Notion.

By Ellis Keane · 2026-03-17

Ihre Codebase ist der nutzloseste Ort, um nach dem Grund einer Entscheidung zu suchen.

Ich weiß, das klingt verkehrt. Wir verbringen Jahre damit, ripgrep-Flags zu lernen, IDE-Suchen zu konfigurieren, Regex-Muster zu memorieren – und nichts davon hilft, wenn die Frage nicht „Wo ist diese Funktion?" lautet, sondern „Warum haben wir diesen Ansatz gegenüber den drei besprochenen Alternativen gewählt?" Die Antwort auf diese zweite Frage steht fast nie im Code. Sie steckt in einem Slack-Thread von vor vier Monaten, einem Linear-Kommentar, der unter Statusupdates begraben wurde, einem Notion-Dokument, das jemand angefangen und nie beendet hat, und einem PR-Review, in dem die eigentliche Debatte in einer Antwort auf eine Antwort auf eine Antwort stattfand.

Das ist das Tool-übergreifende Suchproblem für Entwickler – Entscheidungskontext ist auf Tools ohne einheitlichen Abfragepfad verteilt. Wir haben Suchen, die innerhalb der einzelnen Tools gut funktionieren – Slacks Suche ist ordentlich, GitHubs Code-Suche ist ausgezeichnet, Linear hat Filter für alles – aber nichts, das über alle hinweg sucht. Die Entscheidungen, die Ihre Architektur geprägt haben, leben an fünf verschiedenen Orten, und von Ihnen wird erwartet, dass Sie sich erinnern, wo Sie suchen müssen.

Also gut – so bauen Sie eine Tool-übergreifende Suche mit dem, was Sie bereits haben. Keine neuen Tools nötig (nun ja, fast – ich werde am Ende einen erwähnen, aber das hier funktioniert auch ohne ihn).

Die Anatomie einer verstreuten Entscheidung

Lassen Sie mich etwas Konkretes durchgehen. Letztes Jahr entschieden wir uns zwischen BullMQ und Temporal für unsere Job-Queue. Hier lebte diese Entscheidung tatsächlich:

Slack (#engineering): Drei separate Threads über zwei Tage. Der erste war ein Link, den jemand zu einem Temporal-Blogbeitrag geteilt hatte. Der zweite war eine Debatte darüber, ob wir durable execution benötigten. Der dritte (eine Woche später, anderer Channel) war jemand, der fragte „Wart mal, haben wir das Queue-Thema schon entschieden?"
Linear: Ein Issue mit dem Titel „Evaluate job queue options" mit sechs Kommentaren, darunter eine Vergleichstabelle, die einer unserer Entwickler an einem Nachmittag erstellt hatte.
GitHub: Eine PR-Beschreibung für die BullMQ-Implementierung, die „as discussed" sagte, mit null Links dazu, wo es besprochen wurde.
Notion: Ein halbfertiger Architecture-Decision-Record, der die Vorteile von Temporal behandelte, aber nie mit der endgültigen Wahl aktualisiert wurde.
Google Docs: Meeting-Notizen eines Calls, bei dem wir die Entscheidung tatsächlich trafen, begraben in Aufzählungspunkten zwischen zwei nicht zusammenhängenden Tagesordnungspunkten.

Fünf Tools. Eine Entscheidung. Und hätten Sie in einem einzelnen Tool gesucht, hätten Sie ein Fragment gefunden – nie das vollständige Bild. Der PR sagt Ihnen, was wir gewählt haben. Die Slack-Threads sagen Ihnen, was wir in Betracht gezogen haben. Das Linear-Issue sagt Ihnen die Abwägungen. Das Notion-Dokument sagt Ihnen die halbe Begründung. Die Meeting-Notizen sagen Ihnen den Moment, in dem es finalisiert wurde.

Das ist nicht ungewöhnlich. Das ist irgendwie der Stand der Technik, wie Engineering-Teams Entscheidungen im Jahr 2026 verfolgen. Wir haben KI, die Code generiert, und Suchmaschinen, die das gesamte Internet indizieren – aber herauszufinden, warum Ihr Team BullMQ statt Temporal gewählt hat, erfordert das Prüfen von fünf Apps und die Hoffnung, dass jemandes Erinnerung standhält.

Was Tool-übergreifende Suche für Entwickler schwierig macht

Es ist kein API-Problem – jedes Tool, das wir verwenden, hat eine perfekt brauchbare Such-API. Das Problem ist seltsamer als das:

Unterschiedliche Datenstrukturen. Slack gibt Nachrichten mit Zeitstempeln und Channel-IDs zurück. Linear gibt Issues mit Zuständen und Labels zurück. GitHub gibt Commits, PRs und Code-Treffer in völlig unterschiedlichen Antwortformaten zurück. Diese in eine kohärente Zeitleiste zusammenzuführen erfordert eine Normalisierung, die niemand baut (weil es ehrlich gesagt die Art von Arbeit ist, die in Sprint-Demos nicht auftaucht).

Kontextfragmentierung. Eine Slack-Nachricht, die „Nehmen wir Option B" sagt, ist bedeutungslos ohne den Thread, der die Optionen A, B und C definiert hat. Aber Slacks Suche gibt einzelne Nachrichten zurück, keine Gesprächsbögen. Sie finden die Schlussfolgerung ohne die Begründung.

Zeitlicher Drift. Der Entscheidungsprozess erstreckt sich oft über Tage oder Wochen, mit Lücken, in denen nichts passierte, weil alle tief in anderen Aufgaben versunken waren. Eine Schlüsselwortsuche könnte den Anfang und das Ende eines Gesprächs aufzeigen, während die entscheidende Mitte fehlt – einfach weil in verschiedenen Phasen unterschiedliche Wörter verwendet wurden.

Tool-übergreifende Suche für Entwickler ist kein API-Problem – jedes Tool hat einen perfekt brauchbaren Such-Endpoint. Es ist ein Kontextproblem: Entscheidungen sind über Tools in inkompatiblen Strukturen verstreut, fragmentiert durch Gesprächsbögen und durch zeitlichen Drift getrennt. Schlüsselwortsuche findet Fragmente; nur verbundener Kontext findet das vollständige Bild.

Tool-übergreifende Suche mit dem Vorhandenen aufbauen

Hier kommt der praktische Teil. Für drei oder vier Tools mit reiner Lesezugriff-Suche rechnen Sie mit einem halben Tag, um eine MVP-Version zum Laufen zu bringen – der größte Teil davon für Auth-Setup und Antwortnormalisierung, nicht für die eigentliche Suchlogik.

API-Zugang einrichten

Sie benötigen Tokens für jedes Tool:

Slack: Ein User-Token mit search:read-Scope (Slacks Such-Methoden erfordern User-Tokens, keine Bot-Tokens – erstellen Sie diese über die Slack-API-Apps-Seite)
Linear: Ein persönlicher API-Schlüssel aus Einstellungen, dann API
GitHub: Ein fein abgestimmtes PAT mit Lesezugriff auf Ihre Repos
Notion: Ein internes Integrations-Token aus Einstellungen, dann Verbindungen

Das Fan-out-Abfrage-Skript

Das grundlegende Muster ist peinlich einfach – die gleiche Suchanfrage an jede API abfeuern und die Ergebnisse sammeln:

```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }

async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);

return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```

Jede search*-Funktion umschließt die jeweilige API. Für Slack ist das search.messages. Für Linear ist es eine GraphQL-Abfrage gegen ihre Suchfelder. Für GitHub ist es der REST-Such-Endpoint. Für Notion ist es der Such-Endpoint mit einem query-Parameter.

Normalisieren und Deduplizieren

Das Schwierige ist nicht die Suche – sondern die Ergebnisse nützlich zu machen. Sie sollten:

Zeitstempel normalisieren über Tools hinweg (Slack verwendet Unix-Epochs, Linear verwendet ISO-Strings, GitHub verwendet ISO mit Zeitzonenoffsets)
Verwandte Ergebnisse gruppieren – wenn derselbe Slack-Thread dreimal erscheint, weil drei Nachrichten übereinstimmen, zu einem Ergebnis mit der Thread-URL zusammenfassen
Nach Relevanz ranken – die meisten APIs geben ihre eigenen Relevanz-Scores zurück, aber diese sind nicht über Tools hinweg vergleichbar. Eine einfache Heuristik: exakte Schlüsselwort-Treffer in Titeln rangieren über Body-Treffern, und neuere Ergebnisse rangieren über älteren bei gleicher Relevanz

In einem CLI verpacken

Ich verwende Commander.js dafür (hauptsächlich aus Gewohnheit, aber alles funktioniert):

```bash $ cross-search "bullmq vs temporal"

Found 14 results across 4 tools:

[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...

[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342

[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289

[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```

Vierzehn Ergebnisse, nach Zeit sortiert, über vier Tools. Sie können den vollständigen Bogen der Entscheidung an einem Ort sehen: Das Notion-Dokument wurde zuerst gestartet, dann fand die Slack-Diskussion statt, dann wurde das Linear-Issue zur Verfolgung erstellt, und schließlich landete der PR eine Woche später.

Es wirklich gut machen

Die obige Grundversion funktioniert, hat aber einige frustrierende Ecken. So verbessern Sie sie:

Thread-Erweiterung für Slack. Wenn Sie eine passende Nachricht finden, rufen Sie den gesamten Thread mit conversations.replies ab. Die passende Nachricht könnte „Ja, nehmen wir BullMQ" sein – nicht nützlich ohne die vorhergehenden 40 Nachrichten der Debatte. Zeigen Sie einen Auszug des Threads an, nicht nur die passende Nachricht.

PR-Review-Kommentare. GitHubs Such-API zeigt keine Review-Kommentare, wenn Sie nach PRs suchen – Sie benötigen einen separaten Aufruf an den Pull-Request-Reviews-Endpoint, um sie abzurufen. Dort findet die eigentliche technische Diskussion statt.

Backlinks. Wenn Sie ein Linear-Issue finden, prüfen Sie, ob Slack-Nachrichten die URL dieses Issues enthalten. Slacks Suche unterstützt has:link-Filter kombiniert mit Schlüsselwörtern. Das hebt die informelle Diskussion hervor, die rund um das formale Tracking stattfand.

Caching. Wenn Ihr Team viel Content generiert (und wessen Team tut das nicht), werden Sie schnell auf Rate-Limits stoßen. Ergebnisse lokal mit einer TTL von 30 Minuten cachen – die meisten historischen Entscheidungen ändern sich nicht so schnell.

Wo Textsuche an ihre Grenzen stößt

Hier möchte ich ehrlich über die Einschränkungen sein. Schlüsselwortsuche über Tools hinweg bringt Sie überraschend weit, und dann stößt sie an eine Wand.

Die Wand ist diese: Entscheidungen entwickeln sich. Der Slack-Thread über „Job-Queues" könnte nie „BullMQ" beim Namen nennen – stattdessen hat jemand einen Link geteilt, jemand anderes sagte „Ich mag die Redis-basierte Option," und eine dritte Person sagte „Einverstanden, nehmen wir das." Ihre Suche nach „BullMQ" übersieht den gesamten Thread, weil das Wort nie verwendet wurde. Die Menschen im Thread wussten, was „die Redis-basierte Option" bedeutete. Ihre Suche nicht.

Das ist grundlegend ein Graph-Problem, kein Text-Problem. Was Sie eigentlich wollen, ist: „Zeig mir alles, was mit der Entscheidung verbunden ist, die zu PR #289 geführt hat." Das bedeutet zu verstehen, dass der PR ein Linear-Issue referenziert, das nach einer Slack-Diskussion erstellt wurde, die begann, weil jemand ein Notion-Dokument gelesen hatte. Die Verbindungen sind implizit – Menschen haben sie hergestellt, indem sie URLs kopierten und „as discussed" sagten – und eine Schlüsselwortsuche kann sie nicht rekonstruieren.

Sie können das teilweise lösen, indem Sie Links folgen. URLs aus Slack-Nachrichten, PR-Beschreibungen und Linear-Kommentaren parsen. Eine einfache Adjazenzliste aufbauen: Dieser Slack-Thread verlinkt auf dieses Linear-Issue, das in diesem PR referenziert wird. Dann können Sie bei einer Suche Ergebnisse um verlinkte Elemente erweitern, auch wenn sie nicht mit dem Schlüsselwort übereinstimmen.

Dieser Adjazenzlisten-Ansatz ist im Wesentlichen ein rudimentärer Wissensgraph – und das ist der Ort, an dem der echte Wert der Tool-übergreifenden Suche für Entwickler liegt. Nicht im Finden einzelner Nachrichten, sondern im Verfolgen des Fadens einer Entscheidung über jedes Tool hinweg, das sie berührt hat. Es ist weniger „Suche" und mehr Wissensverwaltung für Entwickler – zu verstehen, wie Information zwischen Ihren Tools fließt, damit Sie Kontext rekonstruieren können, wenn Sie ihn brauchen.

Das Wartungsproblem (und eine Abkürzung)

Der Skript-Ansatz funktioniert brillant für etwa drei Monate, und dann ändert jemand den Slack-Workspace, oder Linear aktualisiert ihr GraphQL-Schema, oder Sie fügen ein neues Tool hinzu und niemand erinnert sich, das Such-Skript zu aktualisieren. Ich habe genau dasselbe zweimal aufgebaut und zweimal aufgegeben (was wahrscheinlich mehr über meine Bereitschaft zur Wartung aussagt als über den Ansatz selbst).

Wenn Sie eine Tool-übergreifende Suche für Entwickler wollen, die ohne Babysitting aktuell bleibt, dafür sind Tools wie Sugarbug gebaut – es pflegt den Wissensgraph automatisch und hält die Verbindungen lebendig, wenn sich Ihre Tools ändern. Aber die obige DIY-Version ist wirklich nützlich, wenn Sie bereit sind, sie zu warten.

Hören Sie auf, fünf Tools separat zu durchsuchen. Sugarbug baut den Wissensgraph, damit Sie jede Entscheidung, Diskussion oder jeden Commit an einem Ort finden können.

Q: Wie suche ich gleichzeitig über mehrere Entwickler-Tools? A: Sie können eine einfache Tool-übergreifende Suche aufbauen, indem Sie die APIs der einzelnen Tools kombinieren – Slacks search.messages, Linears issueSearch und GitHubs Code-Search-Endpoint – in einem einzigen Skript, das Anfragen auffächert und Ergebnisse nach Zeitstempel zusammenführt. Die obigen Code-Beispiele bringen Sie an einem Nachmittag zum Start. Die Hauptherausforderung ist nicht die Suche selbst, sondern die Normalisierung der verschiedenen Antwortformate in eine kohärente Zeitleiste.

Q: Bietet Sugarbug eine Tool-übergreifende Suche für Entwickler? A: Ja. Sugarbug nimmt Signale aus Linear, GitHub, Slack, Figma, Notion und anderen Tools in einen Wissensgraph auf, sodass Sie nach einer Entscheidung oder Diskussion suchen und alle verbundenen Threads, Issues und Commits an einem Ort finden können. Es übernimmt die Normalisierung, Deduplizierung und Link-Verfolgung automatisch – die Teile, die den DIY-Ansatz über die Zeit fragil machen.

Q: Warum finde ich Architekturentscheidungen nicht in meiner Codebase? A: Weil die meisten Entscheidungen in Slack-Threads, Linear-Kommentaren, Notion-Docs und PR-Reviews stattfinden – nicht im Code selbst. Der Code dokumentiert das Ergebnis einer Entscheidung (die Funktion existiert, die Bibliothek wurde gewählt), aber die Begründung, Abwägungen und besprochenen Alternativen sind über Ihre Kommunikations-Tools verstreut. Ein git blame sagt Ihnen, wer eine Zeile wann geändert hat – aber nicht, warum man diesen Ansatz gegenüber den Alternativen gewählt hat.

Q: Kann Sugarbug ADR-Dokumente für die Entscheidungsverfolgung ersetzen? A: Sugarbug ersetzt keine ADRs, aber es erfasst die Entscheidungen, die nie in ein ADR aufgenommen werden. Die meisten Teams schreiben ADRs für vielleicht 10 % ihrer Architekturentscheidungen – der Rest löst sich in Slack-Threads und PR-Kommentaren auf. Sugarbug hebt diese hervor, indem es Gespräche mit den dadurch entstandenen Code-Änderungen verbindet, sodass Sie Entscheidungsverfolgung für die anderen 90 % erhalten, ohne den Workflow von jemandem zu ändern.