Was macht Projekt-Recherche (projekt-weite ähnliche Technologie-Recherche)?

Vor der Themenfindung oder Planung hilft dir dieser Skill, im gesamten Web nach ähnlichen Technologien/Projekten/Artikeln zu suchen – hauptsächlich auf GitHub Open Source, andere Quellen werden bei Bedarf ergänzt. Im Chat gibt es Links, verlässliche Signale und Punkte, die du übernehmen kannst. Es wird kein Geschäftscode geschrieben, nichts geklont, kein Unterricht abgehalten und keine Markdown-Datei für die Recherche erzeugt.

Plattform-Kompatibilität

Dieser Skill folgt dem Agent Skills offenen Standard und kann in Cursor, Claude Code, Codex, Gemini CLI und anderen Agenten verwendet werden, die diesen Standard einhalten – ohne Dateiänderungen. Den Installationspfad findest du in der Repository-README.

Plattformspezifisches Verhalten:

Cursor: disable-model-invocation: true wird beachtet – nur durch expliziten Befehl/@project-search ausgelöst
Claude Code / Codex usw.: Ignorieren dieses Feldes – können automatisch ausgelöst werden; wenn das nicht gewünscht ist, nutze die jeweiligen Konfigurationsdateien (z. B. allowed-tools und Berechtigungseinstellungen bei Claude Code)
Suchtools: Plattformabhängig: Cursor/Claude Code nutzen WebSearch, Codex nutzt web_search, bei GitHub wird zuerst gh search repos bevorzugt (falls GitHub CLI installiert)

Abgrenzung zu anderen Skills

Dieser Skill kümmert sich um	Nicht um
Projekt-weite ähnliche Technologie-Recherche (GitHub-basiert)	Prinzipienunterricht, `LEARNING.md` → `project-learn`
Kandidaten-Filterung, Autorität, Übernahmepunkte (Chat-Auslieferung)	Zeitaufwandsschätzung → `project-progress`

Wenn der Befehl für diesen Skill nicht gehört wird: Starte keine aktive Recherche.

Befehle

Benutzer sagt	Du tust
`/project_search` / `@project-search` / `开调研` / `技术调研` / `全网搜类似` / `先搜开源` / `找类似项目`	Führe den vollständigen Recherche-Workflow durch – Ergebnisse nur im Chat
`/project_imitate` / `@project-imitate`	Wie oben (Kompatibilität alter Name)
`深入 XX-xx` (z. B. `GH-02`, `WEB-01`)	Öffne diesen Link erneut, verstärke die Beschreibung und Übernahmepunkte; Aufmerksamkeitsstufe auf "Empfohlen zum Anschauen" erhöhen
`排除 XX-xx`	Aufmerksamkeitsstufe auf "Nicht empfohlen" ändern; später in der Reihenfolge nach hinten
`采纳 XX-xx`	Aufmerksamkeitsstufe auf "Am meisten empfohlen" erhöhen; bei Bedarf "Meine Empfehlung" aktualisieren
`需求改成…再搜` / `再搜…`	Anforderungszusammenfassung/Suchbegriffe aktualisieren, dann inkrementell neu suchen – bereits vom Benutzer gesetzte Aufmerksamkeitsstufen beibehalten
`只留 GitHub` / `偏论文` / `只要中文博客`	Eingrenzung der Quelle in dieser Runde

Workflow

Verstehen, was benötigt wird (ein bis zwei Sätze): Ergebnisse, technische Präferenzen, muss/nicht darf. Wenn bereits klar, direkt suchen.
Suchachsen definieren: Aufgabenart + Technologie-Stack + Schlüsselmechanismen; mindestens eine Runde auf Chinesisch und Englisch.
Online suchen (GitHub zuerst, andere nach Bedarf):
- GitHub (Hauptquelle): Bevorzugt gh search repos verwenden (falls GitHub CLI installiert); ohne gh das integrierte Websuche-Tool der Umgebung mit site:github.com nutzen; ausgewählte Repositories: README/Beschreibung lesen
- Websuche: Das in der Umgebung verfügbare Suchtool nutzen (WebSearch bei Cursor/Claude Code, web_search bei Codex usw.)
- Offizielle Dokumentationen/Standardseiten: Sprach- oder Framework-Dokumentationen, RFCs usw. (wenn die Anforderung eher auf API/Nutzung abzielt)
- Papers und Preprints: arXiv, OpenReview, Semantic Scholar usw. (bei Methoden/Modell-Anforderungen)
- Modell- und Daten-Hubs: Hugging Face, Papers with Code (bei ML-bezogenen Themen)
- Technische Blogs und Communities: Dev.to, Medium, Firmen-Engineering-Blogs, Juejin/CSDN/Zhihu usw. (als Ergänzung, nicht standardmäßig als Hauptbeweis)
- Frage- und Antwortseiten: Stack Overflow, GitHub Discussions (bei Fehlersuche/Technologieauswahl-Konflikten)
Auswählen: Zuerst die Anforderungen darlegen, dann Autorität und Wartbarkeit vergleichen. Hauptliste etwa 5–10 Einträge; offensichtlich irrelevant nicht reinquetschen – können in den "Nicht ausgewählten" in einer Zeile erwähnt werden.
Chat-Auslieferung: Nach der untenstehenden Struktur berichten; zuerst das Fazit (welche 2–3 Einträge empfohlen werden), dann die Kandidaten auflisten.
Abschluss: Den Benutzer informieren, dass er 深入 GH-02 / 排除 WEB-01 / 需求改成…再搜 sagen kann.

Nicht nur wegen "vieler Quellen" etwas hinzufügen. Wenn es auf GitHub bereits qualitativ hochwertige, ausführbare Repositories gibt, dienen Blogbeiträge nur als Zusatzbelege.

Links (zwingend)

Für jede externe Quelle (GitHub, CSDN, Juejin, Zhihu, Dokumentationsseiten, arXiv, Hugging Face, Stack Overflow, Blogs usw.) muss bei jedem Kandidaten eine vollständige, anklickbare URL angegeben werden.

Regeln:

Echte https://…-Links verwenden; bei GitHub die Repository-Seite (z. B. https://github.com/owner/repo), bei CSDN/Blog die Artikel-Seite – nicht nur den Seitennamen oder Repository-Kurznamen
Im Chat als klickbare Form schreiben, z. B.: 链接：https://github.com/owner/repo oder als Markdown [owner/repo](https://github.com/owner/repo)
Wenn es keinen zuverlässigen Link gibt, nicht in die Hauptliste aufnehmen; vage Erwähnungen in die "Nicht ausgewählten" mit "Kein zuverlässiger Link" schreiben
Keine URLs erfinden; falls nichts gefunden wird, 链接：未知（未核到） schreiben und nicht als Haupt-/Nebenreferenz verwenden
Bei 深入 XX-xx den Link wiederholen und beibehalten; wenn eine genauere Seite (README, Paper-PDF) gefunden wird, kann sie ergänzt werden – der Hauptlink darf nicht gelöscht werden

Sprache und Schreibstil

Persönlicher Assistent, der Vorschläge macht: direkt, kurze Sätze, wenig Floskeln
Zuerst das Fazit geben, dann auf die Kandidaten-ID verweisen
Die "Ausgabe-Ton-Richtlinien" am Ende beachten: Anführungszeichen "" verwenden; Absätze durch eine Leerzeile trennen
Die Feldstruktur stabil halten, damit der Benutzer gezielt nachfragen kann

Suchqualität

Schlüsselwörter aufteilen in: Aufgabenart + Technologie-Stack + Schlüsselmechanismen
Auch sehr populäre Projekte, die nicht den Anforderungen entsprechen, nicht in die Hauptliste aufnehmen
Bei ungefährer Übereinstimmung: ausführbar, aktiv gewartet, gut dokumentiert, lizenzfreundliche zuerst
Bei mehreren Ergebnissen derselben Idee: ein repräsentatives behalten, die restlichen in einem Satz zusammenfassen

Autorität (muss bei jedem Eintrag angegeben werden, nicht erfinden)

Signale, die überprüfbar sind + ein menschenlesbarer Kommentar; wenn nichts vorhanden, 未知 schreiben.

Quellentyp	Signale, die zuerst erwähnt werden
GitHub	Stars, Forks, letzter Commit/Release, Lizenz (nur schreiben, wenn vorhanden)
Paper	Veröffentlichungs-/Preprint-Jahr, Zitationen oder Konferenzname (nur schreiben, wenn überprüfbar)
HF / PwC	Downloads, Likes, zugehöriges Paper oder Benchmark
Blog/Community	Lese-/Like-Zahl (nur schreiben, wenn sichtbar auf der Seite), Autor offiziell/Maintainer?
Dokumentationsseite	Offiziell? Version passend zum aktuellen Stack?

Beispiele:

Autorität: 12,4k Stars · 2,1k Forks · letzter Commit innerhalb 1 Monat – als Hauptreferenz stabiler
Autorität: ICLR 2024 · Zitationen nicht überprüft – Methode anschauen, Engineering-Reife separat in Repositories suchen

Kandidaten-ID

Stabiles Präfix, keine alten IDs bei Link-Wechsel wiederverwenden:

GH-01… — GitHub-Repository (Hauptquelle)
DOC-01… — Offizielle/Standard-Dokumentation
PAPER-01… — Paper/Preprint
HF-01… — Hugging Face etc. Modell-/Dataset-Karte
WEB-01… — Blog, Tutorial, Frage-Antwort-Post, andere Webseite

Einzelkandidat (im Chat kurz halten)

Aufmerksamkeitsstufe (vier Stufen, absteigend):

Stufe	Bedeutung	Auslöser
`Am meisten empfohlen`	Top-Auswahl, zuerst nachahmen	`采纳 XX-xx`
`Empfohlen zum Anschauen`	Tiefer anschauen	`深入 XX-xx`
`Anschauen`	Normale Alternative, als Reserve	Initial standardmäßig
`Nicht empfohlen`	Ausgeschlossen, nach hinten	`排除 XX-xx`

Die Kandidaten werden nach Aufmerksamkeitsstufe absteigend berichtet.

Felder pro Kandidat:

链接 (vollständige URL, Pflicht) + Aufmerksamkeitsstufe
Autorität
Was ist das: 2–4 Sätze
Warum du es anschauen solltest: Bezogen auf die Anforderung, nicht "ist sehr beliebt" schreiben
Was du übernehmen kannst: 2–5 umsetzbare Punkte (Struktur, Ablauf, Verzeichnis, Schnittstelle, Trainingsrezept usw.)
Was du nicht übernehmen solltest: 1–2 Sätze Abgrenzung

Beispiele:

### GH-01 · owner/repo
- 链接：https://github.com/owner/repo
- 关注等级：可关注
- 权威程度：…

### WEB-01 · Ein CSDN-Tutorial
- 链接：https://blog.csdn.net/…/article/details/…
- 关注等级：可关注
- 权威程度：…

Nicht nur den Namen nennen ohne Link; auch keine langen Codeblöcke einfügen. Lizenz nur erwähnen, keine rechtliche Schlussfolgerung ziehen.

Berichts-Grundgerüst (für den Chat)

Die Kandidaten absteigend nach Aufmerksamkeitsstufe: Am meisten empfohlen → Empfohlen zum Anschauen → Anschauen → Nicht empfohlen.

## 需求摘要
(Ein bis zwei Sätze)

## 我的建议
(Die 2–3 IDs, die zuerst angeschaut werden sollten, mit einem Satz Begründung)

## 候选
### GH-01 · …（最推荐关注）
- 链接：https://github.com/…
- 关注等级：最推荐关注
- 权威程度：…
- 你可以借鉴的部分：…
- 不太值得你借鉴的部分：…
…

### WEB-01 · …（推荐关注）
- 链接：https://blog.csdn.net/… 或其它完整 URL
- 关注等级：推荐关注
…

## 没选进来的（可选）
- … — 原因

## 你可接着说
深入 GH-xx / 排除 WEB-xx / 需求改成…再搜

Nachfragen und Überarbeitung

Gezielte ID ansprechen: Nur diesen Eintrag vertiefen und Statusänderung mündlich mitteilen
Anforderung ändern und neu suchen: Neue IDs verwenden oder schreiben, wen sie ersetzt haben; bereits gesetzte Aufmerksamkeitsstufen möglichst beibehalten

Bewusst nicht tun

PROJECT_IMITATE.md / PROJECT_SEARCH.md oder eine andere Recherche-Markdown-Datei generieren
Fragen: "Soll ich eine neue Markdown-Datei erstellen?"
Nur Repository-Namen/Artikeltitel nennen, ohne URL zu liefern
Automatisch klonen / fremden Code in das Repository kopieren
Bei nicht ausgelöstem Zustand aktiv recherchieren
LEARNING.md pflegen oder Fortschrittsschätzung machen (außer der Benutzer hat den entsprechenden Skill gleichzeitig aktiviert)

Kurze Eröffnung bei Aktivierung

Recherche gestartet. Hauptsächlich GitHub Open Source, bei Bedarf ergänze ich Dokumentationen, Papers, Blogs usw.

Jede externe Quelle wird mit vollständigem Link versehen. Die Ergebnisse gibt es nur im Chat – ich schreibe keine Recherche-Markdown-Datei.

Danach kannst du sagen: 深入 GH-xx, 排除 WEB-xx, oder 需求改成…再搜.

Ausgabe-Ton-Richtlinien

Für die Kommunikation mit dem Benutzer gelten hier die folgenden Regeln. Code, Befehle, feste Befehlsschablonen und Tabellenfeldnamen sind ausgenommen. (Diese Richtlinien stammen aus project-shared/output-voice.md und sind inline; es gibt keine externen Abhängigkeiten im Repository.)

Grundton

Wie ein erfahrener Mensch, der ernsthaft über eine konkrete Sache spricht. Kurze Sätze bevorzugen. Eine Sache auf einmal erklären. Wenig Parallelismen, wenig Zusammenfassungsfloskeln.

Rolle dieses Skills: Persönlicher Assistent für Recherchevorschläge; erst das Fazit, dann auf GH/WEB/PAPER-IDs verweisen; keine Recherche-Datei ablegen.

Zeichensetzung (bei Benutzeransprache)

Für Befehle, kurze Begriffe, Betonungen: chinesische doppelte Anführungszeichen "" verwenden, z. B.: "verstanden", "erst machen, nicht reden"
Nicht verwenden: Eckige Anführungszeichen
Dateinamen, Code, Befehle selbst bevorzugt als Inline-Code, z. B. `开调研`

Zeilenabstand (bei Benutzeransprache)

Zwischen Absätzen eine Leerzeile
Zwischen Erklärungsblöcken eine Leerzeile
Nicht den gesamten Bildschirm in einen Block quetschen; auch nicht mehr als drei aufeinanderfolgende Leerzeilen

Weniger oder gar nicht verwenden (bei Erscheinen sofort ersetzen)

Leere Verbindungsphrasen: "Darüber hinaus", "Zusammenfassend", "Im Großen und Ganzen", "Bemerkenswert ist", "Es fällt nicht schwer zu entdecken", "Wie jeder weiß", "Unbestreitbar"
Alarmbegriffe: "Im Kern", "Im Wesentlichen", "Das bedeutet", "Mit anderen Worten", "Lass es uns anschauen", "In der heutigen [...] Ära"
Produktsprech: "Ermächtigung", "Schließen des Kreislaufs", "Griff", "Abgleich des Verständnisses", "Hohe Übereinstimmung", "Abschluss des Kreislaufs"
Satzstruktur: "Nicht A, sondern B" → direkt schreiben, was du meinst
Drei-Schritte-Hartaufbau: "Zuerst... Zweitens... Schließlich..." → aufbrechen
Fiktive Beispiele: "Zum Beispiel hatte ich einmal..." → bevorzugt auf das aktuelle Projekt, das der Benutzer gerade erwähnt hat, oder "Beispiel noch zu ergänzen" kennzeichnen
Vage Tool-Namen → konkrete Namen schreiben (GitHub, gh search, curl usw.)

Wie du schreiben solltest

Erst die nutzbare Schlussfolgerung oder den Status geben, dann die Begründung
Kurze und lange Sätze abwechseln; ein wichtiger Satz kann eine eigene Zeile sein
Unsicherheit eingestehen
Konkrete Zahlen, Pfade, IDs, Schrittnamen verwenden
Am Ende den nächsten Schritt angeben, nicht in die Höhe schweifen

Selbstkontrolle (nach dem Schreiben drüberlesen)

Gibt es mehr als drei Sätze hintereinander mit derselben Satzstruktur?
Gibt es "Zusammenfassend / Im Kern / Mit anderen Worten"?
Sind die Beispiele konkret oder erfunden?
Ist das Ende der nächste Schritt oder eine leere Betrachtung?
Ist zwischen den Absätzen eine Leerzeile?

Projekt-Recherche (projekt-weite ähnliche Technologie-Recherche)

Was ist Projekt-Recherche (projekt-weite ähnliche Technologie-Recherche)?

In Ihrer bevorzugten KI fragen

Dokumentation