Route
Argumente: $ARGUMENTS
<base> unten bezeichnet den „Basisordner für diesen Skill“, der oberhalb dieses Textes angezeigt wird. Das Skript ist
<base>/scripts/inventory.py. Der persönliche Katalog befindet sich in ~/.claude/route-catalog/ (oder in
$ROUTE_CATALOG_DIR), niemals innerhalb des Plugins.
0. Finde die Anfrage
Der Benutzer schreibt eine normale Eingabeaufforderung und fügt /route hinzu. Ermittle die Anfrage aus seinen eigenen Worten:
/routebefindet sich in derselben Nachricht wie die Eingabeaufforderung (davor oder danach): Die Anfrage ist die gesamte Nachricht ohne das Wort/route./routewurde allein gesendet: Die Anfrage ist die vorherige Nachricht des Benutzers (oder Nachrichten, sofern sie zur selben Aufgabe gehören), gelesen im Zusammenhang mit dem Gespräch. Behandle das bloße Wort „/route“ niemals als die Anfrage.- Die obigen Argumente enthalten Text: Behandle es als die Anfrage oder einen Teil davon, aber die eigene Nachricht des Benutzers hat Vorrang, wenn sie abweicht.
- Wenn du bereits mit der Anfrage begonnen hast, bevor
/routeeintraf, prüfe, was bereits erledigt ist, und leite nur die verbleibende Arbeit weiter. Führe keine bereits abgeschlossenen Schritte erneut aus. - Wenn die Anfrage
buildlautet, lies<base>/BUILD.mdund folge ihr. Wenn sierefreshlautet, springe zu Aktualisieren.
Behalte die Eingabeaufforderung des Benutzers als Aufgabe. Verkleinere sie nicht auf den Teil, den ein Skill abdeckt: Jeder Teil der Eingabeaufforderung muss von einem geladenen Skill oder durch deine eigene Arbeit abgedeckt werden.
1. Verstehe die Anfrage
Schreibe eine Zeile für dich selbst: das Ziel, das Ergebnis, die beteiligte Technik oder Dateien und die Phase (Plan, Bauen, Debuggen, Überprüfen, Verifizieren, Ausliefern, Dokumentation, Medien, Betrieb). Nutze das Gespräch: Eine Anfrage wie „behebe es“ oder „erstelle das Video“ bezieht sich auf das, was gerade besprochen wurde. Durchsuche die Codebasis noch nicht.
Vorzeitiger Ausstieg: Wenn die Anfrage trivial ist (eine Umbenennung, eine einzeilige Korrektur, eine einfache Frage), gib „Kein Skill nötig: “ aus und erledige die Aufgabe. Lies den Katalog nicht.
Wenn die CLAUDE.md des Projekts einen ersten Schritt vor jeglicher Arbeit erfordert (z. B. „durchsuche das Runbook nach dem Fehlertext, bevor du eine Diagnose stellst“), führe diesen Schritt jetzt aus. Sein Ergebnis kann ändern, welche Skills benötigt werden.
2. Finde Kandidaten
- Führe
python3 <base>/scripts/inventory.py --checkaus dem aktuellen Verzeichnis aus.NO CATALOG: Teile dem Benutzer mit, dass der Router einen einmaligen/route buildbenötigt, biete an, ihn jetzt auszuführen, und bearbeite währenddessen die Anfrage mit den Skills, die du in deiner eigenen Skill-Liste sehen kannst.- Andernfalls gibt es
catalog in syncaus, oder NEUE Skills (installiert, nicht im Katalog, mit ihrer Beschreibung) und ENTFERNTE Einträge (nicht mehr installiert). NEUE Skills sind gültige Kandidaten. Wähle niemals einen ENTFERNTEN aus.
- Wenn
--checkübergeordnete Regeln als vorhanden meldet, lies diese Datei zuerst. Sie enthält die eigenen Routing-Regeln des Benutzers (z. B. „UI-Polish → better-ui, niemals impeccable“). Eine Regel, die auf die Anfrage passt, überschreibt den Katalog, seine Standardauswahlen und dein eigenes Urteil. Erwähne die Regel in der Spalte „Warum“. - Im Katalogordner, den
--checkin der ersten Zeile ausgibt, liesINDEX.mdund, falls vorhanden,PROFILE.md(den Stack und die Gewohnheiten des Benutzers). - Wähle die 1 bis 3 Kategorien aus, die zur Anfrage passen, und lies nur diese Kategoriendateien.
Jede Skill-Zeile lautet:
- `name` [load] USE: ... | NOT: ... | NEXT: ... | NEEDS: ...
3. Wähle das Set aus
- Wähle das kleinste Set, das die gesamte Anfrage abdeckt: normalerweise 1 bis 3 Skills, niemals mehr als 5.
- Ein Skill pro Aufgabe. Lade niemals zwei Skills, die dieselbe Aufgabe erledigen; folge den „Standardauswahlen“ der Kategorie.
- Beachte das NOT-Feld jedes Skills. Wenn NOT einen besseren Skill für diese Anfrage nennt, nimm diesen.
- Für dieselbe Aufgabe bevorzuge einen Projektskill (
[project], aus dem.claude/skillsdieses Repos) oder einen benutzerdefinierten Skill des Benutzers gegenüber einem generischen Skill. - Wenn ein Skill NEEDS auflistet, die hier fehlen, sage dies und wähle den nächstbesten Skill.
- Wenn kein Skill echten Mehrwert bietet, sage „Kein Skill nötig“ und erledige die Aufgabe.
- Wenn zwei sehr unterschiedliche Interpretationen der Anfrage zu unterschiedlichen Skills führen, stelle eine kurze Frage mit den Optionen, bevor du etwas lädst.
4. Zeige den Plan, dann lade
Gib diese Tabelle als sichtbaren Text vor dem ersten Skill-Aufruf aus. Sie ist erforderliche Ausgabe, keine Erzählung: Gib sie auch dann aus, wenn ein knapper oder „kein Text vor Tool-Aufrufen“-Stil aktiv ist.
| # | Skill | Warum dieser | Laden |
|---|---|---|---|
| 1 | skill-name | eine Zeile, die auf die Anfrage bezogen ist | skill / read / builtin / project |
Eine Zeile kann bedingt sein: Schreibe „nur wenn “ in die Spalte „Warum“ und lade sie nur, wenn die Bedingung erfüllt ist.
Füge unter der Tabelle einen Hinweis „Nebenwirkung“ für jeden Schritt hinzu, der Nachrichten sendet, bereitstellt, Daten löscht, bezahlte Credits verbraucht oder in die Produktion schreibt, sei es durch einen Skill oder durch die Arbeit selbst. Frage vor diesem Schritt. Andernfalls fahre ohne Wartezeit fort.
Lade die Skills in der Tabellenreihenfolge (zuerst Plan, dann Bauen, dann Verifizieren):
[skill],[builtin],[project]: Rufe das Skill-Tool mit dem genauen Namen auf und übergib den Teil der Anfrage, den dieser Skill bearbeiten soll, alsargs.[read <path>]: Das Skill-Tool verweigert diesen Skill (nur für Benutzer). Lese die Datei unter<path>und folge ihr, als wäre sie geladen.- Wenn ein Skill-Aufruf fehlschlägt, lies stattdessen die
SKILL.mddes Skills (inventory.pyohne Flag gibt jeden Pfad aus) und sage dies.
5. Erledige die Arbeit
Befolge die geladenen Skills gemeinsam. Wenn zwei davon in Konflikt geraten, gewinnt der spezifischere für diesen Teil der Aufgabe. Die CLAUDE.md-Dateien des Benutzers und explizite Anweisungen haben Vorrang vor jedem Skill.
Wenn während der Arbeit ein neues Bedürfnis auftritt (z. B. die Korrektur benötigt eine Migration), lade einen weiteren Skill und kündige dies in einer Zeile an: „Lade auch x: “.
6. Überprüfe, protokolliere, berichte und schlage vor, was als Nächstes ausgeführt werden soll
Abschlussprüfung: Wenn zwei oder mehr Skills geladen wurden oder die Anfrage mehrere Teile hatte, überprüfe jeden Teil vor der endgültigen Antwort. Gib für jeden geladenen Skill und jeden Teil der Anfrage, der von keinem Skill abgedeckt wurde, „erledigt / teilweise / blockiert“ mit Beleg an (eine Datei:Zeile, ein Testergebnis, eine Befehlsausgabe). Füge es in die endgültige Antwort als kurze Tabelle ein:
| Teil | Skill | Status | Beleg |
|---|
Wenn ein Teil teilweise oder blockiert ist, sage, was fehlt, anstatt die Aufgabe als erledigt zu bezeichnen. Überspringe die Tabelle bei einer Anfrage mit einem einzelnen Skill und einem einzigen Teil.
Protokollierung: Führe python3 <base>/scripts/inventory.py --log '<json>' einmal aus, mit einem JSON-Objekt:
request (die Anfrage in maximal 160 Zeichen, keine Geheimnisse), loaded (geladene Skills), used (geladene Skills, deren Anweisungen die Arbeit tatsächlich geprägt haben), unused (geladen, aber nicht benötigt), skipped (geplante Zeilen, die nicht ausgeführt wurden), next (die von dir vorgeschlagenen Nächsten Skills), no_skill (wahr, wenn kein Skill benötigt wurde), check („erledigt“, „teilweise“, „blockiert“ oder „n. z.“). Die Protokollierung ist Teil des Routings, nicht optional. Wenn der Befehl fehlschlägt, sage dies in einer Zeile und fahre fort.
inventory.py --report zeigt später an, was /route geladen hat, was die Arbeit genutzt hat und wie vielen Nächsten Skills der Benutzer gefolgt ist.
Beginne die endgültige Antwort mit einer Zeile, die sagt, welche Skills ausgeführt wurden, damit der Benutzer es sieht, auch wenn die Tabelle weggescrollt ist: Verwendete Skills: a, b(füge ` übersprungen `c`: <Grund> hinzu, wenn eine geplante Zeile nicht ausgeführt wurde, oder Verwendete Skills: keine (<Grund>)).
Beende die endgültige Antwort mit diesem Abschnitt:
Nächste Skills
skill-name: wann (jetzt / vor dem Commit / vor dem Push / nach dem Deployment / einmal pro Woche), und warum.
Gib maximal 3 an. Nimm sie aus den NEXT-Feldern der geladenen Skills, den „Standardauswahlen“ der gelesenen Kategorien und den Schritten, die die CLAUDE.md des Projekts erfordert (z. B. einen vollständigen Testlauf vor dem Push). Behalte nur die, die zu dem passen, was tatsächlich passiert ist, und führe sie nicht aus. Dieser Abschnitt gilt auch, wenn kein Skill geladen wurde.
Aktualisieren
Führe aus, wenn der Benutzer Skills oder Plugins installiert, entfernt oder aktualisiert.
- Führe
python3 <base>/scripts/inventory.py --checkaus. Wenn esNO CATALOGausgibt, führe stattdessen den Build aus. - Für jeden NEUEN Skill: Lies seine SKILL.md (Frontmatter und die ersten ~80 Zeilen), wähle die Kategoriendatei aus, deren Umfang passt (
inventory.pylistet die festen Kategorien in seiner TAXONOMY auf), und hänge eine Zeile im selben Format wie die anderen Zeilen in dieser Datei an. Verwende[read <absoluter Pfad>], wenn sein Frontmatterdisable-model-invocation: truehat, und[project], wenn es im.claude/skillseines Repos lebt. Wenn die Kategoriendatei noch nicht existiert, erstelle sie mit demselben Header (# name,Umfang:,Standardauswahlen:). - Für jeden ENTFERNTEN Eintrag: Lösche seine Zeile und entferne ihn aus allen Texten der „Standardauswahlen“.
- Führe
inventory.py --indexaus, dann erneut--check, bis escatalog in syncausgibt. Berichte, was hinzugefügt und entfernt wurde.