UiPath/init

Richte coder-eval in diesem Repository ein

Ziel: Dem Benutzer ein Aufgabenverzeichnis mit einer echten Aufgabe hinterlassen, die er sofort ausführen kann, kein leeres Grundgerüst. Die Aufgabe muss etwas testen, das dieses Repository tatsächlich ausliefert.

Die Anfrage des Benutzers lautet: $ARGUMENTS

Schritt 1 – Voraussetzungen prüfen

Führe coder-eval --version aus. Die Installation dieses Plugins installiert nicht das CLI, und jeder spätere Schritt benötigt es.

Wenn es fehlt, folge ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md: Biete die Installation an, frage vor der Ausführung, und bestätige anschließend mit coder-eval --version. Installiere niemals unaufgefordert und fahre nicht fort, wenn der Benutzer ablehnt.

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

Schritt 2 – Prüfen, ob dieses Repository bereits konfiguriert ist

Dieses Skill erstellt eine erste Suite. Wenn es gegen ein Repository ausgeführt wird, das bereits eine Suite hat, würde es eine „erste Aufgabe“ neben einem bestehenden Baum schreiben und Erfolg melden – finde also heraus, ob eine Konfiguration existiert, bevor du etwas schreibst.

Finde den Evaluierungsbaum gemäß ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md. Wenn das Repository bereits Aufgaben hat, melde den Bestand und stoppe: Wie viele Aufgabendateien und wo, wie viele Ausführungsverzeichnisse und ob es Experimente gibt. Weise den Benutzer dann auf die Skills hin, die auf dem Bestehenden aufbauen:

• /coder-eval:lint-tasks zur Überprüfung der vorhandenen Aufgaben;
• /coder-eval:analyze zum Lesen eines abgeschlossenen Durchlaufs.

Erstelle nur dann ein Grundgerüst, wenn das Repository keine Aufgaben hat oder der Benutzer nach Ansicht des Bestands explizit nach weiteren fragt. Überschreibe niemals eine vorhandene Aufgabendatei, egal, worum er bittet; füge sie daneben ein.

Ein Repository mit Aufgaben, aber ohne Experimente ist teilweise konfiguriert, nicht leer. Melde dies als solches und biete das fehlende Element an – erstelle keine erste Aufgabe, als ob nichts vorhanden wäre.

Schritt 3 – Nach testbaren Inhalten scannen

Suche in dieser Prioritätsreihenfolge und melde, was du gefunden hast, bevor du etwas schreibst:

1. Claude Code Skills – glob .claude/skills/*/SKILL.md und **/skills/*/SKILL.md. Skills sind das Wertvollste, was man evaluieren kann, da ihre Aktivierung unsichtbar bleibt, bis sie fehlschlägt. Wenn du welche findest, empfehle /coder-eval:check-skill für jedes davon – das ist eine speziell dafür entwickelte Aktivierungssuite, die hier nicht selbst gebaut werden sollte.
2. Ein MCP-Server – eine .mcp.json, ein mcpServers-Schlüssel in package.json oder pyproject.toml oder ein Server-Einstiegspunkt (eine server.py / index.ts, die Tools registriert). Notiere, welche Tools er bereitstellt.
3. Ein CLI-Einstiegspunkt – [project.scripts] in pyproject.toml, bin oder scripts in package.json oder ein Makefile mit nutzbaren Zielen.

Wenn das Repository ein Monorepo mit vielen Skill- oder Paketverzeichnissen ist, begrenze den Scan und frage, auf welchen Unterbaum du dich konzentrieren sollst, anstatt fünfzig Kandidaten zu melden.

Wenn du nichts in diesen drei Kategorien findest, sage dies deutlich. Biete dann stattdessen die kleinste nützliche Sache an – eine Aufgabe, die ein Skript oder einen Testbefehl ausführt, den das Repo bereits hat, und dessen Ausgabe überprüft – anstatt eine leere Suite zu erstellen, die nichts beweist.

Schritt 4 – Eine echte Aufgabe erstellen

Schreibe in den in Schritt 2 ermittelten Baum. Wenn das Repository keinen hat, schlage einen Speicherort vor und frage nach. Die „Niemals-Überschreiben“-Regel aus Schritt 2 gilt hier immer noch – sie ist der einzige Ort, an dem diese Regel lebt.

Schreibe eine Aufgabe, die aus dem abgeleitet ist, was Schritt 3 gefunden hat:

• Ein CLI – eine Aufgabe, deren Aufforderung nach etwas fragt, das das CLI tut, mit Kriterien, die den Inhalt der resultierenden Datei überprüfen, nicht nur, dass eine Datei erschienen ist.
• Ein MCP-Server – eine Aufgabe, die ein bestimmtes Tool ausführt und seine Wirkung verifiziert.
• Skills – verweise stattdessen auf /coder-eval:check-skill; eine Aktivierungssuite hat eine andere Form als eine Fähigkeitsaufgabe, und dieses Skill baut sie korrekt auf.

Aufforderungen instruieren, Kriterien validieren. Wiederhole in der Aufforderung nicht, was die Kriterien prüfen – eine Aufforderung, die sagt „stelle sicher, dass die Datei X enthält“, testet Leseverständnis, nicht Fähigkeit.

Bevor du die Kriterien schreibst, lies ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md. Es ist die gemeinsame Checkliste dafür, ob eine Aufgabe aus dem falschen Grund bestehen kann, und die eine Aufgabe, die du hier erstellst, ist das Vorbild für jede spätere Aufgabe in diesem Repository – daher lohnt es sich, sie richtig zu machen, anstatt sie später zu reparieren. Für Kriterientypen und ihre Felder lies ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md.

Verwende /coder-eval:task, wenn der Benutzer nach dieser Aufgabe weitere wünscht; es ist die gleiche Erstellungsschleife mit einer natürlichsprachlichen Kurzbeschreibung.

Schritt 5 – Umgebungsvariablen

Schreibe die Variablen, die der gewählte Agent benötigt (z. B. ANTHROPIC_API_KEY für den Standard-claude-code-Agenten) in .env.example – erstelle sie oder hänge sie an.

Schreibe niemals .env: Es kann bereits echte Geheimnisse enthalten. Wenn .env nicht existiert, prüfe, ob es in .gitignore aufgeführt ist, bevor du dem Benutzer vorschlägst, eines zu erstellen, und sage Bescheid, wenn dies nicht der Fall ist.

Schritt 6 – Validieren

Führe coder-eval plan <task-verzeichnis>/*.yaml aus und iteriere, bis der Exit-Code 0 ist. Dies validiert das Aufgabenschema durch die echten Modelle, sodass ein falsch geratener Feldname hier sichtbar wird. plan akzeptiert Aufgaben-Dateien: Ein bloßes Verzeichnisargument wird direkt abgelehnt (Expected a YAML task file but got a directory), gib also immer explizite Pfade oder einen Glob an. Schlage coder-eval plan ohne Argument nicht vor – die Argument-lose Erkennung funktioniert nur aus einem coder-eval-Quellcode-Checkout und endet überall sonst mit Exit-Code 1.

Ein leeres oder aufgabenloses Verzeichnis ergibt keinen sinnvollen Erfolg – wenn plan keine Aufgaben meldet, behandle dies als Fehler beim Erstellen, nicht als Bestehen. Beachte, dass der Fehler „Bare-Directory“ ein anderes Ergebnis ist: Er bedeutet, dass du die falsche Argumentform übergeben hast, nicht, dass das Gerüst leer ist.

Schritt 7 – Melden

Teile dem Benutzer mit:

• was du beim Scan gefunden hast und was du zuerst evaluieren möchtest;
• den genauen Befehl, um es auszuführen: coder-eval run <pfad>, plus den Hinweis, dass es echte Token kostet und die Anmeldeinformationen aus Schritt 5 benötigt;
• dass /coder-eval:check-skill der nächste Schritt ist, wenn das Repo Skills ausliefert;
• dass /coder-eval:analyze anschließend das Ausführungsverzeichnis liest und /coder-eval:ci die Suite in ein GitHub-Actions-Gate verwandelt.