Shambhavagrawal/rotless-github-research

GitHub Research

Finden Sie jedes relevante Repository und jede extrahierbare Komponente für das Thema oder die Frage des Benutzers: $ARGUMENTS (Claude Code füllt dies aus; in anderen Agenten ist es die Anfrage des Benutzers)

Die literale Schlüsselwort-Suche schlägt bei Nischenthemen fehl: Entwickler benennen Repos nach dem Ding, das sie berühren (eine Website, eine API, eine Organisation, eine Bibliothek), nicht nach dem Konzept. Suchen Sie nach den Artefakten, die jede Implementierung enthalten muss, aus mehreren Richtungen (Code, Repos, Commits, Issues, andere Hosts, das Web), verifizieren Sie jeden Treffer und zerlegen Sie Kandidaten in wiederverwendbare Teile, um sie in unsere Ziellösung einzubauen.

Die rotless-Familie

Teil von rotless und vollständig eigenständig nutzbar. Wenn die Recherche den Stand der Technik für eine Fähigkeit darstellt, benennt der Aufrufer eine Datei und deren Form (prior-art.md, definiert von rotless-skill-modernizer): Schreiben Sie den Bericht dorthin in dieser Form. Aufrufer: rotless-skill-creator (Schritt 0, vor dem Bauen), rotless-skill-modernizer (fix für ein ersetztes Tool, refresh für die gesamte Landschaft) und rotless-skill-refiner (eine „bessere Methode“-Lektion wird gegen das Bestehende geprüft, bevor sie übernommen wird).

Werkzeugkasten

Helfer befinden sich im scripts/-Ordner dieser Fähigkeit. Setzen Sie S einmal auf den absoluten Pfad dieses Ordners, ausgehend vom Basisverzeichnis dieser Fähigkeit (dem Ordner, der diese SKILL.md enthält; Claude Code gibt ihn als „Base directory for this skill: …“ aus, wenn die Fähigkeit geladen wird), und rufen Sie Helfer immer über $S auf (das aktuelle Arbeitsverzeichnis ist das Projekt des Benutzers); -h listet Flags auf; python3, oder python unter Windows. Off-GitHub-Endpunkte befinden sich in references/sources.md (gleicher Ordner). Bevorzugen Sie eine POSIX-Shell (bash; Git Bash unter Windows) gegenüber PowerShell (Probleme beim Quoting von -, !, jq). Sarkari/UPSC-Beispiele dienen nur zur Veranschaulichung.

Tool	Was es durchsucht	Am besten geeignet für
grepapp.py (= searchGitHub-Tool, wenn das grep-MCP installiert ist)	Dateiinhalte, ~1 Mio. beliebte Repos, Regex, keine Authentifizierung	Hartcodierte Domänen, Importzeilen, Konfigurationsschlüssel
gh api -X GET search/code -f q='…'	Dateiinhalte, GitHub's Legacy-Index (mehr Repos, kein Regex)	Zweite Code-Quelle; path:/filename:-Signaturen
ghsweep.py	Repository-Name/Beschreibung/Readme/Themen, viele Abfragen, dedupliziert	Breite; Gesamtzahlen, gemeinsame Themen, [noise?]-Tags
gh search commits …	Commit-Nachrichten	Repos, deren Name/README nichts aussagen
gh search issues … --include-prs	Issue/PR-Text	Repos + reale Schmerzpunkte (benötigt spezifische Phrasen; generische Wörter ertrinken in Bot-Issues)
ghverify.py	GraphQL-Batch, 25 Repos/Aufruf	Existenz, Umbenennungen, reale Aktivität, Zustand, Beweise, Warnhinweise
gh repo read-dir / read-file, gh api …/contents	Dateien eines Repos, kein Klonen	Bestätigung von echtem Code
srcsweep.py	21 Nicht-GitHub-Quellen parallel: npm, crates, Packagist, Hex, NuGet, Maven, RubyGems, Hackage, Docker Hub, ArtifactHub, AUR, Open VSX, GitLab, Codeberg, MCP Registry, skills.sh, Hugging Face (Modelle/Datensätze/Spaces/Papers, mit dem Code-Repo, das ein Paper verlinkt), Hacker News	Stand der Technik außerhalb von GitHub; endet mit einem Verzeichnis der durchsuchten / nicht erreichten Quellen; --repos leitet GitHub-Repos an ghverify.py - weiter
references/sources.md	Endpunkt-Notizen + Quellen ohne Such-API (PyPI, Homebrew, pkg.go.dev, Product Hunt, Reddit)	Manuelle Nachfassaktionen

gh-Suchregeln, die wichtig sind (getestet; Missachtung gibt still [] oder falsche Ergebnisse zurück)

• Anführungszeichen: gh search <art> "zwei wörter" = exakte Phrase. Für UND übergeben Sie Wörter ohne Anführungszeichen; OR funktioniert ohne Anführungszeichen.
• Für alles Nicht-Triviale verwenden Sie die rohe API (vollständige Syntax + total_count): gh api -X GET search/{repositories|code|commits|issues} -f q='<query>' -f per_page=100 --cache 1h
• Alle Wörter müssen in der Repo-Suche übereinstimmen, halten Sie daher jede Abfrage auf 2–3 Wörter und variieren Sie die Formulierung, anstatt Begriffe in eine Abfrage zu packen. Wenn ein Sweep < 5 Repos zurückgibt, kürzen Sie die Abfragen.
• Ausschluss: Wörter mit NOT wort; Qualifizierer mit -qualifier:wert. -wort gibt 0 zurück. Setzen Sie in gh search Ausschlüsse nach --.
• Codesuche über API = Legacy-Engine: kein Regex; OR/NOT, path:, filename:, extension:, language: funktionieren. Nur Standard-Branch; überspringt große Dateien. Verwenden Sie grep.app für Regex.
• Ergebnisobergrenze 1000 pro Abfrage. Teilen Sie große Ergebnismengen auf: created:A..B, pushed:>DATUM, Stern-Bänder stars:0..24, stars:25..99, stars:100..499 (macht auch wenig bekannte Perlen sichtbar), language:.
• Ratenbegrenzungen: Suche 30/Min; Codesuche 10/Min (gh skill search teilt sich dies); GraphQL 5000 Pkt/Std. Prüfen: gh api rate_limit --jq '.resources | {search: .search.remaining, code: .code_search.remaining, graphql: .graphql.remaining}'. Verwenden Sie --cache 1h bei wiederholten Aufrufen; wenn die Codesuche erschöpft ist, wechseln Sie den Vektor, anstatt zu warten.
• Privatsphäre: Authentifizierte Suche gibt private Repos zurück, die das Konto sehen kann. Melden Sie diese niemals: fügen Sie select(.repository.private == false) (Code) / select(.private == false) (Repos) zu jq hinzu; ghsweep.py filtert sie. Verwenden Sie niemals private/interne Namen des Benutzers in Suchabfragen.
• gh repo read-file / read-dir / gh discussion / gh skill benötigen ein aktuelles gh (getestet 2.103). Bei älteren Versionen verwenden Sie die gh api-Fallbacks in Schritt 3 oder schlagen Sie winget upgrade GitHub.cli / brew upgrade gh vor.

Schritt 0 — Kurzbeschreibung (ein kurzer Block, keine Hin- und Her-Rücksprache, es sei denn, es ist wirklich mehrdeutig)

Schreiben Sie: Ziel · Aufschlüsselung der Ziellösung (modulare Teilprobleme: z. B. Authentifizierung/Sitzung, Scraper/Parser, Normalisierung/Schema, Speicher, API/Schnittstelle – um zu identifizieren, was wo genutzt werden kann) · Muss haben · Schön zu haben · Anti-Patterns (z. B. dünner Wrapper, aufgegeben, benötigt kostenpflichtige API, nur GPU) · Einschränkungen (Sprache, offline…: dies sind Bestehen/Nichtbestehen-Prüfungen, keine Suchbegriffe) · Cutoff als absolutes Datum („aktuell“ → pushed:>2025-10-24) · Aufwand: Schnelldurchlauf (günstige, umkehrbare Wahl: ~10 Abfragen, Top 5) oder vollständige Methode (Standard für Stand der Technik / Bauen-vs-Kaufen / Integration). Wenn die Anfrage „Alternative zu X / wie X / X-Klon“ lautet, lösen Sie zuerst X in sein Repository auf und starten Sie von dort (seine Themen, README, Abhängigkeiten). Zuerst lokal prüfen (kostenlos, 10 Sekunden): was bereits installiert ist, könnte die Antwort liefern: die Skills-Ordner, die Ihr Agent lädt (Projekt- und Benutzerebene: .agents/skills/, .claude/skills/, ~/.codex/skills/…), seine MCP-Serverliste (z. B. claude mcp list), gh extension list. Melden Sie einen Treffer, bevor Sie die Welt durchsuchen.

Schritt 1 — Das Thema identifizieren

Schreiben Sie 15–30 konkrete Suchbegriffe:

1. Berührungspunkte — Domänen, URLs, API-Endpunkte, Hostnamen, RSS-Pfade, App-IDs, die jede Implementierung treffen muss.
2. Code-Signaturen — Importzeilen, SDK-Klassen-/Funktionsnamen, Umgebungsvariablen, Konfigurationsschlüssel, CSS-Selektoren, markante Konstanten.
3. Vokabular aus verschiedenen Perspektiven — Entwickler, Endbenutzer, Wissenschaftler, Infrastruktur und die Nachbardisziplin, die es wahrscheinlich zuerst gelöst hat; regionale/nicht-englische Begriffe, Abkürzungen, Tippfehler. Mehrdeutige Wörter benötigen einen Begleitbegriff (agent + llm, nicht bloß agent).
4. Formen — Bot, Scraper, API, CLI, Bibliothek, Erweiterung, MCP-Server, Agent-Skill, Datensatz, Modell, GitHub Action; und ihre Dateisignaturen (.github/workflows cron, manifest.json, SKILL.md, .claude-plugin/marketplace.json). Agent-Skills und Plugins leben oft in größeren Repos (ein skills/x/SKILL.md in einem 80k★-Monorepo), unsichtbar für die Repo-Suche: finden Sie sie mit Code-Suche filename:SKILL.md "<Phrase aus seiner Beschreibung>" (laut: Hunderte bis Tausende von Treffern, verwenden Sie daher 2 markante Phrasen und scannen Sie 2–3 Seiten) und skills.sh (srcsweep.py --sources skills; semantisch, funktioniert besser mit dem Namen des Skills als mit seinem Zweck). Die Skill-Erinnerung ist der schwächste Vektor: Wenn ein Anker-Skill nie auftaucht, suchen Sie direkt nach seinem Namen und erwähnen Sie dies im Deckungsvermerk.
5. Anker — die 3–10 bekannten Projekte/Produkte, von denen Sie erwarten, dass jede gute Antwort sie enthält. Wird in Schritt 2 als Erinnerungsprüfung verwendet.
6. Ideal-README-Absatz — zwei Sätze, die das perfekte Repository beschreiben, so geschrieben, wie es sein Autor tun würde; extrahieren Sie daraus Suchbegriffe.

Schritt 2 — Auf jedem Vektor suchen

Führen Sie Vektoren parallel aus. Notieren Sie, welche Abfragen welches Repo gefunden haben (found_by: mehr Abfragen = stärkere Relevanz).

A. Codesuche (höchstes Signal). Viele enge Abfragen, eine pro Berührungspunkt/Signatur:

S="<Basisverzeichnis dieser Fähigkeit>/scripts"     # z. B. S="$HOME/.agents/skills/rotless-github-research/scripts" (oder ~/.claude/skills/… in Claude Code)
python "$S/grepapp.py" "sarkariresult.com" --repos-only
python "$S/grepapp.py" "(sarkariresult|freejobalert)\.com" --regex --lang Python --lang JavaScript --repos-only
python "$S/grepapp.py" "upsc.gov.in" --path .github/workflows/ --repos-only          # geplante Bots
gh api -X GET search/code -f q='sarkariresult OR freejobalert language:python' -f per_page=100 \
  --jq '"total \(.total_count)", (.items[] | select(.repository.private == false) | "\(.repository.full_name)\t\(.path)")'

grep.app gibt ~10 Dateien/Abfrage zurück und 504 bei breitem Regex: verankern Sie sich an einem seltenen Literal, fügen Sie --lang/--path hinzu. Rauschen entfernen: gecrawlte URL-Datensätze, Adblock-Listen, Monorepos, in denen der Begriff einmal vorkommt.

B. Repo-Suche (Breite + Landschaftsgröße).

python "$S/ghsweep.py" --pushed ">2024-01-01" --order hits "sarkari OR naukri NOT resume" "freejobalert" "topic:government-jobs"
python "$S/ghsweep.py" --sort stars "topic:sarkari-result"      # Flaggschiffe, deren Beschreibungen generische Wörter überspringen
python "$S/ghsweep.py" --sort updated "sarkari scraper"         # frische Arbeit, begraben durch beste Übereinstimmung
python "$S/ghsweep.py" --must "scrap|crawl|alert|job" --exclude "resume|linkedin" "sarkari OR naukri"   # Relevanzfilter; Homonyme ("prior art" = Patente) überschwemmen sonst die Ergebnisse
gh api -X GET search/topics -f q=sarkari --jq '.items[].name'   # Themen-Slugs entdecken

ghsweep.py gibt Gesamtzahlen aus (wie überfüllt der Bereich ist), die häufigsten Themen (→ nächste Abfragen; versuchen Sie auch Paare von Themen, die von ≥2 Top-Treffern geteilt werden: topic:a topic:b), und [noise?]-Tags (Tutorial/Vorlage/Demo/Dotfiles/Awesome: herabstufen, nicht automatisch entfernen). Lassen Sie --pushed für Stand-der-Technik-Recherche unabhängig vom Alter weg.

C. Commit-Suche: gh search commits sarkariresult --limit 50 --json repository,commit --jq '.[] | "\(.repository.fullName)\t\(.commit.message | split("\n")[0])"'

D. Issue/PR-Suche: gh search issues "freejobalert" --include-prs --limit 50 --json repository,title,url (nur spezifische Phrasen).

E. Schneeball von den besten Treffern (Top 3–5):

• Der eingebundenen Abhängigkeit folgen: Wenn ein Treffer X "einhüllt", "darauf aufbaut" oder "es verwendet", recherchieren Sie auch X: oft ist es der eigentliche Platzhirsch. Der häufigste Ort, an dem zu früh aufgehört wird.
• Awesome-Listen: python "$S/ghsweep.py" --sort stars "awesome <kw> in:name"; nehmen Sie awesome-*-Listen mit ≥200★, extrahieren Sie deren Repo-Links (gh repo read-file README.md --repo o/awesome-x | grep -oE 'github\.com/[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+' | sort -u) und leiten Sie sie an ghverify.py - weiter. Gelistet zu sein ist ein weiches Qualitätssignal.
• Ähnliche Repos: Themen + Sprache eines Top-Treffers → topic:a topic:b language:x, ähnliche Stern-Klasse bevorzugen.
• README "Alternativen / Ähnlich / Inspiriert von / Danksagungen"-Abschnitte; markante Code-Strings → grep.app (findet Kopien und Portierungen); andere Repos des Autors (gh repo list <owner> --limit 100); Forks mit eigener Arbeit (gh api "repos/o/r/forks?per_page=100" --jq '.[] | select(.pushed_at > .created_at) | .full_name'); Bibliotheksabhängigkeiten-Seite über Ihr Web-Fetch-Tool oder curl (github.com/o/r/network/dependents).

F. Außerhalb von GitHub: ein Befehl, mehrere Formulierungen (1–3 Wörter jede; Registries UND die Begriffe):

python "$S/srcsweep.py" "repository discovery" --limit 4        # 21 Quellen, ~10s, endet mit einem Verzeichnis der durchsuchten / NICHT ERREICHTEN Quellen
python "$S/srcsweep.py" "sarkari" --repos | python "$S/ghverify.py" -   # Von den Ergebnissen verlinkte GitHub-Repos, verifiziert

Verwenden Sie dann Websuche für das, was keine Such-API hat (PyPI site:pypi.org, Homebrew, pkg.go.dev, Product Hunt, Reddit, Blogs, awesome <topic>). Für Stand-der-Technik-/Wettbewerbsrecherche listen Sie auch bemerkenswerte kommerzielle Produkte auf. Nicht-GitHub-Treffer (GitLab, Codeberg, nur Registry) können nicht durch ghverify.py laufen: prüfen Sie sie von Hand und markieren Sie Beweise als Dokumentiert/Metadaten.

Stoppen und Erinnern. Hören Sie auf, wenn neue Abfragen hauptsächlich bekannte Repos zurückgeben, aber drei Abfragen, die dasselbe Repo zurückgeben, sind ein lokales Minimum, keine Abdeckung. Überprüfen Sie die Anker aus Schritt 1: Jeder Anker, der nicht von Ihren Suchen gefunden wurde, bedeutet eine Vokabellücke: Finden Sie heraus, welche Wörter er verwendet, und suchen Sie danach. Null Ergebnisse bedeuten „Diese Route kann es nicht sehen", nicht „Es existiert nicht": Formulieren Sie es einmal um oder wechseln Sie die Route, bevor Sie zu dem Schluss kommen.

Schritt 3 — Verifizieren und bewerten

Jeder Kandidat durchläuft ghverify.py (erfundene Namen erscheinen als NICHT GEFUNDEN; umbenannte zeigen den aktuellen Namen):

python "$S/ghverify.py" owner/repo https://github.com/o2/r2 ...      # oder: ... | python "$S/ghverify.py" -

Lesen Sie seine Spalten: letzter inhaltlicher Commit (ignoriert Bump/Chore/Deps/Merge/Typo/Docs), nicht pushedAt; Issue-Lösungsrate %; zusammengeführte PRs; Personen; Org/Benutzer; Releases/Jahr; Beweise (Tests, CI, Manifest, security.md; NONE = Nur README, hart verifizieren); Flags !velocity (>100★/Tag: viral oder gekauft, benötigt Kontext), !lowfork (≥1000★, Forks/Sterne < 0,005), new (<14 Tage), stale Ny (kein inhaltlicher Commit seit 2+ Jahren: gekennzeichnet, niemals herabgestuft: ein aufgegebenes Tool beweist immer noch, dass die Idee gebaut wurde), noise?.

Bestätigen Sie dann echten Code für jedes Repository, das Sie melden werden (READMEs lügen in beide Richtungen). Verankern Sie Beweise mit einem Commit:

sha=$(gh api repos/o/r/commits/HEAD --jq .sha)
gh repo read-dir src --repo o/r --ref $sha                    # JSON: --json name,type --jq '.entries[]'
gh repo read-file path/to/main.py --repo o/r --ref $sha       # Fallback: gh api "repos/o/r/contents/PATH?ref=$sha" -H "Accept: application/vnd.github.raw"
gh api "repos/o/r/git/trees/$sha?recursive=1" --jq '"\(.tree|length) Dateien", (.tree[:80][] | .path)'

Zitieren Sie Permalinks https://github.com/o/r/blob/<sha>/<path>#L10-L40, keine Branch-Links.

• Passung & Extraktionsmöglichkeit: stark / teilweise / schwach / vom Thema abweichend, Auflistung der…

… [gekürzt für die Übersetzung]