巨人之肩 (Giants‘ Shoulders)
„Wenn ich weiter gesehen habe, dann deshalb, weil ich auf den Schultern von Giganten stehe.“ — Isaac Newton, 1675
Übersicht
Bevor du etwas Neues baust, finde heraus, wer bereits etwas Ähnliches gebaut hat. Die meisten Ideen wurden bereits ausprobiert: einige gut gelöst, einige schlecht gelöst, einige aus lehrreichen Gründen aufgegeben, wenige wirklich offen. Das Ziel ist nicht zu kopieren – sondern von der aktuellen Grenze aus zu starten, statt von einer leeren Seite: Bewährte Ansätze wiederverwenden, bekannte Sackgassen vermeiden und klar sehen, wo die Aufgabe tatsächlich vom Bestehenden abweicht.
Agentenunabhängig: Funktioniert mit jedem Agenten, der das Web durchsuchen kann (Claude Code, Codex, Cursor, TRAE oder andere). Verwende die vom Host bereitgestellten Web-Such-/Fetch-Tools. Führe dies zu Beginn der Aufgabe, vor dem Entwerfen oder Programmieren aus und halte es proportional – eine kurze Suche, keine Literaturrecherche.
Wann ausführen vs. überspringen
Ausführen, wenn die Aufgabe etwas Neues schafft oder einen Ansatz wählt: Ein Werkzeug / Skript / eine Bibliothek / CLI / Fertigkeit / Plugin / ein Agent / Workflow / eine Integration / ein Prototyp / Produkt bauen, eine Architektur entwerfen oder ein Framework, eine Bibliothek oder einen Algorithmus auswählen.
Überspringen für triviale Aufgaben (eine Zeile übersetzen, eine Variable umbenennen, die Uhrzeit prüfen) oder Aufgaben ohne externen Vorarbeiten (Bearbeiten der eigenen privaten Dateien/Daten des Benutzers). Wenn du dir unsicher bist, ob es sich lohnt, frage einen Satz: „Soll ich kurz ein bis zwei Minuten nachsehen, ob es bereits eine Lösung gibt?“
Arbeitsablauf
1. Das Problem in einem Satz neu formulieren
Reduziere die Aufgabe auf das Kernproblem in einfachen Worten – nicht die vom Benutzer gewählte Lösung. Z.B. „Ein Skript zum Entfernen von Duplikaten in meiner CSV bauen“ → Kernproblem = „Zeilendeduplizierung in tabellarischen Daten“. Wenn die Formulierung so breit ist, dass sie eine ganze Werkzeugkategorie abdeckt, stelle genau eine klärende Frage vor der Suche (biete bis zu 3 Beispieldimensionen als Anregungen, keinen Fragebogen).
2. Vor der Suche ein Vokabular erstellen
Verschiedene Communities verwenden unterschiedliche Wörter für dieselbe Sache. Bevor du eine Abfrage ausführst, schreibe 6–10 Formulierungen des Problems aus verschiedenen Blickwinkeln auf und ordne jede Suchanfrage einer Formulierung zu. Dies verhindert den häufigsten Fehlermodus: Fünf Abfragen landen alle in derselben semantischen Nachbarschaft. Decke mindestens ab:
- Erbauer-Perspektive – die eigenen Worte des Benutzers
- Benutzer-des-Werkzeugs-Perspektive – was jemand, der danach sucht, eingeben würde
- Akademische/Forschungsperspektive – falls zutreffend
- Infrastruktur/Implementierungsperspektive – der technische Name
- Angrenzende-Community-Perspektive – die benachbarte Disziplin, die es wahrscheinlich zuerst gelöst hat
Füge mindestens eine englische Formulierung hinzu – die meisten Vorarbeiten und Repos lassen sich besser auf Englisch finden.
3. Dort suchen, wo Entwickler tatsächlich veröffentlichen
Verwende die Web-Werkzeuge des Hosts (zuerst suchen, dann vielversprechende Treffer abrufen). Führe 3–6 gezielte Abfragen über verschiedene Formulierungen und Quellen hinweg durch – führe nicht eine generische Abfrage aus und höre auf.
| Quelle | Was sie findet | Wie |
|---|---|---|
| Websuche | Produkte, Vergleiche, „Bestes X für Y“, Blogbeiträge | Suchwerkzeug des Hosts |
| Code-Hosts | Echte Implementierungen, Bibliotheken, „awesome-*“-Listen | site:github.com <problem>, GitLab; gh search repos/code "<Schlüsselwörter>" falls gh-CLI existiert |
| Paketregister | Existierende Bibliotheken | npm, PyPI, crates.io, pkg.go.dev, Hugging Face (ML) |
| Produkt/Community | Gestartete Produkte, Erfahrungsberichte | Product Hunt, Hacker News „Show HN“, relevante Subreddits |
| Q&A/Foren | Fallstricke, warum Ansätze scheitern | Stack Overflow, HN-Threads |
| Domain-spezifische Quellen | Der kanonische Weg | offizielle Dokumentation, RFCs/Standards, arXiv, Modellkarten |
Bevorzuge Primärquellen (Repos, Show-HN-Threads, Projekt-Webseiten) gegenüber Aggregator-Listen. Ein GitHub-Repo mit 200 Sternen schlägt eine Medium-Liste.
4. Bei jedem direkten Treffer eine Ebene tiefer gehen
Hier scheitert die Suche am häufigsten – indem sie eine Ebene zu früh aufhört. Wenn die Dokumentation eines Projekts sagt „basiert auf X“, „verwendet Y als Wrapper“, „offizielles Werkzeug für Z“ oder „läuft über W“, dann ist dieses genannte Ding oft der eigentliche Platzhirsch und das gefundene Projekt nur ein dünner Wrapper. Behandle jede genannte Abhängigkeit bei einem direkten Treffer als Suchhinweis: Verfolge sie mit einer eigenen Abfrage, bevor du ein Fazit ziehst. Lass nicht das erste (möglicherweise winzige) Projekt, das du findest, die Antwort bestimmen.
5. Ergebnisse in vier Kategorien clustern
Wirf keine Rohdaten aus. Gruppiere sie:
- Direkte Treffer – gleiches Problem, gleicher Ansatz
- Angrenzende Lösungen – gleiches Problem, anderer Ansatz
- Teillösungen – löst einen Teil
- Aufgegeben / Veraltet – existierte, ist jetzt tot (notiere das Datum des letzten Commits und, falls auffindbar, warum es gestorben ist – das ist oft die lehrreichste Vorarbeit)
6. Die Standardmuster extrahieren
Was wiederholt sich bei den Treffern? Gemeinsame Architektur, Bibliotheken, Designentscheidungen, Namensgebung, Preismodelle. Das ist das Standard-Spielbuch, auf dem die Aufgabe aufbauen oder mit dem sie konkurrieren würde.
7. Den Winkel der Aufgabe ehrlich bewerten
Vergleiche in einem Absatz die spezifische Formulierung des Benutzers mit dem, was existiert. Nenne den wirklichen Unterscheidungsfaktor oder gib zu, dass es keinen gibt. Erfinde keine Neuheit, um nett zu sein, und erfinde keine Konkurrenten, um gründlich zu wirken.
8. Ein Urteil abgeben, dann weitermachen
Wähle ein Urteil und beginne damit (siehe references/report-template.md für die genaue Ausgabeform):
- Vorhandenes verwenden – bereits gut gelöst; nenne die beste(n) Option(en)
- Forken / Erweitern – nächstgelegenes Projekt + konkret, was hinzugefügt werden soll
- Beitragen – die Funktion gehört stromaufwärts; schlage vor, wo
- Neu bauen – echte Lücke; der Unterschied ist klar und verteidigbar
- Zuerst recherchieren – jemand hat es versucht und aufgegeben; verstehe warum, bevor du Zeit investierst
Übergib dann an die eigentliche Aufgabe, informiert durch das, was du gefunden hast. Warte nicht auf Zustimmung, es sei denn, ein Ergebnis ändert den Umfang materiell (z.B. ein ausgereiftes Werkzeug tut bereits genau dies) – in diesem Fall zeige es auf und frage.
Budget & Schutzmaßnahmen
- Zeitlich begrenzen. Strebe ≤10 Abfragen insgesamt an; höre früher auf, wenn die Landschaft nach 3–4 Abfragen klar ist und mindestens eine eine Abhängigkeit eine Ebene tiefer verfolgt hat (Schritt 4). Dies geht der eigentlichen Arbeit voraus; es darf sie nicht dominieren.
- Ehrlich berichten. „Keine direkte Vorarbeit gefunden“ ist ein gültiges, wertvolles Ergebnis – sage, wo du gesucht hast, anstatt mit schwachen Treffern oder erfundenen Konkurrenten aufzufüllen.
- Nicht „bauen“ empfehlen, wenn etwas Gutes existiert. Maßgeschneiderte Entwicklung verursacht laufende Wartungskosten, die routinemäßig unterschätzt werden. Standardmäßig verwenden/anpassen/beitragen, es sei denn, nichts passt.
- Wartung prüfen, nicht nur Sterne. Aktuelle Commits, Issue-Antworten, Release-Rhythmus und Bus-Faktor verraten mehr als die Sternanzahl. Ein stabiles Werkzeug mit 500 Sternen kann ein trendiges mit 50.000 schlagen.
- Lizenzen respektieren. Notiere die Lizenz eines Projekts, wenn du eine Wiederverwendung vorschlägst.
- Quellen angeben. Jedes genannte Element erhält einen Link, sodass die Ergebnisse überprüfbar sind.
- Kein Netzwerk? Sage es, notiere, dass die Suche übersprungen wurde, greife auf das zurück, was du weißt – kennzeichne es als aus dem Gedächtnis und möglicherweise veraltet – und fahre dann fort.
- Synthetisieren, nicht nur auflisten. Der Wert liegt im Vergleich (Wiederverwendung vs. Lücke), nicht in einem Haufen Links.
Referenzdateien
references/report-template.md– die genaue Ausgabestruktur und ein durchgearbeitetes Beispiel. Lies es, wenn du die Zusammenfassung verfasst.
Optional: Als Standardregel festlegen
Standardmäßig wird diese Fertigkeit nur ausgelöst, wenn ihre Beschreibung zur Aufgabe passt. Um sie automatisch vor jeder Von-Grund-auf-Aufgabe auszuführen, füge eine Regel zur Anweisungsdatei des Host-Agenten hinzu. Einmal ausführen (Opt-in, idempotent, sicher erneut auszuführen):
scripts/install.sh
Es fragt, ob Giants‘ Shoulders eine Standardregel werden soll, und falls ja, hängt es einen markierten Regelblock an die gefundenen Anweisungsdateien des Agenten an (AGENTS.md für Codex/TRAE/Cursor, CLAUDE.md für Claude Code). Bei Ablehnung wird nichts geschrieben. Setze GIANTS_SHOULDERS_ASSUME_YES=1, um nicht-interaktiv zu installieren.