UiPath/check-skill

Skill-Aktivierungsüberprüfung

Eine Skill verdient ihren Platz nur, wenn das Modell im richtigen Moment danach greift. Diese Entscheidung wird fast ausschließlich aus der description im Frontmatter der Skill getroffen – also ist „Löst meine Skill aus?“ eine messbare Frage, und so wird sie gemessen: Erstellen Sie einen beschrifteten Satz von Benutzeranfragen, führen Sie einen echten Agenten gegen jede aus und bewerten Sie, ob die Skill aktiviert wurde.

Die Anfrage des Benutzers lautet: $ARGUMENTS

Schritt 1 — Die Ziel-Skill lokalisieren

$ARGUMENTS kann ein Pfad zu einer SKILL.md, ein Pfad zum Verzeichnis der Skill, ein Skill-Name oder leer sein.

• Leer: glob über .claude/skills/*/SKILL.md und **/skills/*/SKILL.md. Eine Übereinstimmung → verwenden. Mehrere → auflisten und fragen, welche. Keine → melden und stoppen.
• Ein Verzeichnis: die SKILL.md darin verwenden.
• Ein Name: das passende Skill-Verzeichnis finden.

Der reine Skill-Name ist der Verzeichnisname, der SKILL.md enthält. Lesen Sie die Frontmatter-description und behalten Sie sie im Blick: Diese Zeichenkette ist das, was das Modell abgleicht, also ist sie die primäre Eingabe für das Design der Testzeilen und das, was Sie am Ende bearbeiten werden.

Messen Sie ihre Länge, während Sie dort sind – zwei separate Budgets kürzen sie, und jedes erzeugt ein Ergebnis mit geringer Trefferquote, das genau wie schlechte Formulierung aussieht.

1. Pro-Skill-Kürzung. description und when_to_use werden konkateniert und bei einem festen Zeichenbudget abgeschnitten – 1.536 Zeichen, konfigurierbar über die Einstellung skillListingMaxDescChars. Triggertext jenseits des Cutoffs kann die Aktivierung nicht beeinflussen, existiert also praktisch nicht.
2. Das Gesamtlisting-Budget, das in genau den Repositories am meisten zählt, die Aktivierungssuiten ausführen. Das Listing enthält immer jeden Skill-Namen, aber sein Gesamtzeichenbudget skaliert mit etwa 1% des Kontextfensters des Modells, geteilt durch jeden Skill, den der Benutzer installiert hat. Bei Überlauf verwirft Claude Code Beschreibungen, beginnend mit den Skills, die Sie am seltensten aufrufen.

Die zweite hat eine Konsequenz, die klar ausgesprochen werden sollte: In einem Repository mit vielen Skills kann eine Skill nahezu Null-Recall mit einer perfekt guten Beschreibung erzielen, weil ihre Beschreibung nie im Listing war. Das Umschreiben der Formulierung behebt dann nichts. Und die Fallreihenfolge ist zuerst die selten aufgerufenen – also ist eine neu erstellte Skill, die definitionsgemäß selten aufgerufen wird und genau das ist, wofür jemand diese Suite ausführt, das wahrscheinlichste Opfer. Das ist eine systematische Verzerrung gegen die getestete Skill.

Hebel, wenn das Listing das Problem ist: skillListingBudgetFraction (der 1%-Standard), die Umgebungsvariable SLASH_COMMAND_TOOL_CHAR_BUDGET (eine feste Zeichenanzahl) und skillOverrides auf "name-only" setzen, um Budget von Skills freizugeben, die Sie nicht abgleichen müssen.

Wenn die Skill keine description im Frontmatter hat, stoppen und dies als Ergebnis melden – eine Skill ohne Beschreibung kann nie modell-invokiert werden, also würde eine Suite konstruktionsbedingt Null-Recall erzielen und Ihnen nichts sagen, was Sie nicht bereits wissen.

Schritt 2 — Bestätigen, dass coder-eval installiert ist

Führen Sie coder-eval --version aus. Die Installation dieses Plugins hat die CLI nicht installiert, und die Suite kann ohne es nicht validiert oder ausgeführt werden.

Wenn es fehlt, folgen Sie ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md: Angebot zur Installation, vor dem Ausführen nachfragen und mit coder-eval --version danach bestätigen. Niemals unaufgefordert installieren und nicht fortfahren, wenn der Benutzer ablehnt.

Diese Referenz deckt auch die andere Hälfte des Versionschecks ab – ob dieses Projekt eine coder-eval-Version festlegt und was zu tun ist, wenn die installierte nicht dazu passt.

Schritt 3 — Prüfen, was diese Skill bereits abdeckt

Bevor Sie etwas entwerfen, prüfen Sie, was das Repository bereits hat. Lokalisieren Sie den Aufgabenbaum gemäß ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md und globen Sie ihn nach einer Aufgabe, die ein skill_triggered-Kriterium trägt.

Wenn eine existierende Suite diese Skill bereits benennt, melden Sie ihre Abdeckung – wie viele positive und ablenkende Zeilen, welche suite_thresholds sie bewacht – und bieten Sie an, sie zu erweitern, indem Sie Zeilen an ihren Datensatz anhängen, anstatt eine parallele Suite zu erstellen. Zwei Suiten für eine Skill driften auseinander, und der Benutzer bezahlt für beide bei jedem Lauf. Nur erstellen, wenn nichts diese Skill abdeckt oder wenn der Benutzer sich nach dem Anzeigen des Bestehenden dafür entscheidet.

Zwei Dinge, die es wert sind, gemeldet zu werden, anstatt stillschweigend zu umgehen:

• Eine existierende Suite ohne ablenkende Zeilen. Precision ist definitionsgemäß 1,0, also ist die Hälfte des Ergebnisses bedeutungslos. Bieten Sie an, Ablenkungen hinzuzufügen – eine echte Verbesserung sowohl gegenüber dem Erstellen einer Konkurrenzsuite als auch gegenüber dem Schweigen.
• Eine benachbarte Suite, die einen anderen Skill benennt. Das ist keine Abdeckung. Fahren Sie mit der Erstellung fort und sagen Sie, warum der Nachbar nicht zählt.

Prüfen Sie dann, woher agent.plugins kommen soll. Wenn ein Experiment, gegen das die Aufgabe aufgelöst wird, diesen Block bereits bereitstellt, übernehmen Sie ihn und schreiben Sie keinen – eine Aufgabe, die neu deklariert, was das Experiment bereitstellt, driftet davon ab, ohne dass die Abweichung abgefangen wird. Schreiben Sie den eigenen Block der Vorlage nur, wenn nichts die Skill bereits für die Sandbox bereitstellt. Wenn mehrere Experimente existieren und unklar ist, gegen welches diese Aufgabe aufgelöst wird, fragen Sie statt zu raten.

Schritt 4 — Die Zeilen entwerfen

Dieser Schritt ist das gesamte Experiment. Der Rest ist Mechanik.

Positive Zeilen – Anfragen, die ein echter Benutzer plausibel stellen würde und die die Beschreibung zu decken beansprucht. Paraphrasieren; niemals Formulierungen aus der Beschreibung kopieren. Eine aus der Beschreibung übernommene Zeile testet Zeichenkettenabgleich, nicht Aktivierung. Variieren Sie den Wortschatz und fügen Sie mindestens eine indirekte Zeile hinzu, in der der Benutzer sein Problem beschreibt, nicht die Operation, die die Skill ausführt.

Ablenkungszeilen – angrenzende Anfragen, die die Skill nicht übernehmen sollte, insbesondere solche, die Vokabular mit der Beschreibung teilen. Diese machen Precision aussagekräftig.

Geschwister-eigene Zeilen (optional) – Anfragen, die legitimerweise zu einem benannten anderen Skill im selben Repository gehören, mit expected_skill gesetzt auf dieses Geschwister. In einem Repository mit mehreren Skills ist die Fehlleitung zwischen zwei benachbarten Skills der häufige Fehler, und eine einfache Ablenkung zeigt nur, dass ein Fehlschuss geschah, nicht wohin er ging. Diese Zeilen geben das an.

Fügen Sie sie hinzu, wenn zwei Skills überlappende Themen haben und Sie wissen möchten, welcher gewinnt. Sie kosten zusätzliche Zeilen, und jede Zeile ist ein voller Agentenlauf – behandeln Sie sie also als gezielte Nachverfolgung, nicht als Standard.

Niemals den Skill-Namen in einer Eingabeaufforderung nennen. Das testet Gehorsam, nicht Aktivierung:

• Schlecht: "Verwenden Sie die pdf-forms-Skill, um dieses Antragsformular auszufüllen."
• Gut: "Ich muss die Felder auf diesem Antrags-PDF ausfüllen und zurücksenden."

Diese Regel wird von geschwister-eigenen Zeilen nicht beeinflusst: expected_skill ist ein Label im Datensatz, das vom Kriterium gelesen und dem Agenten nie gezeigt wird. Die prompt der Zeile darf dennoch keinen Skill-Namen enthalten, auch nicht den des Geschwisters.

Größenbestimmung. Mindestens 3 positive + 3 Ablenkungen. Zielen Sie auf 8–12 von jeder für ein Signal, auf das Sie reagieren können – Recall über 3 Zeilen bewegt sich in 33-Punkte-Sprüngen, was zu grob ist, um einen echten Rückschritt von Rauschen zu unterscheiden. Die mitgelieferte Vorlage hat 6 Zeilen, weil dies das illustrative Minimum ist, kein Ziel. Geschwister-eigene Zeilen kommen obendrauf: 8–12 Positive plus 8–12 Ablenkungen sind bereits 16–24 Läufe, also geben Sie die resultierende Summe an, bevor Sie die Suite schreiben.

Weigern Sie sich, eine Suite ohne ablenkende Zeilen zu generieren. Ohne Negative ist Precision definitionsgemäß 1,0 und die Hälfte des Ergebnisses bedeutungslos. Sagen Sie warum und fragen Sie stattdessen nach den angrenzenden Fällen.

Schritt 5 — Die Suite schreiben

Kopieren Sie die beiden Vorlagendateien in den Aufgabenbaum des Benutzers, der durch Befolgung von ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md gefunden wurde (wenn das Repository keins hat, schlagen Sie einen Ort vor und fragen Sie):

• ${CLAUDE_PLUGIN_ROOT}/reference/templates/activation.yaml
• ${CLAUDE_PLUGIN_ROOT}/reference/templates/activation-rows.jsonl

Ersetzen Sie dann, wobei die JSONL neben der YAML bleibt (dataset.paths-Einträge werden relativ zur Aufgabendatei aufgelöst):

• task_id → <skill-name>-activation
• skill_name → den reinen Skill-Namen
• expected_skill jeder positiven Zeile → denselben reinen Namen; Ablenkungszeilen behalten ""; expected_skill einer geschwister-eigenen Zeile → den reinen Namen des Geschwisters
• prompt jeder Zeile → die in Schritt 4 entworfenen Anfragen, ein JSON-Objekt pro Zeile

Machen Sie die Skill dann erreichbar, was der Schritt ist, der entscheidet, ob die Suite überhaupt etwas misst. Die Aufgabe läuft in einer frischen Sandbox, die keine Dateien des Benutzers enthält, also werden dem Agenten keine Skills angeboten, es sei denn, die Aufgabe sagt, wo sie leben. Das ist der agent.plugins-Block in der Vorlage – und es ist nur die Aufgabe der Vorlage, wenn nichts die Skill bereits bereitstellt: Wenn Schritt 3 ein Experiment gefunden hat, das diesen Block bereitstellt, übernehmen Sie ihn und löschen Sie die Kopie der Vorlage, anstatt eine zweite Deklaration zu schreiben.

Ansonsten füllen Sie ihn aus. path muss ein Plugin-Root sein: ein Verzeichnis, das ein skills/-Unterverzeichnis enthält, sodass die Skill unter <path>/skills/<skill-name>/SKILL.md liegt. Eine .claude-plugin/plugin.json ist optional – ohne sie ist der Namespace standardmäßig der Name des Verzeichnisses selbst.

Für .claude/skills/pdf-forms/SKILL.md ist dieser Root .claude, nicht .claude/skills. Auf ein bloßes Verzeichnis von Skill-Verzeichnissen zu zeigen, lädt gar nichts.

Erstellen Sie einen minimalen Root, anstatt auf .claude selbst zu zeigen. Ein Plugin-Root lädt das GESAMTE Plugin, nicht nur seine Skills: Ein agents/, commands/ oder hooks/-Verzeichnis neben skills/ wird für den evaluierten Agenten ebenfalls sichtbar. Auf das .claude eines Repos zu zeigen, gibt dem Agenten jeden Projekt-Subagenten und Befehl – und ein Subagent, der die Anfrage beantworten kann, ist ein Störfaktor, kein Detail. Wenn .claude/agents/pdf-expert.md existiert, während Sie pdf-forms messen, kann der Agent an ihn delegieren, anstatt die Skill zu rufen; skill_triggered zeichnet no auf, und der Recall sinkt aus einem Grund, der nichts mit der Beschreibung der Skill zu tun hat. Es macht die Zahl auch repository-abhängig, sodass zwei Suiten nicht mehr vergleichbar sind.

Bauen Sie also einen Root, der genau die zu testende Einheit enthält, und zeigen Sie darauf:

SKILL_ROOT="$(mktemp -d)"
mkdir -p "$SKILL_ROOT/skills"
ln -s "$(pwd)/.claude/skills/pdf-forms" "$SKILL_ROOT/skills/pdf-forms"
export SKILL_SOURCE_PATH="$SKILL_ROOT"

Verwenden Sie cp -R anstelle von ln -s, wo Symlinks umständlich sind (Windows, einige CI-Images). Wenn der Benutzer die Einzeiler bevorzugt, funktioniert export SKILL_SOURCE_PATH="$(pwd)/.claude" immer noch – sagen Sie klar, dass es auch alles andere unter .claude freigibt, also ein niedriger Recall eher den Geschwistern als der Skill zugeschrieben werden kann.

Behalten Sie es als Umgebungsvariable, anstatt einen absoluten Pfad in die YAML einzubacken – die Suite wird committed und auf anderen Maschinen erneut ausgeführt. Wenn die Variable nicht gesetzt ist, fehlt die Skill einfach, jede positive Zeile bekommt 0 Punkte, und das Ergebnis ist nicht von einer Skill zu unterscheiden, die nie auslöst. Bestätigen Sie also, dass sie gesetzt ist, bevor Sie ein Ergebnis mit niedrigem Recall melden.

skill_name muss der reine Name sein, selbst wenn die Skill von einem Plugin kommt und als plugin:skill aufgerufen wird – der Prüfer entfernt den Namespace vor dem Vergleich. Ein namespaced-Wert hier erzielt stillschweigend Null-Recall auf jeder Zeile, was genau wie eine defekte Skill aussieht.

Da der Abgleich nach reinem Namen erfolgt, kann er einer Namenskollision nicht standhalten. Zwei Skills namens init – eine von einem Plugin, eine integriert – sind für das Kriterium dieselbe Zeichenkette, also wird es demjenigen gutschreiben, der feuert, als ob es die getestete wäre. Überprüfen Sie, ob der Name über alles Installierte hinweg eindeutig ist, bevor Sie einem Ergebnis vertrauen (/context und /doctor listen den aktiven Satz auf). Eine Kollision erzeugt keinen Fehler; sie misst die falsche Skill. Wenn eine existiert, sagen Sie es, anstatt die Zahl zu melden – das Umbenennen der Skill oder das Messen, wo die Kollision nicht existiert, sind die einzigen ehrlichen Lösungen.

Für Kriterienfelder über diese Vorlage hinaus lesen Sie ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md.

Schritt 6 — Validieren, bevor Sie etwas ausgeben

coder-eval plan <path-to-activation.yaml> muss mit Exit-Code 0 beendet werden. Es ist nur ein Schema-Check – es liest die Datensatzdatei nicht – also bestätigen Sie auch, dass die JSONL neben der YAML liegt und ein Objekt pro Zeile enthält.

Schritt 7 — Ausführen

Jede Zeile ist ein voller Agentenlauf: N Zeilen bedeuten N Läufe und echte Token-Kosten. Geben Sie die Zeilenanzahl und den Agenten/das Modell an, der/das verwendet wird, und fragen Sie dann, bevor Sie beginnen.

coder-eval run <path-to-activation.yaml>

Das Kriterium ist agentenagnostisch – es erkennt Claude, der die Skill über das Skill-Tool einschaltet, und jeden Agenten ohne dieses Tool (z.B. Codex), indem es die Dateien der Skill von der Festplatte liest – also funktioniert dieselbe Suite unabhängig davon, gegen welchen Agenten die Aufgabe aufgelöst wird.

Schritt 8 — Berichten und interpretieren

Präsentieren Sie Recall, Precision, F1 und die Konfusionsmatrix, dann sagen Sie, was sie bedeuten:

• Niedriger Recall (verpasst Zeilen, die es hätte fangen sollen): Kürzung und Listing-Verwerfung ausschließen, bevor Sie auf eine zu wenig beanspruchende Beschreibung schließen. Beide erzeugen ein Ergebnis mit niedrigem Recall, das nicht von schlechter Formulierung zu unterscheiden ist, und beide sind billig zu überprüfen: /doctor schätzt die Kontextkosten des Listings und seine größten Beitragenden, und die Skills-Zeile in /context meldet die Listing-Größe nachdem das Budget angewendet wurde – das ist das, was das Modell tatsächlich erhalten hat. Erst wenn die Beschreibung nachweislich im Listing und innerhalb des Pro-Skill-Cutoffs liegt, ist die Formulierung der Schuldige: Sie benennt nicht die Situationen, Dateitypen oder Formulierungen, die sie auslösen sollten.
• Niedrige Precision (feuert auf Ablenkungen): Die Beschreibung beansprucht zu viel und stiehlt benachbarte Anfragen. Engen Sie sie ein, und sagen Sie explizit, wofür die Skill nicht ist.
• Fehlschüsse konzentriert auf ein Geschwister (mit geschwister-eigenen Zeilen): Das ist ein Abgrenzungskonflikt zwischen zwei Beschreibungen, nicht eine vage Beschreibung. Allein die getestete Skill zu beheben, tendiert dazu, den Fehler zu verschieben, anstatt ihn zu beseitigen – sagen Sie explizit, wofür jede der beiden Skills nicht ist, und führen Sie erneut aus.
• Beide hoch: Melden Sie die Zahlen und die Zeilenanzahl, und weisen Sie darauf hin, dass eine kleine Suite wenig aussagt – bieten Sie an, sie zu erweitern.

Zeigen Sie auf die Frontmatter-description als das zu bearbeitende Element, zitieren Sie die spezifischen Zeilen, die...

… [für die Übersetzung gekürzt]