Was macht Promo-Scout?
Generische, verifikationsorientierte Förderungsintelligenz. Sie ist das Gegenteil eines Hype-Scrapers: Nichts gelangt ins Board, es sei denn der aktuelle GitHub-Status belegt es, und die Bewertung erfolgt durch sshx-Konsens (isolierte Perspektiven + Wahrheitstabelle), nicht durch das Urteil eines einzelnen Modells.
Erfordert: gh authentifiziert mit Ihrem vorhandenen GitHub-Auth, entweder via gh auth login oder GH_TOKEN, sowie das sshx-Skill, das dem Aufrufer zur Verfügung steht.
Verwendungszweck
Ein Agent oder Betreiber möchte für ein Ziel-Repository/eine Organisation wissen: Was ist jetzt wirklich förderungswürdig, wie hängen die Teile über Repos hinweg zusammen, und welche verlockenden Behauptungen sind NICHT verifizierbar?
Schritt 0 – Expliziten Umfang mit dem BENUTZER bestätigen
Es gibt keinen allgemeinen, kontoweiten Standard. Fordern Sie den Benutzer auf, Folgendes zu nennen:
- eine gesamte Organisation (standardmäßig nur öffentliche Repos),
- ein oder mehrere spezifische Repos (
owner/repo), oder - eine gemischte Liste.
Bestätigen Sie außerdem
REPO_LIMITfür Organisationsziele (Standard: 12 zuletzt aktive öffentliche Repos). Das Sammeln privater Repos erfordert ein explizites Opt-in mit--include-private; verwenden Sie dieses Flag nicht, es sei denn, der Benutzer hat es bestätigt.
Schritt 1 – Live-Zustand abrufen (deterministisch; von überall ausführbar)
Führen Sie das gebündelte Fetch-Skript mit einem expliziten Ziel aus:
python3 scripts/promo_scout_fetch.py <org | owner/repo> [weitere...] # öffentlicher/Standard-Umfang
python3 scripts/promo_scout_fetch.py --include-private <org | owner/repo> [weitere...] # nur nach expliziter Bestätigung
Es schreibt /tmp/promo_scout_bundle.json: pro Repo den README-Header, letzte Commits, Releases, offene PRs, aktuelle Issues. Dies ist der EINZIGE Nachweis, den der Konsensschritt verwenden darf.
Schritt 2 – Echten sshx-Konsens über das Bundle ausführen
Rufen Sie das sshx-Skill auf (arbeiterdelegiert, isolierte Perspektiven, codex-cli-Arbeiter) mit dieser Entscheidung, wobei das Bundle als feste Eingabe dient:
Gegeben sei AUSSCHLIESSLICH dieses Bundle mit dem Live-GitHub-Zustand, erstellen Sie drei Listen. (1) Förderungswürdig: Elemente, die jetzt wirklich eine Förderung verdienen – jedes MUSS konkrete Bundleg-Nachweise zitieren (ein Release-Tag, ein datierter Commit, eine README-Fähigkeit). (2) Verbindungen: Repo-übergreifende Links, bei denen die Arbeit eines Repos mit der eines anderen zusammenhängt, jeweils gestützt durch ein echtes Signal im Bundle (gemeinsame PRs, Abhängigkeitserwähnungen, komplementäre Fähigkeiten). (3) Verworfen: verlockende Behauptungen, die das Bundle NICHT unterstützt, mit dem fehlenden Nachweis. Keine Übertreibung; wenn Nachweise fehlen, kommt es zu "Verworfen", nicht zu "Förderungswürdig".
Verwenden Sie unterschiedliche sshx-Denkperspektiven, z. B.: eine Förderbarkeits-Linse, eine Repos-übergreifende Verbindungs-Linse und eine Skeptiker-/ Übertreibungsjäger-Linse. Fordern Sie Konvergenz gemäß der sshx-Wahrheitstabelle; respektieren Sie abstain, wenn Arbeiter eine Behauptung nicht belegen können.
Schritt 3 – Das Board ausgeben
Schreiben Sie das vereinbarte Ergebnis als Board (Markdown + optional JSON): ## Förderungswürdig jetzt, ## Verbindungen, ## Verworfen (nicht verifizierbar). Jedes förderungswürdige/verbundene Element führt seine Bundleg-Nachweise inline auf. Die Liste "Verworfen" ist obligatorisch – sie ist die Glaubwürdigkeit des Boards.
Schutzmaßnahmen
- Kein Nachweis, keine Auslieferung. Das Live-Bundle ist die einzige Quelle; kein externes Gedächtnis, keine aufgeblähten Zahlen.
- Die Verbindungen/Synthese müssen aus dem Konsens über den Live-Zustand ENTSTEHEN – keine vorab verfasste Erzählung einspielen.
- Ehrlich durch Konstruktion: nicht verifizierbar → Verworfen; wenn kein Konsens erzielt werden kann,
abstainmelden, keine Schätzung.