Install
npx skills add tw93/Waza -a claude-code codex cursor -g -yFür wen
Wenn Sie Features schon planen und Defekte beheben und der Agent dieselben Gewohnheiten fahren soll statt zu improvisieren, passt dieser Skill. Offiziell: die Engineering-Gewohnheiten, die Sie schon kennen, in Skills verwandeln, die der Agent ausführen kann.
Nach der Installation erhalten Sie eine Gruppe Slash-Skills. Die Seite nennt /think, /check, /hunt. In Claude Code tippen Sie die Slash-Befehle direkt. In Codex rufen Sie sie über den installierten Skill-Namen auf und folgen denselben Schritten. Die Seite erwähnt außerdem Cursor, Gemini CLI, Copilot, Amp, Kimi Code CLI, und andere Agenten, die dasselbe gemeinsame Verzeichnis lesen, können diese acht Skills aufnehmen. Das ist eine Verzeichnislesebeziehung, keine exklusive Namensmenge.
Besser geeignet ist, wer ein öffenbares Ziel-Repository hat und zuerst einen schreibgeschützten Plan oder Check will, statt den Agenten sofort implement sagen zu lassen. Offizielle Hinweise:
https://github.com/tw93/waza
Erster Versuch in 3 Minuten
Nur diesen offiziellen Installationsweg verwenden:
npx skills add tw93/Waza -a claude-code codex cursor -g -y
Der Befehl legt eine Kopie ins gemeinsame Skill-Verzeichnis ~/.agents/skills. Claude Code hängt per Symlink an. Codex, Cursor und andere Agenten, die dieses Verzeichnis lesen, erkennen die Skills dann als Namen wie /check und /think. Die Seite gibt keinen zweiten Installer als Hauptweg.
Voraussetzungen: dieser Rechner kann den npx-Befehl oben bereits ausführen, und Sie haben mindestens einen Agenten geöffnet, der ~/.agents/skills liest. Der Installationsort ist dieses gemeinsame Verzeichnis. Nicht von Hand in einen anderen Ordner kopieren.
Für die erste Aufgabe eine umkehrbare, analyseorientierte Aktion wählen. Nach dem Öffnen des Ziel-Repositorys in Claude Code /check eingeben, oder zuerst /think nur für den Plan. In Codex dieselbe Prüfung oder denselben Plan über den Skill-Namen aufrufen. Beim ersten Mal nicht implement sagen. Erfolgssignal: die Skills erscheinen unter Namen wie /check und /think, und /check kann aus dem öffentlichen Kontext des Repositorys ein Prüfergebnis liefern statt zu sagen, der Skill sei nicht installiert.
Anwendungsbeispiele
Beispiel 1: zuerst die Funktion planen, dann entscheiden, ob implementiert wird.
Offiziell steht Funktionsplanung so: /think, den Plan genehmigen, dann implement X sagen, dann /check, erst danach merge. Beim ersten Mal nur bis /think laufen und den Plan lesen. Die Belege schreiben weder, wie ein Genehmigen-Knopf aussieht, noch einen konkreten Merge-Befehl. Bestätigen lässt sich diese Reihenfolge und dass die Umsetzung nach Annahme des Plans geschehen soll.
Beispiel 2: zuerst die Ursache suchen, dann Code ändern.
Offiziell steht Defektbehebung so: /hunt, dann reparieren, dann /check, dann Nacharbeit. Die Seite schreibt Nacharbeit als release/publish/push/issue follow-through, entfaltet diese Schritte aber nicht. Beim ersten Mal nur /hunt laufen. Wenn die Ursachenbeschreibung zum Symptom passt, erst dann ändern. /hunt ist zum Bestätigen der Ursache geschrieben, nicht zum sofortigen Loslegen.
Beide Beispiele stehen auf demselben Installationsweg. /check kann einem Plan oder einer Reparatur folgen, aber beim ersten Mal die Prüfung allein laufen und bestätigen, dass öffentlicher Kontext gelesen wurde.
Grenzen
Waza liefert nur allgemeine Engineering-Gewohnheiten. /check liest zur Laufzeit den öffentlichen Kontext des Ziel-Repositorys, darunter README, Paketmanifeste, Makefile, CI-Workflows und die Einschränkungen dieser Aufgabe. Es liest keine privaten Pfade, Anmeldedaten oder Token. Die Seite schreibt nicht, dass es auf private Konfiguration oder Geheimnisse zugreifen kann.
Der Installationsbefehl nennt die drei Ziele claude-code, codex und cursor; die Kopie landet in ~/.agents/skills. Andere Agenten, die dieses Verzeichnis lesen, können die Skills aufnehmen, aber die Seite gibt nicht für jeden Namen ein Auslösebeispiel. Neben Claude-Code-Slashes und Codex-Aufrufen nach Name ist für andere Umgebungen nur bestätigt: „lesen sie das gemeinsame Verzeichnis, erscheinen diese acht Skills“.
Die Seite schreibt keinen Sprachumfang, kein Kontingent und keinen Pflicht-Repositorytyp. Fehlt öffentlicher Kontext im Ziel-Repository, gibt die offizielle Seite kein separates Fehlerbeispiel, wie weit /check kommt.