verification-before-completion

Überblick über den verification-before-completion Skill

Wofür verification-before-completion gedacht ist

Der verification-before-completion Skill ist ein strikter Final-Check-Workflow für den Moment, kurz bevor du sagst, dass etwas fertig, behoben, erfolgreich durchgelaufen oder bereit für Review ist. Seine Aufgabe ist einfach: ungestützte Erfolgsmeldungen stoppen und zuerst frische Belege erzwingen.

Besonders nützlich ist das bei AI-unterstützter Entwicklung, Agent-Workflows, der Vorbereitung von Commits und der Übergabe an PR-Reviewer. Wenn du schon einmal Aussagen wie „tests should pass“, „the bug is fixed“ oder „build looks good“ gesehen hast, ohne dass der passende Befehl tatsächlich ausgeführt wurde, zielt dieser Skill genau auf diesen Fehlerfall.

Wer diesen Skill installieren sollte

Besonders gut passt der Skill für:

• Entwickler, die AI-Agents zum Bearbeiten von Code einsetzen
• Reviewer, die saubere, belegbare Status-Updates wollen
• Teams, die genug von optimistischen, aber nicht verifizierten Abschlussmeldungen haben
• alle, die Skill-Validation-Muster nutzen, bei denen Nachweis wichtiger ist als Selbstsicherheit

Wenn du vor allem Code-Generierung, Planung oder breit angelegte Debugging-Hilfe suchst, ist das kein Ersatz für diese Skills. Der verification-before-completion Skill ist ein Guardrail, kein vollständiger Delivery-Workflow.

Der eigentliche Job-to-be-done

Die eigentliche Aufgabe ist nicht einfach „Tests ausführen“. Sondern:

1. festlegen, welcher Nachweis die Aussage tatsächlich belegen würde
2. genau diese Verifikation jetzt ausführen
3. die echte Ausgabe lesen
4. nur die Aussage treffen, die von diesem Nachweis gedeckt ist

Das klingt offensichtlich, aber genau an dieser Stelle brechen viele AI-gestützte Workflows. Dieser Skill macht daraus eine harte Hürde, bevor Abschlussformulierungen verwendet werden.

Was diesen Skill anders macht

Der entscheidende Unterschied ist seine enge Fokussierung. verification-before-completion versucht nicht, dein gesamtes Repository intelligent zu verstehen. Er setzt eine einzige, sehr wertvolle Regel durch:

keine Abschlussaussagen ohne frische Verifikationsbelege

Gerade deshalb eignet er sich besonders gut als letzter Absicherungs-Layer. Im Vergleich zu einem normalen „sei vorsichtig und prüfe alles“-Prompt lässt sich dieser Skill zuverlässiger auslösen, weil er eine wiederholbare Entscheidungslogik vorgibt: identifizieren, ausführen, lesen, verifizieren, dann sprechen.

Wann der verification-before-completion Skill besonders gut passt

Verwende den verification-before-completion Skill, wenn du kurz davor bist, Dinge zu sagen wie:

• „tests pass“
• „the bug is fixed“
• „the build succeeds“
• „this is ready to merge“
• „the linter is clean“

Diese Aussagen brauchen jeweils unterschiedliche Belege. Der Skill hilft dabei, einen häufigen Fehler zu vermeiden: etwas nur indirekt Nachgewiesenes zu prüfen und das Ergebnis dann zu weitreichend zu formulieren.

So verwendest du den verification-before-completion Skill

Installationskontext für verification-before-completion

Installiere ihn aus dem Repository obra/superpowers:

npx skills add https://github.com/obra/superpowers --skill verification-before-completion

Da dieser Skill in einer einzigen SKILL.md enthalten ist, ist die Einführung leichtgewichtig. Es gibt keine Helper-Skripte oder zusätzlichen Resource-Dateien, die du zuerst verstehen musst.

Diese Datei zuerst lesen

Starte mit:

• skills/verification-before-completion/SKILL.md

Diese Datei enthält den vollständigen Verhaltensvertrag. Da die unterstützende Repository-Struktur hier sehr schlank ist, reicht es aus, zuerst SKILL.md zu lesen, um zu verstehen, ob der Skill zu deinem Workflow passt.

Welche Eingaben der Skill von dir braucht

Der verification-before-completion Skill funktioniert am besten, wenn du drei Dinge mitgibst:

• die Aussage, die du treffen willst
• den Befehl, der diese Aussage tatsächlich belegen würde
• eventuelle Umgebungsgrenzen, die die Verifikation blockieren

Beispielhafte Eingaben:

• „I want to say the fix works. The proving command is pytest tests/api/test_login.py -q.”
• „I want to say the build passes. The expected verification is npm run build.”
• „I think lint is clean, but I have not run ruff check . yet.”

Ohne eine konkrete Aussage und einen konkreten Befehl kann der Skill nur allgemeine Vorsichtshinweise geben.

Aus einem groben Ziel einen brauchbaren Prompt machen

Schwacher Prompt:

• „Can I say this is done?”

Besserer Prompt:

• “Before I claim this is complete, apply the verification-before-completion skill. The claim is: ‘the login bug is fixed.’ The best proving command is pytest tests/auth/test_login_bug.py -q. If that is not enough, tell me what additional verification is required.”

Warum das besser ist:

• die Aussage wird klar benannt
• ein möglicher Nachweispfad wird vorgeschlagen
• der Skill darf zu schwache Verifikation ausdrücklich infrage stellen

So rufst du den Skill in der Praxis auf

Setze verification-before-completion direkt vor jeder Abschlussnachricht, Commit-Zusammenfassung oder PR-Notiz ein. Ein praxistauglicher Ablauf ist:

1. die Code-Änderung abschließen
2. entscheiden, welche exakte Aussage du treffen willst
3. den Befehl identifizieren, der diese Aussage belegt
4. den vollständigen Befehl frisch ausführen
5. Ausgabe und Exit-Status prüfen
6. die Aussage abschwächen oder einschränken, wenn die Belege unvollständig sind

Diese Reihenfolge ist wichtig. Der Skill ist genau an dem Punkt am wertvollsten, an dem Menschen dazu neigen, zu optimistisch zusammenzufassen.

Aussagen mit dem richtigen Nachweis abgleichen

Ein großer praktischer Vorteil des verification-before-completion Skills ist, dass er Nachweis-Mismatch verhindert.

Beispiele:

• Aussage: „Tests pass“
  Nachweis: der relevante vollständige Testbefehl mit null Fehlern

• Aussage: „Linter is clean“
  Nachweis: der Linter-Befehl mit null Fehlern

• Aussage: „Build succeeds“
  Nachweis: der Build-Befehl mit erfolgreichem Exit

• Aussage: „Bug is fixed“
  Nachweis: ein Verifikationsschritt, der den ursprünglichen Fehlerpfad reproduziert und jetzt erfolgreich durchläuft

Ein erfolgreicher Linter-Lauf belegt keinen erfolgreichen Build. Eine geänderte Datei belegt keinen Bugfix. Genau an dieser Unterscheidung scheitern viele schwache Agent-Ausgaben.

Was als frischer Verifikationsbeleg gilt

Frisch bedeutet: Der Befehl wurde für genau diesen aktuellen Stand der Arbeit ausgeführt, nicht nur aus einem früheren Versuch in Erinnerung behalten. In der Praxis heißt das:

• keine alten Terminal-Ausgaben als Grundlage verwenden
• nicht annehmen, dass unveränderte Dateien automatisch unveränderte Ergebnisse bedeuten
• Erfolg nicht aus benachbarten Signalen ableiten
• keine Teilverifikation für eine weiter gefasste Aussage verwenden

Wenn du nach dem letzten Lauf Code geändert hast, ist dieser alte Lauf für Abschlussaussagen nicht mehr belastbar.

Was tun, wenn du die Verifikation nicht ausführen kannst

Manchmal blockiert die Umgebung die Ausführung: fehlende Abhängigkeiten, keine Zugangsdaten, nicht verfügbare Services, nicht unterstütztes OS oder Zeitdruck. In diesem Fall solltest du die stärkere Aussage nicht treffen.

Verwende stattdessen belegbasierte Formulierungen:

• “I made the change, but I could not run npm test in this environment.”
• “The fix is implemented, but build verification remains unconfirmed.”
• “I verified formatting only; full integration tests were not run.”

Auch dann ist der Einsatz von verification-before-completion erfolgreich, denn bei diesem Skill geht es um wahrheitsgemäße Statuskommunikation, nicht um erzwungene Gewissheit.

Praktisches Prompt-Muster für Agents

Ein starkes wiederverwendbares Prompt-Muster:

“Use the verification-before-completion skill before any success claim. For each claim, identify the proving command, run it fresh if possible, read the full output, and only state what the evidence confirms. If verification is blocked, report the limitation instead of implying success.”

Das funktioniert gut in Agent-Instruktionen, PR-Assistenten und Commit-Generierungs-Workflows.

Bester Workflow für Skill-Validation-Anwendungsfälle

Für verification-before-completion for Skill Validation solltest du den Skill als finalen Validator behandeln, nicht als Hauptwerkzeug. Eine gute Reihenfolge ist:

1. einen anderen Skill zum Implementieren oder Debuggen verwenden
2. zu verification-before-completion wechseln
3. die enge Aussage verifizieren, die du veröffentlichen willst
4. eine Zusammenfassung mit Befehl und Ergebnisbelegen erstellen

Diese Trennung verbessert das Vertrauen, weil Implementierung und Validierung nicht ineinander verschwimmen.

FAQ zum verification-before-completion Skill

Ist verification-before-completion nur eine Erinnerung, Tests auszuführen?

Nein. Der verification-before-completion Skill ist strenger als eine bloße Erinnerung. Er erzwingt eine Zuordnung von Aussage zu Nachweis. Es geht nicht nur darum, „irgendetwas auszuführen“, sondern den Befehl auszuführen, der genau die Aussage belegt, die du gleich treffen willst.

Ist dieser Skill für Einsteiger nützlich?

Ja, besonders für Einsteiger, die noch lernen, was unterschiedliche Checks tatsächlich belegen. Der Skill vermittelt eine starke Gewohnheit: Nicht über die eigenen Belege hinaus verallgemeinern. Diese Gewohnheit verbessert sowohl die technische Genauigkeit als auch das Vertrauen von Reviewern.

Wann sollte ich verification-before-completion nicht verwenden?

Verwende ihn nicht als einzigen Coding- oder Debugging-Skill. Er entwirft keine Architektur, findet keine Root Causes und schreibt dir keinen vollständigen Testplan. Er ist ein Abschluss-Checkpoint und funktioniert am besten zusammen mit umsetzungsorientierten Skills.

Warum ist das besser als ein gewöhnlicher Prompt?

Ein gewöhnlicher Prompt sagt oft „verify before answering“, aber Agents driften trotzdem in weiche, unklare Aussagen ab. Der verification-before-completion skill ist besser, wenn du vor Abschlussaussagen ein konsistentes Gate mit klaren Folgen für ungestützte Behauptungen willst.

Braucht der Skill einen bestimmten Stack oder eine bestimmte Toolchain?

Nein. Der Skill ist stack-agnostisch, weil seine Logik auf Belegen basiert, nicht auf Sprache oder Framework. Du lieferst den passenden Nachweis-Befehl für deine Umgebung, egal ob das pytest, npm test, go test, cargo test oder ein anderer Verifier ist.

Kann ich ihn auch nutzen, wenn vollständige Verifikation zu teuer ist?

Ja, aber dann muss die Aussage entsprechend enger formuliert sein. Wenn du nur einen gezielten Test ausgeführt hast, dann sag, dass genau dieser Test erfolgreich war. Mache daraus nicht „everything passes“, wenn du den breiteren Nachweis nicht ausgeführt hast.

So verbesserst du den verification-before-completion Skill

Nenne die Aussage, bevor du um Validierung bittest

Die größte Verbesserung der Ausgabequalität erreichst du, wenn du den exakten Satz nennst, den du schreiben möchtest. Zum Beispiel:

• schwach: „validate this“
• stark: “I want to say: ‘the payment bug is fixed and tests pass’”

So kann der Skill zusammengesetzte Aussagen sauber trennen und jedem Teil den passenden Nachweis zuordnen.

Den besten Nachweis-Befehl ausdrücklich angeben

Lass den Skill nicht über Repository-Konventionen raten, wenn du sie bereits kennst. Stärkere Eingabe:

• “The canonical project check is make test.”
• “The bug is proven by pytest tests/payments/test_refund.py -q plus npm run build.”

Das reduziert falsches Vertrauen, das aus unvollständigen Checks entsteht.

Implementierungsstatus und verifizierten Status trennen

Ein häufiger Fehler ist, „Ich habe den Code geändert“ mit „Das Problem ist gelöst“ zu vermischen. Verbessere die verification-before-completion usage, indem du um eine zweiteilige Antwort bittest:

• was geändert wurde
• was tatsächlich verifiziert wurde

So bleiben Zusammenfassungen ehrlich, auch wenn die Ausführung blockiert ist.

Breite Aussagen aus schmalen Checks vermeiden

Wenn du einen einzelnen fokussierten Test ausgeführt hast, solltest du den Skill nicht bitten, das ganze Repository abzusegnen. Bessere Formulierung:

• “Can I say the targeted regression test now passes?”
• nicht “Can I say the system is fully fixed?”

Das ist eine der wertvollsten Gewohnheiten, die der Skill fördert.

Bei teilweisen Belegen um abgeschwächte Formulierungen bitten

Eine praktische Möglichkeit, den verification-before-completion guide im echten Arbeitsalltag zu verbessern, ist das Anfordern einer Fallback-Formulierung:

• “If the claim is too strong for the evidence, rewrite it to the strongest accurate version.”

Damit wird der Skill nicht nur zu einem Blocker, sondern auch zu einem Werkzeug für bessere Kommunikation.

Nach wesentlichen Änderungen erneut ausführen

Wenn du nach einem erfolgreichen Verifikationslauf noch Code änderst, nutze den verification-before-completion Skill erneut. Frische Belege beziehen sich auf den aktuellen Stand, nicht auf den vorherigen Entwurf. Das ist besonders wichtig in schnellen Agent-Loops, in denen ein „kleiner letzter Feinschliff“ frühere Checks entwerten kann.

Belege in die Abschlusszusammenfassung aufnehmen

Für mehr Vertrauen solltest du den Nachweis direkt in die Abschlussnotiz aufnehmen:

• ausgeführter Befehl
• Pass/Fail-Ergebnis
• eventuelle Grenzen oder Auslassungen

Beispiel:

• “Verified with pytest tests/auth/test_login_bug.py -q: passed, 1 test, 0 failures.”
• “Did not verify full integration suite in this environment.”

Dieser Stil macht den Skill wertvoller für Reviewer und für dein zukünftiges Ich.

Auf das häufigste Fehlmuster achten

Der häufigste Fehlgebrauch von verification-before-completion for Skill Validation besteht darin, Erfolg aus Absicht, Code-Änderungen oder Erwartungen abzuleiten statt aus echter Ausgabe. Wenn du bessere Ergebnisse willst, stelle vor jeder Abschlussnachricht noch eine letzte Frage:

“What command output would make this statement true?”

Wenn du darauf keine klare Antwort geben kannst, ist die Aussage wahrscheinlich noch nicht bereit.