Open-Source-Vorbereitung
Ein Vorab-Check für ein Repository, das kurz davor steht, öffentlich zu werden. Ein Skript führt die mechanischen Prüfungen durch; du liest das Projekt, beurteilst, was das Skript nicht kann, erstellst einen Bericht und füllst dann nur das aus, was der Benutzer auswählt.
Die Reihenfolge ist wichtig, weil ein Fehler nicht rückgängig gemacht werden kann: Sobald ein Repository öffentlich ist, wurde alles in seiner Historie gesehen. Geleakte Anmeldedaten und persönliche Daten haben Vorrang; Standardtexte kommen zuletzt.
1. Scannen
Führe das beiliegende Scanner-Skript aus dem Repository-Stammverzeichnis aus (Node 20 oder neuer, keine Abhängigkeiten, schreibgeschützt):
node <skill-verzeichnis>/scripts/scan.mjs <repo-verzeichnis>
Es gibt JSON aus: summary zählt fehlschlagende Ergebnisse nach Level, und jeder Fund hat eine id, ein level (block, warn, info), einen status (pass, fail, skip) und evidence. Füge --no-history für eine sehr große Historie hinzu, nur wenn der Benutzer zustimmt, diesen Teil zu überspringen, und sage, dass er übersprungen wurde. Wenn gitleaks installiert ist, führe auch gitleaks git <repo-verzeichnis> --redact --no-banner aus und führe seine Ergebnisse zusammen; es kennt viele weitere Token-Formate.
Die Geheimnisregeln des Scanners sind Muster, daher sind false Positives zu erwarten (Test-Fixtures, Dokumentationsbeispiele) und gehe nicht davon aus, dass alles erfasst wurde. Untersuche jeden Treffer selbst, bevor du ihn meldest. Eine Zeile kann mit einem oss-prep: allow-Kommentar als beabsichtigt markiert werden.
2. Lesen und bewerten
Lies references/checklist.md für die Bedeutung jeder Prüfung, wie man ein echtes Problem von Rauschen unterscheidet und für die Prüfungen, die nur du durchführen kannst. Kurz gesagt, über die Ergebnisse des Skripts hinaus:
- Was die Historie und die Dateien preisgeben. Öffne jeden Geheimnis-Treffer und jede sensible Datei in der Historie (
git show <commit>:<pfad>). Suche nach echten Namen, E-Mails, Telefonnummern, Adressen, Kunden- oder Finanzdaten, internen Hostnamen und Screenshots mit privaten Daten in Dokumentationen oder Fixtures. - Lizenzkonsistenz. Der LIZENZ-Text,
package.json, SKILL.md Frontmatter, README und alle pro-Datei-Header sollten übereinstimmen. Notiere gebündelten Drittanbieter-Code, Schriftarten oder Bilder und prüfe, ob deren Lizenzen eine Weiterverteilung erlauben. - README für einen Fremden. Jemand, der über eine Suche kommt, sollte erfahren, was es ist, es sehen (ein Screenshot oder ein Demolink), es installieren und ausführen können und die Lizenz finden, ohne privaten Kontext.
- Dinge, die nur für den Autor funktioniert haben. Hartcodierte lokale Pfade,
.env-Werte, die das Projekt benötigt, aber nicht dokumentiert, Skripte, die die Maschine des Autors voraussetzen.
3. Bericht
Schreibe den Bericht in der Sprache des Benutzers, in dieser Form:
# Open-Source-Bereitschaft: <repo>
**Bewertung:** <Bereit / Bereit nach den blockierenden Punkten / Nicht bereit>, ein Satz warum.
## Blockierend (vor Veröffentlichung beheben)
- ❌ <Titel>: <was gefunden wurde, mit Datei:Zeile oder Commit> → <die Lösung>
## Sollte behoben werden
- ⚠️ ...
## Schön zu haben
- 💡 ...
## Bereits vorhanden
- ✅ <eine Zeile pro Eintrag, gruppiert>
## Erfordert dich auf GitHub
<Einstellungen, die der Benutzer selbst ändert, mit dem genauen gh-Befehl oder Einstellungspfad>
Setze den schwerwiegendsten Punkt an den Anfang. Sei spezifisch: „src/config.ts:12 enthält einen OpenAI-Schlüssel, auch im Commit a1b2c3d“ statt „Geheimnisse gefunden“. Sage, was du nicht überprüft hast (kein gh, Historie übersprungen, Binärdateien).
Frage dann, welche Punkte ausgefüllt werden sollen. Biete die naheliegende Menge als Standard an („alle fehlenden Dateien“) und liste jede Wahl auf, damit der Benutzer auswählen kann.
4. Ausfüllen, was der Benutzer ausgewählt hat
Verwende die Vorlagen in assets/templates/ als Ausgangspunkt und passe sie an dieses Projekt an; lies zuerst references/fixing.md. Kurz gesagt:
- Dateien schreiben, niemals veröffentlichen. Erstelle oder bearbeite Dateien nur im Arbeitsverzeichnis. Führe keine Commits, Pushs, Änderungen der Repository-Sichtbarkeit oder -Einstellungen durch und erstelle keine Releases, es sei denn, der Benutzer bittet um diesen spezifischen Schritt.
- An das Projekt anpassen. Verwende seine tatsächlichen Befehle, Node-Version, Paketmanager, Lizenz und Kontaktmöglichkeit; schreibe in der Sprache des README (beide, wenn das README zweisprachig ist). Lasse Abschnitte weg, die nicht zutreffen, anstatt Platzhalter zu liefern.
- Niemals eine Lizenz für den Benutzer auswählen. Wenn keine vorhanden ist, erkläre die gängigen Optionen in einem Satz pro Option (MIT, Apache-2.0, GPL-3.0, AGPL-3.0, duale Lizenzierung) und frage nach. Kopiere den offiziellen Lizenztext genau; paraphrasiere oder tippe ihn nicht aus dem Gedächtnis neu.
- Geheimnisse in der Historie werden nicht durch Löschen der Datei behoben. Die Anmeldedaten müssen zuerst widerrufen und ersetzt werden; das ist die Aufgabe des Benutzers in der Konsole des Anbieters. Das Umschreiben der Historie (
git filter-repo) oder die Veröffentlichung eines frischen Repositorys sind seine Entscheidung; erkläre beides und führe beides ohne ein klares Ja nicht aus. - GitHub-Einstellungen gehören dem Benutzer. Gib die genauen
gh-Befehle oder Einstellungspfade aus der Referenz an; führe sie nur aus, wenn der Benutzer darum bittet.
Schließe ab, indem du den Scanner erneut ausführst und zeigst, welche Ergebnisse sich geändert haben, plus was noch für den Benutzer übrig ist.