review

Überblick über die review skill

Was die review skill macht

review ist eine Pre-Landing-PR-Review-Skill, die Diffs gegen den Basis-Branch prüft, bevor Code gemerged wird. Sie richtet sich an Reviewer, die mehr brauchen als einen generischen Prompt: Im Fokus stehen konkrete strukturelle Risiken wie SQL-Sicherheit, Verstöße gegen Trust Boundaries, bedingte Seiteneffekte, Shell Injection und die Vollständigkeit von Enums.

Wer sie nutzen sollte

Nutze die review skill, wenn du kurz davor bist, Code einzuspielen, auf „review this PR“ antwortest oder einen konsistenten review for PR Review-Workflow über mehrere Repos hinweg brauchst. Besonders hilfreich ist sie für Agents, die echte Defekte schnell markieren und laute Stilkommentare vermeiden sollen.

Warum sie sich unterscheidet

Die Skill ist bei Reihenfolge und Priorisierung im Review klar meinungsstark. Sie stellt kritische Sicherheitsprüfungen an den Anfang, danach folgen Themen mit niedrigerer Schwere, und sie unterstützt spezialisierte Review-Pfade für Bereiche wie Tests, Security, Performance und Wartbarkeit. Dadurch ist der review guide deutlich handlungsorientierter als ein breiter „Scan den Diff“-Prompt.

Passung und Grenzen

Am stärksten ist sie bei Codeänderungen mit einem klaren Git-Diff und einem aussagekräftigen Basis-Branch. Weniger nützlich ist sie für abstrakte Designkritik, Copy-Edits in Produkttexten oder Fälle, in denen der Nutzer nur Lob oder eine Zusammenfassung möchte. Wenn du eher eine leichte Einschätzung als ein Fix-first-Review brauchst, reicht ein generischer Prompt oft aus.

review skill verwenden

Installieren und auslösen

Installiere mit npx skills add garrytan/gstack --skill review. Die Skill ist darauf ausgelegt, auf Formulierungen wie „review this PR“, „code review“, „check my diff“ und „pre-landing review“ zu reagieren. Deshalb sollte der Input nach Möglichkeit immer die Änderung und den Vergleichspunkt benennen.

Gib der Skill ein echtes Review-Ziel

Das beste review usage beginnt mit einer diff-basierten Anfrage, nicht mit einer vagen Bitte. Gute Inputs nennen Repo, Branch und Ziel:

• „Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.“
• „Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.“

Diese Dateien zuerst lesen

Für eine praxisnahe Prüfung der review install-Verkettung solltest du zuerst SKILL.md lesen, dann checklist.md, design-checklist.md und greptile-triage.md. Wenn du den Workflow anpassen willst, wirf außerdem einen Blick in TODOS-format.md und den Ordner specialists/, um zu verstehen, welche Probleme an Subagents und welche an die Haupt-Checkliste gehen.

Nutze den Workflow, den die Skill erwartet

Das Repo ist auf einen Zwei-Pass-Review ausgelegt: zuerst kritische Sicherheitsprüfungen, dann informative Punkte. Ein starker Prompt sollte verwertbare Ausgaben mit Datei-/Zeilenangaben und konkreten Fixes verlangen, nicht nur „find bugs“. Wenn du den betroffenen Änderungsbereich kennst, nenne ihn, damit die Skill den passenden Spezialistenpfad priorisieren kann.

review skill FAQ

Ist review besser als ein normaler Prompt?

Ja, wenn du ein reproduzierbares PR-Review-Verhalten brauchst. Ein normaler Prompt kann Scope-Regeln, Eskalationsreihenfolge oder das Routing an Spezialisten übersehen. Die review skill baut all das in den Workflow ein und reduziert so das Rätselraten darüber, was zuerst geprüft werden soll.

Ist die review skill anfängerfreundlich?

Meistens ja, solange der Nutzer Branch oder PR beschreiben kann. Anfänger profitieren von der geführten Checkliste, müssen aber trotzdem einen echten Diff und genug Kontext liefern, um beabsichtigtes Verhalten von Regressionen zu unterscheiden.

Wann sollte ich review nicht verwenden?

Nicht verwenden für No-Code-Fragen, Brainstorming oder abstrakte Architekturgespräche ohne konkreten Änderungssatz. Sie ist auch nicht passend, wenn du nur einen schnellen Plausibilitätscheck willst und keine Findings auf Zeilenebene brauchst.

Was sollte ich von review for PR Review erwarten?

Erwarte knappe, auf Fixes ausgerichtete Kommentare mit priorisierter Schwere. Die Skill ist darauf ausgelegt, Landing-Blocker sichtbar zu machen, nicht das ganze Repo nachzuerzählen oder eine Jubelzusammenfassung zu liefern.

review skill verbessern

Gib präzisere Inputs

Die stärksten review skill-Inputs nennen den Basis-Branch, das riskante Subsystem und den gewünschten Standard. Statt „review my PR“ besser: „review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients.“

Füge Kontext hinzu, der das Urteil verändert

Wenn die Änderung bewusst riskant ist, sag es dazu. Wenn ein Muster laut Projektpolitik erlaubt ist, erwähne das direkt. Das reduziert False Positives und hilft dem Review, sich auf echte Abwägungen zu konzentrieren, statt bekannte Entscheidungen erneut aufzurollen.

Fordere das Format an, das du brauchst

Wenn du eine landungsorientierte Ausgabe willst, bitte um Findings mit file:line, Schweregrad und konkreten Fixes. Wenn du nur Blocker möchtest, sag das ausdrücklich. Wenn du Spezialisten-Abdeckung brauchst, fordere sie explizit an, damit das Review nicht nach dem ersten Durchlauf endet.

Nach dem ersten Durchlauf iterieren

Nutze das erste Review, um offensichtliche Probleme zu beheben, und lasse review anschließend erneut über den aktualisierten Diff laufen. Die größten Qualitätsgewinne entstehen meist dadurch, dass du den Scope schärfst, den Vergleichs-Branch enger fasst und der Skill genau den Risikobereich gibst, der dir am wichtigsten ist.