build2-community/build2-review

Was macht build2-review?

ROOT auflösen

Sei HERE das Verzeichnis, das diese SKILL.md enthält (absoluter Pfad aus dem Systemkontext).

ROOT ist der build2-Skill-Baum. Verwende den ersten Kandidaten, bei dem guides/packaging-guide-review.md existiert:

1. HERE/../build2 (Geschwister-Layout: dieses Verzeichnis neben einem build2-Skill, auch wenn es in ein benutzerebenen-Skills-Verzeichnis kopiert wurde)
2. HERE/../.. (verschachteltes Layout: dieses Verzeichnis unter dem build2-Skill-skills/-Unterverzeichnis)

Wenn keines existiert, stoppe.

Alle späteren read_file-Pfade sind ${ROOT}/....

Dies ist eine schreibgeschützte, lokale Vorab-Prüfung (Sanity Check). Sie soll Paketierungsprobleme erkennen, bevor du veröffentlichst, indem sie dieselbe Checkliste verwendet, die ein cppget.org-Reviewer gegen das Repository verwenden würde. Sie darf niemals ein GitHub-Issue oder einen Pull Request erstellen, kommentieren oder mergen, niemals einen Branch pushen, niemals eine E-Mail senden und niemals das zu prüfende Repository verändern (keine Commits, keine Tags, keine Dateibearbeitungen, kein bdep release, kein bdep publish, kein git push). Wenn ein Schritt unten eine solche Änderung vornehmen würde, überspringe ihn und verwandle ihn stattdessen in einen gemeldeten Befund. Das zu prüfende Repository muss aus dieser Prüfung genau so hervorgehen, wie es hineingegangen ist. Das Erstellen eines Plans für die gemeldeten Befunde, ohne ihn auszuführen, gilt nicht als Änderung – siehe „Planmodus“ weiter unten, wann das zutrifft.

Die Checkliste und die Kriterien in ${ROOT}/guides/packaging-guide-review.md sind die Quelle der Wahrheit. Kopiere die Checklisten-Elemente. Paraphrasiere nicht die erforderlichen Kriterien. Erfinde keine Review-Kriterien.

Reviews decken nur Build- und Paketierungsunterstützung ab. Ignoriere die Qualität des Upstream-Quellcodes, die Upstream-Dokumentation und den Stil des Upstream-C/C++.

Harte Regeln

1. Keine extern sichtbaren Änderungen: niemals ein GitHub-Issue oder einen Pull Request erstellen, kommentieren oder mergen, niemals einen Branch pushen, niemals eine E-Mail senden. Dies ist bedingungslos, es gilt auch, wenn der Benutzer während des Laufs explizit danach fragt: lehne ab und verweise auf den separaten manuellen Review-Workflow (siehe „Stoppen und fragen“ unten), anstatt es hier zu tun.
2. Keine Änderungen am zu prüfenden Repository: keine Commits, Tags oder Dateibearbeitungen, kein git push, kein bdep release, kein bdep publish. Nur Inspektion (git log, git show, git diff, Dateien lesen). Wenn du etwas baust oder testest, um ein Element zu verifizieren, tue dies außerhalb des Baums in einem temporären Verzeichnis, niemals innerhalb des Arbeitsbaums des geprüften Repositorys.
3. Wenn ein lokaler Pfad angegeben wird, verwende ihn an Ort und Stelle, schreibgeschützt. Checke keinen anderen Referenz (ref) aus, stashe oder setze ihn zurück.
4. Wenn ein entferntes Repository oder eine URL angegeben wird, klone es schreibgeschützt in ein temporäres Verzeichnis unter /tmp/claude/. Verwende niemals Push-fähige Remotes oder git push. Behandle den Klon als Wegwerfobjekt.
5. Setze niemals ein Häkchen bei einem Checklisten-Element, ohne es persönlich bei diesem Lauf verifiziert zu haben.
6. Blockierend vs. nicht blockierend folgt den Kriterien des Leitfadens. Wenn du dir unsicher bist, sage dies, anstatt einen konzeptionellen buildfile-Fehler stillschweigend herabzustufen.
7. Die Ausgabe ist ein Bericht im Gespräch (optional auch in eine temporäre Datei unter /tmp/claude/ geschrieben). Veröffentliche ihn niemals extern.

Obligatorische Lektüre (vor der Meldung von Befunden)

Lese diese Dateien vollständig mit read_file, bevor du irgendwelche Befunde meldest. Überfliege sie nicht.

1. ${ROOT}/guides/packaging-guide-review.md
2. ${ROOT}/guides/packaging-guide-antipatterns.md
3. ${ROOT}/HOWTO/package-naming.md
4. ${ROOT}/guides/packaging-guide-testing.md, nur Schritt 9 („Paket testen“). Schritt 10 („Veröffentlichen“) führt review in main zusammen und liegt außerhalb des Rahmens – ignoriere ihn.

Lade bei Bedarf aus der Karte am Ende. Die anfängliche Review-Checkliste in packaging-guide-review.md ist die Checkliste, die du durcharbeitest. Diese Datei ist die einzige Kopie.

Argumente

$ARGUMENTS ist der Text nach /build2-review (oder nach /build2 review). Analysiere der Reihe nach. Die erste übereinstimmende Regel gewinnt.

Erstes Token	Art
leer / weggelassen	automatisch erkennen nach Auflösen des Ziels
initial	vollständige Checkliste für Ersteinreichung
version	neue Upstream-Version, diff-basiert
revision	neue Paketierungs-Revision, diff-basiert mit zusätzlichen Prüfungen
alles andere	als <repo-oder-lokaler-pfad> behandeln und Art automatisch erkennen

Verbleibende Tokens: <repo-oder-lokaler-pfad> (GitHub-URL, Eigentümer/Repo oder ein lokaler Klon-Pfad) und optional <version>. Wenn das Ziel fehlt, frage nach.

Melde die gewählte Art und Version dem Benutzer, bevor du beginnst.

Repository holen

Wenn der Benutzer einen lokalen Pfad angegeben hat, verwende ihn unverändert, schreibgeschützt.

Andernfalls klone schreibgeschützt in ein temporäres Verzeichnis (niemals in diesen Klon pushen, niemals als Push-Ziel für irgendetwas anderes hinzufügen):

git clone --recurse-submodules --shallow-submodules <url> /tmp/claude/<name>

Klassifizieren

Bestimme <VERSION> aus dem manifest-Feld version: (der neueste veröffentlichte Tag, wenn es mehrere Pakete gibt). Bestimme die Art:

Hinweis	Art
Noch kein veröffentlichter Tag, oder der geprüfte Referenz (ref) ist immer noch der erste bdep new Commit	initial
Ein vX.Y.Z-Tag existiert bereits und diese Version ist X.Y.Z+R	revision
Eine vorherige Version wurde getaggt und dies ist ein neues X.Y.Z	version

Überprüfe den ersten Commit des Repositorys (schreibgeschützt):

git log -p "$(git rev-list --all | tail -1)"

Dieser Commit darf nur Dateien enthalten, die von bdep new generiert wurden, und seine Nachricht muss die exakte Befehlszeile sein. Zeichne jede Abweichung als Befund auf. Ignoriere sie nicht.

Art: initial

Arbeite jedes Element im Abschnitt „Anfängliche Review-Checkliste“ von packaging-guide-review.md gegen das Repository durch. Hake ein Element nur ab, nachdem du es persönlich verifiziert hast (Baum, manifest, buildfiles, Installations-Layout, Tests, Tags). Verwende die verlinkten HOWTOs/Leitfäden für jedes Element, anstatt aus dem Gedächtnis.

Klassifiziere jeden Befund genau so, wie es der Leitfaden tut:

Klasse	Wann
Blockierend	hoher Schweregrad oder Auswirkung, viele Benutzer, konzeptioneller Fehler (falsche Compile-Optionen in buildfiles) oder kann später nicht ohne Kompatibilitätsbruch behoben werden
Nicht blockierend	sollte in einer Revision oder der nächsten Version behoben werden, besteht die Prüfung nicht
Hinweis	nur Beobachtung

Lade bei Bedarf während der Prüfung:

• Namen: ${ROOT}/HOWTO/package-naming.md
• Lizenz: ${ROOT}/guides/packaging-license.md
• Begleitpaket -tests Zusammenfassung / README: ${ROOT}/HOWTO/tests-extra-dependencies.md
• Private Header: ${ROOT}/HOWTO/third-party-private-headers.md
• Compile-Optionen: ${ROOT}/HOWTO/buildfile-compile-options.md
• Was nicht zu tun ist: ${ROOT}/guides/packaging-guide-antipatterns.md
• Tagebuchartige Kommentare oder Notizen in buildfiles, manifest oder READMES: ${ROOT}/guides/packaging-guide-antipatterns.md, „Keine tagebuchartigen Kommentare oder Notizen hinterlassen“

Wenn du „Verwendet Git-Submodul und Symlinks für Upstream“ überprüfst: führe zusätzlich in jedem Paketverzeichnis find . -type l -exec test -d {} \; -print aus und bestätige, dass jedes Ergebnis einen passenden symlink=dir-Eintrag in der eigenen <pkg>/.gitattributes dieses Pakets hat (siehe ${ROOT}/guides/packaging-guide-summary.md Schritt 5). git zeichnet den Symlink-Typ nicht auf, daher bricht ein fehlender Eintrag für einen Verzeichnis-Symlink stillschweigend einen Windows-Checkout. Behandle einen fehlenden Eintrag als blockierend.

Installation und Verteilung testen

Die statische Inspektion der Checkliste reicht nicht aus. Baue das Paket auch außerhalb des Baums, um Dinge zu finden, die erst zur Build-Zeit sichtbar werden (fehlende oder private Header im Installationsbaum, Dateien, die im buildfile-Graphen fehlen, kaputte clean-Regeln). Tue dies in einem temporären Verzeichnis unter /tmp/claude/, niemals innerhalb des geprüften Repositorys. Befolge „Schritt 9: Paket testen“ in ${ROOT}/guides/packaging-guide-testing.md:

1. Installierter Fall: b install config.install.root=/tmp/claude/<name>-install, dann baue und führe tests/ quelloffen gegen diese installierte Kopie aus. Bestätige, dass nichts Unerwartetes installiert wurde (keine fehlenden Header, keine privaten Header versehentlich installiert).
2. Quellverteilung: b dist config.dist.root=/tmp/claude/<name>-dist config.dist.uncommitted=true, dann führe im extrahierten Archiv configure, update, test und clean aus. Ein grüner bdep test allein ist nicht ausreichend – so baut cppget.org tatsächlich das Paket.

Entferne beide temporären Verzeichnisse danach. Zeichne jeden Fehlschlag als Befund auf (ein Paket, das nicht korrekt installiert oder verteilt werden kann, ist normalerweise blockierend).

Bericht

Präsentiere die Ergebnisse dem Benutzer unter Verwendung desselben Abschnittslayouts wie der Ergebnis-Kommentar des Leitfadens, aber poste sie nirgendwo:

Blockierende Probleme:

...

Nicht blockierende Probleme:

...

Hinweise:

...

Leere Abschnitte weglassen. Wenn du eine temporäre Kopie geschrieben hast, erwähne ihren Pfad.

Art: version

Vergleiche die Basisversion (zuvor geprüft) mit der Zielversion mittels diff. Bevorzuge ein lokales git diff <alter-tag>..<neuer-tag>, wenn beide Tags im Klon verfügbar sind, andernfalls die GitHub-Vergleichsansicht:

https://github.com/<eigentümer>/<projekt>/compare/vALT...vNEU

Achte auf Build-Level-Kompatibilität: Umbenannte exportierte Ziele oder Konfigurationsvariablen sind brechend, selbst wenn die API des Upstream stabil ist.

Melde eines der folgenden:

1. Keine wesentlichen Paketierungsänderungen, keine Probleme: sage es klar, keine Checkliste nötig.
2. Keine wesentlichen Paketierungsänderungen, es gibt Probleme: liste sie direkt auf (keine Checkliste).
3. Wesentliche Paketierungsänderungen: führe das vollständige initiale Verfahren oben durch, Checkliste plus Installations- und Verteilungs-Test.

Art: revision

Gleiches Vorgehen wie bei version, plus markiere es als Befund, wenn eines dieser Kriterien nicht zutrifft:

• Änderungen sind beschränkt auf Fehlerbehebungen in buildfiles, manifest und ähnlichen Paketierungsdateien.
• Upstream-Quellcode-Fixes sind beschränkt auf kritische Fehler, die aus dem Upstream zurückportiert wurden.
• Streng abwärtskompatibel mit der Version, die es ersetzt.
• Keine wesentlichen strukturellen Änderungen (Quellcode-Layout, exportierte Zielnamen, Konfigurationsvariablennamen).

Planmodus

Dieses Skill bleibt in jedem Fall schreibgeschützt, es führt niemals die Korrekturen selbst aus. Es ändert sich nur, ob ein Plan für die erforderlichen Änderungen und Verbesserungen zusammen mit dem Bericht erstellt wird.

• Wenn die aktuelle Sitzung im Planmodus ist (vom Assistenten wird erwartet, dass er einen Implementierungsplan zur Genehmigung vorschlägt, bevor er Änderungen vornimmt, anstatt sofort zu handeln): erstelle nach dem Bericht auch einen Plan, der die blockierenden und nicht blockierenden Befunde adressiert, und präsentiere ihn über den Plan-Genehmigungsmechanismus, den die Umgebung bereitstellt. Beschränke den Plan auf blockierende und nicht blockierende Befunde, überspringe Hinweise, es sei denn, der Benutzer fragt danach. Gruppiere zusammenhängende Korrekturen und weise auf solche hin, die generiertes bdep new-Layout, manifest oder buildfile-Dateien betreffen, die besondere Sorgfalt oder eine bestimmte Reihenfolge erfordern.
• Andernfalls folge dem etablierten Berichtsablauf oben und höre dort auf. Erstelle, schlage vor oder deute keinen Implementierungsplan an; die Korrekturen sind zur Ausführung durch den Benutzer oder einen separaten Workflow bestimmt.

Stoppen und fragen

Stoppe, anstatt zu raten, wenn einer dieser Fälle zutrifft:

• Du kannst die Version oder die Art nicht bestimmen.
• Du kannst nicht auf das Repository zugreifen (Klonen schlägt fehl, lokaler Pfad ungültig).
• Der erste Commit ist kein bdep new-Commit und der Benutzer hat nicht entschieden, wie dies im Bericht festgehalten werden soll.
• Blockierend vs. nicht blockierend für einen Befund, der die Kompatibilität brechen würde, ist unklar.
• Der Benutzer hat darum gebeten, tatsächlich das GitHub-Review-Issue/PR zu öffnen, etwas zu mergen oder die E-Mail an [email protected] zu senden. Dies ist ein separater, nicht zum Leistungsumfang gehörender Workflow, den dieses Skill nicht ausführt.
• Der Benutzer hat darum gebeten, das Paket zu erstellen statt es zu prüfen (wechsel zu build2-package).

Karte für den Bedarfsfall

Bedarf	Datei
Checkliste und Kriterien	${ROOT}/guides/packaging-guide-review.md
Was nicht zu tun ist	${ROOT}/guides/packaging-guide-antipatterns.md
Namen	${ROOT}/HOWTO/package-naming.md
Lizenz	${ROOT}/guides/packaging-license.md
Begleitpakete	${ROOT}/HOWTO/tests-extra-dependencies.md
Paket erstellen	../build2-package/SKILL.md