Skill Doctor
Diagnostizieren und verbessern Sie jede SKILL.md. Ein Kompass, kein Handbuch – die konkreten Standards liegen in references/, lesen Sie sie bei Bedarf.
Diagnoseablauf nach dem Auslösen (jeder Schritt muss sichtbare Ausgabe erzeugen)
Ein Schritt ohne sichtbare Ausgabe wird still übersprungen (Seleznov-Experiment, 2026). Drucken Sie eine Bestätigungszeile pro Schritt. Selbstprüfungs-Flag: Wenn diese Sitzung die Ziel-SKILL.md bereits bearbeitet/geschrieben hat, stellen Sie jeder Diagnosezeile
[self-review]voran und fügen Sie am Ende von Schritt 3 eine Zeile hinzu: "Schlussfolgerung ist selbst bewertet, empfehle erneute Überprüfung mit einem frischen Unteragenten."
Schritt 1: Lesen Sie die Ziel-SKILL.md und kündigen Sie den Diagnosebeginn an
Lesen Sie den vollständigen Text der zu bearbeitenden SKILL.md, führen Sie python3 <this-skill-dir>/scripts/check_listing_budget.py "<project_root>" aus (den Pfad in Anführungszeichen setzen – Leerzeichen sind üblich), und drucken Sie zwei Zeilen:
[skill-doctor] Prüfung: <path> body=<N> Zeilen description=<M> Zeichen
[skill-doctor] Budget (<platform>): <K> Skills, <T> Zeichen vs ≈<B> → <fits | OVERFLOW ×N.N>
Erkennt automatisch die Plattform (CC / Codex / Hermes / OpenClaw). Exit: 0 = passt; 1 = Überlauf; 2 = nicht verfügbar (keine Plattform / Kontext unbekannt → fragen Sie den Benutzer nach Plattform + Fenster). Überlauf ist ein populationsweiter HINWEIS, kein Befund gegen den geprüften Skill: drucken Sie die Zahlen, damit der Benutzer Bescheid weiß, aber kürzen Sie NICHT die Beschreibung dieses Skills aus Budgetgründen – Verschlankung ist ein globaler Durchlauf, niemals eine Einzel-Skill-Korrektur.
Schritt 2: Bewertung anhand der Dimensionen
Wählen Sie die zu ladenden Dimensionen aus dem Referenzindex (Dimensionen-Abschnitt) – lesen Sie nur die Einträge, deren wann-zu-lesen-Bedingung zutrifft. Nach dem Laden drucken Sie eine Zeile:
[skill-doctor] Geladen: <list>; Übersprungen: <list mit einwortigem Grund>
Schritt 2.5: Trockentest-Walkthrough (nur wenn der Textkörper einen Workflow enthält)
Befolgen Sie references/effect-dry-run.md, nehmen Sie den 1 typischsten Prompt und führen Sie ihn durch die Textkörperschritte, wobei Sie prüfen, ob Eingabe/Anweisung/Ausgabe verbunden sind.
Jede unterbrochene Verbindung oder Mehrdeutigkeit → markieren Sie P0 (Effektproblem) und setzen Sie es in den ❌-Abschnitt von Schritt 3.
Drucken Sie eine Zeile:
[skill-doctor] Trockentest-Prompt: "<prompt>" broken links=<N>
Wenn der Textkörper keinen Workflow hat (reiner Regel-/Referenztyp-Skill), drucken Sie:
[skill-doctor] Trockentest: übersprungen (kein Workflow)
Schritt 2.6: Live-Injection-Prüfung (nur wenn der Ziel-Skill im Gültigkeitsbereich der aktuellen Sitzung liegt)
Prüfen Sie, ob der Ziel-Skill in der Liste der verfügbaren Skills dieser Sitzung mit seiner Beschreibung (nur mit Namen) erscheint. Die 3 Fälle (injiziert / namensbasierter Budget-Drop / außerhalb des Gültigkeitsbereichs übersprungen) und die Populationshinweis-Regel finden Sie in references/live-injection-check.md. Drucken Sie eine Zeile:
[skill-doctor] Live-Injection: <injected | DROPPED (nur-Name) | skipped (<grund>)>
Schritt 3: Ausgabe des Diagnoseberichts
Formatieren Sie streng wie folgt, drucken Sie in die Konversation:
[skill-doctor] Diagnose
❌ Muss behoben werden (sortiert P0→P3, Definitionen in references/priority-tiers.md)
[P0 effect break] <problem>: <warum> → <lösung>
[P1 structure] <problem>: <warum> → <lösung>
[P2 specificity] <problem>: <warum> → <lösung>
[P3 affects execution] <problem>: <warum> → <lösung>
⚠️ Verbesserungsvorschläge (einschließlich rein kosmetischer / ausführlicher P3)
- <problem>: <warum> → <lösung>
✅ Bestandene Prüfungen
- <liste>
P3-Platzierungsregel: Fragen Sie: "Wenn nicht behoben, wird die nächste LLM, die diesen Skill ausführt, etwas falsch machen?" – ja → ❌; lediglich hässlich/ausführlich → ⚠️. Siehe references/priority-tiers.md.
Jedes Problem muss eine spezifische Zeilennummer oder ein Feld angeben – keine Ungenauigkeiten. Wenn dieselbe Art von Verstoß an mehreren Stellen auftritt, listen Sie sie separat auf – z. B. falsch kategorisierte Inhalte in drei Unterverzeichnissen sollten 3 Probleme sein, nicht 1 zusammengeführter Eintrag.
Nennen Sie den Fehlermodus, wenn einer zutrifft (siehe references/predictability-glossary.md): stellen Sie dem Befund [no-op] / [sediment] / [premature-completion] / [weak-leading-word] / [duplication] / [sprawl] voran. Der Name sagt welche Art; die P-Stufe sagt immer noch wie schlimm – orthogonal, daher ersetzt das Präfix niemals die Stufe.
Schritt 4: Anwenden mit Bearbeiten nach Benutzerbestätigung
Niemals ohne Bestätigung bearbeiten. Warten Sie, bis der Benutzer "behebe es" sagt, bevor Sie handeln.
Wenden Sie vor dem Handeln die Größenbegrenzung und die Vor-Löschungs-Prüfung an; schließen Sie danach den Kreislauf – das vollständige Verfahren finden Sie in references/apply-safety.md.
Drucken Sie nach der Korrektur eine Zeile:
[skill-doctor] <N> Korrekturen an <path> angewandt body: <alt>→<neu> Zeilen (<+X%>)
Kurzreferenz der harten Regeln
Die quantifizierten harten Regeln (ein Verstoß ist ein Fehler, kein Vorschlag) befinden sich in references/hard-rules.md – konsultieren Sie sie bei jeder Prüfung.
Ausnahme-Fallback
Wenn ein Pfad fehlt, YAML nicht geparst werden kann oder ein gebündeltes Skript (scripts/check_listing_budget.py + scripts/detect_platform.py / scripts/check_routes.py / scripts/eval_retrieval.py / scripts/check_desc_slim.py) fehlt oder mit Exit 2 endet – handhaben Sie es gemäß references/exception-fallback.md. Geben Sie die Ausnahme zuerst dem Benutzer bekannt; niemals still überspringen.
Ausgabe und Sprache
Der Berichtstext folgt references/output-style.md (klar, terminalsicher, Schlussfolgerung zuerst). Textkörper/Referenzen standardmäßig auf Englisch; kennzeichnen Sie ungerechtfertigte Nicht-Englisch-Sprache mit ⚠️ – Richtlinie + die zwei gerechtfertigten Ausnahmen in references/language-policy.md.
Aufgaben außerhalb des Gültigkeitsbereichs dieses Skills
- Ob die tatsächliche Funktionalität korrekt ist (das ist ein Logikfehler, kein Skill-Form-Problem)
- Projektspezifische Konventionen (die gehören in CLAUDE.md, nicht in einen Skill)
- Einmalige Korrekturskripte (werden nach einmaligem Ausführen verworfen, sollten kein Skill sein)
Warum dieser Skill existiert
Warum LLMs SKILL.md fälschlicherweise als Handbuch schreiben und wie dieser Skill mechanische Prüfungen von Beurteilungen trennt: references/rationale.md.