check

Überblick über das check skill

Was das check skill macht

Das check skill ist ein Review- und Freigabe-Workflow für Code-Diffs, PRs, Issue-Triage, Release-Readiness, Pushes und Projekt-Audits. Es eignet sich am besten für Nutzer, die schnell, aber diszipliniert eine Antwort auf die Frage wollen: „Ist das sicher auslieferbar, was ist kaputt, und was muss ich vor dem Mergen beheben?“

Wann dieses check skill am besten passt

Nutze das check skill, wenn du Code Review für einen konkreten Änderungsumfang brauchst, etwa vor dem Merge, vor einem Release oder zur Validierung generierter Artefakte und nachgelagerter Maßnahmen. Besonders hilfreich ist es, wenn der Agent zuerst den Worktree prüfen, versteckte lokale Änderungen vermeiden und behebbare Probleme von Punkten trennen soll, die menschliche Rücksprache brauchen.

Was check von anderen Ansätzen unterscheidet

Das check skill ist kein generischer Prompt nach dem Motto „schau dir diesen Code an“. Es bringt explizite Sicherheitsprüfungen für verschmutzte oder ungetrackte Worktrees mit, einen klaren Workflow mit Review an erster Stelle und Routing zu Spezialprüfungen, wenn Architektur- oder Sicherheitsrisiken im Spiel sind. Dadurch ist es robuster als ein einmaliger Prompt für check for Code Review, weil weniger geraten werden muss, wann geprüft wird, was geprüft wird und wann Schluss ist.

So verwendest du das check skill

check installieren und auslösen

Installiere es mit:

npx skills add tw93/Waza --skill check

Rufe es dann auf, wenn du ein konkretes Review-Ziel hast: einen Diff, einen Branch, einen PR, einen Release-Kandidaten, einen Commit-Bereich oder einen Audit-Auftrag für das Repo. Für check usage gib dem Agenten einen klar abgegrenzten Scope, zum Beispiel „prüfe die letzten 3 Commits“, „checke diesen PR vor dem Merge“ oder „prüfe die Release-Readiness nach Dependency-Updates“.

Gib dem check skill die richtige Eingabe

Die stärkste Eingabe für check ist nicht „ist das gut?“, sondern eine begrenzte Aufgabe mit Kontext. Gute Beispiele:

• „Check diesen PR vor dem Merge auf Sicherheits- und Architekturregressionen.“
• „Prüfe den aktuellen Worktree und sag mir, was den Release blockiert.“
• „Auditiere die generierten Dateien und sag mir, ob sie zu den Source-Änderungen passen.“

Nenne Branch, Commit-Bereich, geplantes Release und alle Einschränkungen wie „Dateien nicht ändern“ oder „nur öffentlichen Repo-Kontext prüfen“. So vermeidest du zu breite, unklare Review-Ausgaben.

Diese Dateien zuerst lesen

Beginne mit SKILL.md und sieh dir dann references/project-context.md und references/persona-catalog.md an, um Review-Tiefe, Routing zu Spezialrollen und Release-Erwartungen zu verstehen. Nutze agents/reviewer-security.md und agents/reviewer-architecture.md, wenn der Diff Vertrauensgrenzen, APIs, Imports oder die Modulstruktur berührt. references/public-reply.md ist wichtig, wenn der Workflow ein Follow-up von Maintainer-Seite bei Issues oder PRs umfasst.

Praktische Workflow-Tipps

Vor dem Review erwartet das check skill eine Worktree-Sicherheitsprüfung mit git status --short --branch -uall. Das ist wichtig, weil schmutzige oder ungetrackte Änderungen die Bedeutung des Reviews verändern können. Wenn du ein besseres check guide-Ergebnis willst, sag dem Agenten, ob er nur Findings melden soll, ob er sichere Probleme selbst beheben darf und welcher Verifikationsbefehl nach Änderungen verwendet werden soll.

FAQ zum check skill

Ist check nur für Code Review gedacht?

Nein. Das check skill deckt auch Release-Readiness, Pushes, veröffentlichte Artefakte, Issue- und PR-Triage sowie projektweite Audits ab. Es passt besser als ein normaler Prompt, wenn zur Aufgabe auch eine „vor dem Ausliefern“-Bewertung gehört und nicht nur das Lesen von Code.

Wann sollte ich check nicht verwenden?

Verwende check nicht für offene Ideensuche, Root-Cause-Debugging oder Textbearbeitung. Das Skill ist für konkrete Diffs und operative Reviews gedacht, nicht für Brainstorming oder narrative Rückmeldungen.

Ist check anfängerfreundlich?

Ja, wenn du Ziel und gewünschtes Ergebnis benennen kannst. Anfänger erzielen die besten Ergebnisse, wenn sie genau sagen, was sich geändert hat, was geprüft werden soll und ob sie nur Findings oder zusätzlich sichere Fixes möchten. Ohne diese Angaben mag check install einfach sein, aber check usage wird zu breit, um verlässlich zu sein.

Worin unterscheidet es sich von einem normalen Prompt?

Ein normaler Prompt fordert meist eine subjektive Einschätzung an. check ergänzt einen disziplinierten Ablauf: Sicherheits-Preflight, Scope-Kontrolle, erwartete Verifikation und Routing zu Spezialprüfungen für Sicherheit oder Architektur. Dadurch ist es für check for Code Review verlässlicher als eine ad-hoc formulierte Review-Anfrage.

So verbesserst du das check skill

Liefere ein schärferes Review-Briefing

Am nützlichsten sind diese Angaben: was sich geändert hat, warum es sich geändert hat, was auf keinen Fall kaputtgehen darf und welche Art von Review du willst. Zum Beispiel: „prüfe nur den Authentifizierungspfad“, „fokussiere dich auf Release-Artefakte“ oder „checke, ob dieses Refactoring öffentliche APIs verändert“. Das grenzt die Suche ein und verbessert die Aussagekraft.

Mach die harten Einschränkungen sichtbar

Sag dem Skill etwas über Packaging-Regeln, generierte Dateien, geschützte Pfade und erforderliche Verifikationsbefehle. Wenn das Repo eine Build- oder Release-Quelle der Wahrheit hat, nenne sie direkt. Das reduziert falsche Sicherheit und hilft dem check skill, Drift, fehlende Artefakte oder unsichere Folgeänderungen zu erkennen.

Iteriere auf Basis von Findings, nicht von Lob

Antworte nach dem ersten Durchlauf mit den konkreten Findings, die erneut geprüft werden sollen, oder mit dem Patch, den du angewendet hast. Das Skill wird besser, wenn du einen zweiten Durchlauf jeweils nur auf einen Risikobereich fokussierst, etwa Sicherheit, Architektur oder Release-Readiness. Wenn die Ausgabe zu breit wirkt, verenge den Scope statt nach „mehr Details“ zu fragen.