self-eval

Überblick über den self-eval skill

Wofür self-eval gedacht ist

Der self-eval skill ist ein rein promptbasierter Claude Code Skill für ehrliche Bewertungen nach abgeschlossener Arbeit. Er hilft einem AI Agent, die eigene Ausgabe nach einer Aufgabe, einem Code Review, einer Implementierungssitzung, einer Debugging-Runde oder einer Planungsphase einzuschätzen, ohne in vages Lob oder überhöhte „4/5“-Bewertungen zu verfallen.

Statt auf einer einzigen subjektiven Skala zu fragen „Wie gut war das?“, trennt self-eval die Bewertung in zwei Achsen: Anspruch der Aufgabe und Qualität der Ausführung. Dadurch eignet sich der Skill besonders, wenn Sie eine kalibrierte Antwort auf die Frage brauchen: „War das wirklich starke Arbeit – oder nur solide Arbeit an einer einfachen Aufgabe?“

Für welche Nutzer und Aufgaben self-eval am besten passt

Nutzen Sie den self-eval skill, wenn ein Agent abgeschlossene Arbeit prüfen soll, bevor Sie sie akzeptieren, mergen oder darauf weiter aufbauen. Besonders relevant ist das für Engineering-Teams, die AI für Codegenerierung, Refactoring, Issue-Triage, Test-Erstellung oder Architektur-Analysen einsetzen.

Der Skill ersetzt keine Test-Suites, kein menschliches Review, kein Security Review und keine Produktionsvalidierung. Sein Wert liegt in strukturierter Selbstkritik: übermäßiges Selbstvertrauen erkennen, Schwächen sichtbar machen und über mehrere Arbeitssitzungen hinweg eine Bewertungshistorie aufbauen.

Was self-eval von einem normalen Prompt unterscheidet

Ein normaler Prompt wie „Bewerte deine Arbeit“ führt oft zu generischen positiven Aussagen, vorsichtigen Einschränkungen und einer optimistischen Punktzahl. self-eval ergänzt Vorgaben, die Score-Inflation erschweren: verpflichtende Devil’s-Advocate-Argumentation, eine feste Bewertungsmatrix und die Speicherung von Scores in .self-eval-scores.jsonl.

Diese Persistenz ist wichtig. Wenn sich aktuelle Bewertungen zu eng häufen, kann der Skill Muster von Score-Inflation markieren, statt jede Bewertung isoliert zu betrachten.

So verwenden Sie den self-eval skill

Installation von self-eval und Repository-Prüfung

Installieren Sie den Skill aus der GitHub-Quelle mit Ihrem Skill Manager, zum Beispiel:

npx skills add alirezarezvani/claude-skills --skill self-eval

Der relevante Repository-Pfad lautet:

engineering/skills/self-eval/SKILL.md

In der aktuellen Struktur gibt es keine externen Abhängigkeiten, Helper-Skripte, gebündelten Regeln oder Referenzdateien. Für eine schnelle Prüfung vor der Installation sollten Sie zuerst SKILL.md lesen; dort stehen Bewertungsmodell, Workflow und erwartetes Ausgabeformat. Da es sich um einen rein promptbasierten Skill handelt, ist das Einführungsrisiko niedrig. Die Qualität der Ausgabe hängt jedoch stark davon ab, ob Sie genügend Aufgabenkontext liefern.

Welche Eingaben der self-eval skill benötigt

Für eine hilfreiche Nutzung von self-eval reicht „Bewerte das“ nicht aus. Geben Sie dem Agent die abgeschlossene Arbeit und den Maßstab, an dem sie bewertet werden soll.

Starke Eingaben enthalten:

• Die ursprüngliche Nutzeranfrage oder Issue-Beschreibung
• Die finale Antwort, den Patch, den Plan oder das Review, das der Agent erstellt hat
• Relevante Einschränkungen, etwa Zeitlimits, Style-Regeln, Testanforderungen oder verbotene Ansätze
• Validierungsnachweise, zum Beispiel ausgeführte Tests, geänderte Dateien, ausgeführte Commands oder bekannte Lücken
• Die Zielgruppe: Maintainer, Reviewer, Product Owner, Einsteiger oder Produktionsteam

Ein schwacher Prompt fragt nach einer Punktzahl. Ein starker Prompt liefert dem Skill genug Evidenz, um „geringer Anspruch, aber sauber umgesetzt“ von „hoher Anspruch, aber unvollständig“ zu unterscheiden.

Prompt-Muster für bessere Ergebnisse mit self-eval

Verwenden Sie self-eval nach Abschluss der Arbeit, nicht davor. Ein praxistauglicher Prompt sieht so aus:

Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.

Diese Struktur verbessert das Ergebnis, weil das Modell nicht nur Tonfall oder Aufwand bewertet. Die Bewertung muss Anspruch, Ausführung, Evidenz und verbleibende Risiken berücksichtigen.

Empfohlener Workflow für self-eval

Führen Sie self-eval an Kontrollpunkten aus, an denen eine irreführend positive Einschätzung teuer werden könnte:

1. Aufgabe abschließen oder Lösung entwerfen.
2. self-eval mit ursprünglichem Ziel und Arbeitsnachweisen anfordern.
3. Den Devil’s-Advocate-Abschnitt vor der finalen Punktzahl lesen.
4. Die Schwächen in eine kurze Fix-Liste überführen.
5. Erst nach substanziellen Änderungen erneut ausführen, nicht nach rein kosmetischen Anpassungen.

Wenn .self-eval-scores.jsonl in Ihrem Arbeitsverzeichnis erstellt wird, behandeln Sie die Datei als lokale Bewertungshistorie. Entscheiden Sie im Team, ob diese Datei committed, ignoriert oder regelmäßig geprüft werden soll.

FAQ zum self-eval skill

Ist self-eval für Model Evaluation oder für Codequalität gedacht?

Es ist für beides nützlich, allerdings in einem klar abgegrenzten Sinn. self-eval für Model Evaluation bedeutet hier vor allem aufgabenbezogene Bewertung der eigenen Arbeit eines AI Agent, nicht benchmarkfähige Modellmessung. Der Skill kann helfen, Sitzungen zu vergleichen, überhöhte Selbstbewertungen zu erkennen und die Review-Disziplin zu verbessern. Er ersetzt jedoch keine formalen Eval-Harnesses, Golden Datasets oder von Menschen gelabelte Bewertungen.

Wann sollte ich self-eval nicht verwenden?

Verwenden Sie den Skill nicht als einziges Gate für risikoreiche Arbeit: sicherheitsrelevante Änderungen, rechtliche oder medizinische Inhalte, Produktionsmigrationen oder alles, was nachweislich korrekt sein muss. Vermeiden Sie ihn auch, wenn es kein konkretes Artefakt zur Bewertung gibt. Der Skill braucht eine Aufgabe, ein Ergebnis und Bewertungskriterien; andernfalls erzeugt er zwar weiterhin Struktur, aber auf schwacher Evidenzbasis.

Ist self-eval einsteigerfreundlich?

Ja, weil der Skill rein promptbasiert ist und keine Tooling-Abhängigkeiten hat. Einsteiger sollten trotzdem vor der Nutzung SKILL.md lesen, insbesondere die Bewertungslogik. Die eigentliche Lernkurve liegt nicht in der Installation, sondern darin, genug Kontext bereitzustellen, damit die Bewertung nicht auf Bauchgefühl basiert.

Worin unterscheidet sich self-eval von einer einfachen Kritik?

Eine Kritik kann Probleme auflisten, ohne kalibrierte Bewertung zu liefern. self-eval nutzt ein Zwei-Achsen-Modell und eine matrixgebundene finale Punktzahl. Dadurch hat der Agent weniger Spielraum, nachträglich eine Bewertung zu rechtfertigen, die sich einfach „richtig anfühlt“. Der Devil’s-Advocate-Schritt verlangt außerdem, zunächst sowohl für eine höhere als auch für eine niedrigere Bewertung zu argumentieren, bevor das finale Urteil festgelegt wird.

So verbessern Sie den self-eval skill

Geben Sie self-eval belastbarere Evidenz

Der beste Weg, Ergebnisse mit self-eval zu verbessern, ist konkrete Evidenz. Nennen Sie geänderte Dateien, fehlgeschlagene oder erfolgreiche Tests, wichtige Auslassungen und Akzeptanzkriterien. Wenn keine Tests ausgeführt wurden, sagen Sie das. Wenn die Antwort absichtlich eine Anforderung übersprungen hat, gehört auch das in den Kontext.

Bessere Eingabe bedeutet nicht längere Eingabe, sondern bewertbare Eingabe. „Auth-Code refactored“ ist schwach. „Refactored auth/session.ts to remove duplicated token parsing; ran npm test -- auth; did not test OAuth callback manually“ gibt dem Skill eine reale Grundlage für die Bewertung.

Achten Sie auf typische Fehlermuster bei self-eval

Der häufigste Fehler besteht darin, dass das Modell Aufwand statt Ergebnis belohnt. Ein weiterer ist, eine schwierige Aufgabe mit nur teilweiser Umsetzung automatisch als stark zu bewerten. self-eval ist darauf ausgelegt, dem entgegenzuwirken – aber nur, wenn der Nutzer den ursprünglichen Anspruch und das tatsächliche Ergebnis mitliefert.

Achten Sie außerdem auf Rauschen in der Score-Historie. Wenn .self-eval-scores.jsonl sehr unterschiedliche Aufgabentypen mischt, können Cluster-Signale weniger aussagekräftig sein. Eine kleine Dokumentationspolitur und eine komplexe Migration sollten nicht als gleichwertig interpretiert werden, nur weil sie dieselbe numerische Punktzahl haben.

Vom Score zur konkreten Aktion iterieren

Hören Sie nicht bei der finalen Punktzahl auf. Der nützliche Teil der Ausgabe ist die Lücke zwischen Anspruch und Ausführung. Machen Sie daraus einen Reparatur-Prompt:

Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.

So bleibt die nächste Iteration fokussiert. Außerdem verhindert es, dass der Agent die Arbeit durch sachfremde Zusatzfeatures „verbessert“, nur um eine höhere Bewertung zu erreichen.

self-eval vorsichtig anpassen

Wenn Sie den self-eval skill anpassen, bewahren Sie die Bestandteile, die für Kalibrierung sorgen: getrennte Achsen, Devil’s-Advocate-Argumentation, feste Score-Zuordnung und Bewusstsein für die Score-Historie. Labels, Ausgabeformat oder teamspezifische Akzeptanzkriterien anzupassen, ist in der Regel unproblematisch. Entfernen Sie jedoch die Vorgaben, die das Modell dazu bringen, gegen die eigene Einschätzung zu argumentieren, verhält sich der Skill wieder eher wie ein gewöhnlicher Review-Prompt.