agent-sort

Agent Sort – Agenten-Sortierung

Verwende diesen Skill, wenn ein Repository eine projektspezifische ECC-Oberfläche anstelle der standardmäßigen Vollinstallation benötigt.

Das Ziel ist nicht zu raten, was „nützlich erscheint“. Das Ziel ist es, ECC-Komponenten mit Belegen aus der tatsächlichen Codebasis zu klassifizieren.

Wann verwenden

• Ein Projekt benötigt nur einen Teil von ECC und Vollinstallationen sind zu überladen
• Der Repository-Stack ist klar, aber niemand möchte Skills einzeln von Hand kuratieren
• Ein Team möchte eine wiederholbare Installationsentscheidung, die auf grep-Belegen basiert, nicht auf Meinungen
• Du musst ständig geladene tägliche Arbeitsflächen von durchsuchbaren Bibliotheks-/Referenzflächen trennen
• Ein Repository ist in die falsche Sprache, Regel oder den falschen Hook-Satz abgedriftet und benötigt eine Bereinigung

Unverhandelbare Regeln

• Verwende das aktuelle Repository als Quelle der Wahrheit, nicht allgemeine Präferenzen
• Jede DAILY-Entscheidung muss konkrete Repository-Belege zitieren
• LIBRARY bedeutet nicht „löschen“; es bedeutet „zugänglich halten, ohne standardmäßig zu laden“
• Installiere keine Hooks, Regeln oder Skripte, die das aktuelle Repository nicht verwenden kann
• Bevorzuge ECC-native Oberflächen; führe kein zweites Installationssystem ein

Ausgaben

Erstelle diese Artefakte in dieser Reihenfolge:

1. DAILY-Bestand
2. LIBRARY-Bestand
3. Installationsplan
4. Überprüfungsbericht
5. optionalen skill-library-Router, falls das Projekt einen möchte

Klassifikationsmodell

Verwende nur zwei Eimer:

• DAILY
  • sollte jede Sitzung für dieses Repository laden
  • stark an die Sprache, das Framework, den Workflow oder die Operator-Oberfläche des Repositorys angepasst
• LIBRARY
  • nützlich zu behalten, aber nicht wert, standardmäßig geladen zu werden
  • sollte durch Suche, Router-Skill oder selektive manuelle Nutzung erreichbar bleiben

Belegquellen

Verwende repo-lokale Belege, bevor du eine Klassifikation vornimmst:

• Dateierweiterungen
• Paketmanager und Lockfiles
• Framework-Konfigurationen
• CI- und Hook-Konfigurationen
• Build-/Test-Skripte
• Importe und Abhängigkeitsmanifeste
• Repository-Dokumentation, die den Stack explizit beschreibt

Nützliche Befehle sind:

rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
cat pyproject.toml
cat Cargo.toml
cat pubspec.yaml
cat go.mod

Parallele Prüfdurchläufe

Falls parallele Sub-Agenten verfügbar sind, teile die Prüfung in folgende Durchläufe auf:

1. Agenten
   • klassifiziere agents/*
2. Skills
   • klassifiziere skills/*
3. Befehle
   • klassifiziere commands/*
4. Regeln
   • klassifiziere rules/*
5. Hooks und Skripte
   • klassifiziere Hook-Oberflächen, MCP-Gesundheitschecks, Hilfsskripte und Betriebssystemkompatibilität
6. Extras
   • klassifiziere Kontexte, Beispiele, MCP-Konfigurationen, Vorlagen und Anleitungsdokumente

Falls Sub-Agenten nicht verfügbar sind, führe dieselben Durchläufe sequenziell aus.

Kern-Workflow

1. Das Repository lesen

Ermittle den tatsächlichen Stack, bevor etwas klassifiziert wird:

• verwendete Sprachen
• verwendete Frameworks
• primärer Paketmanager
• Test-Stack
• Lint-/Format-Stack
• Bereitstellungs-/Laufzeit-Oberfläche
• bereits vorhandene Operator-Integrationen

2. Die Belegtabelle erstellen

Für jede Kandidaten-Oberfläche notieren:

• Komponentenpfad
• Komponententyp
• vorgeschlagener Eimer
• Repository-Beleg
• kurze Begründung

Verwende dieses Format:

skills/frontend-patterns | skill | DAILY | 84 .tsx-Dateien, next.config.ts vorhanden | Kern-Frontend-Stack
skills/django-patterns   | skill | LIBRARY | keine .py-Dateien, kein pyproject.toml       | in diesem Repo nicht aktiv
rules/typescript/*       | rules | DAILY | package.json + tsconfig.json            | aktives TS-Repo
rules/python/*           | rules | LIBRARY | null Python-Quelldateien             | nur zugänglich halten

3. Entscheiden: DAILY vs. LIBRARY

In den DAILY-Eimer verschieben, wenn:

• das Repository eindeutig den passenden Stack verwendet
• die Komponente allgemein genug ist, um jeder Sitzung zu helfen
• das Repository bereits von der entsprechenden Laufzeit oder dem Workflow abhängt

In den LIBRARY-Eimer verschieben, wenn:

• die Komponente nicht zum Stack gehört
• das Repository sie später benötigen könnte, aber nicht jeden Tag
• sie Kontext-Overhead ohne unmittelbare Relevanz hinzufügt

4. Den Installationsplan erstellen

Die Klassifikation in Aktion umsetzen:

• DAILY-Skills -> installieren oder in .claude/skills/ behalten
• DAILY-Befehle -> nur als explizite Shims behalten, falls noch nützlich
• DAILY-Regeln -> nur passende Sprachsätze installieren
• DAILY-Hooks/Skripte -> nur kompatible behalten
• LIBRARY-Oberflächen -> durch Suche oder skill-library zugänglich halten

Falls das Repository bereits selektive Installationen verwendet, aktualisiere diesen Plan, anstatt ein weiteres System zu erstellen.

5. Den optionalen Bibliotheks-Router erstellen

Falls das Projekt eine durchsuchbare Bibliotheksoberfläche wünscht, erstelle:

• .claude/skills/skill-library/SKILL.md

Dieser Router sollte enthalten:

• eine kurze Erklärung von DAILY vs. LIBRARY
• gruppierte Trigger-Keywords
• wo die Bibliotheksreferenzen leben

Dupliziere nicht jeden Skill-Text im Router.

6. Das Ergebnis überprüfen

Nachdem der Plan angewendet wurde, überprüfe:

• jede DAILY-Datei existiert am erwarteten Ort
• veraltete Sprachregeln wurden nicht aktiv gelassen
• inkompatible Hooks wurden nicht installiert
• die resultierende Installation entspricht tatsächlich dem Repository-Stack

Gib einen kompakten Bericht zurück mit:

• DAILY-Anzahl
• LIBRARY-Anzahl
• entfernte veraltete Oberflächen
• offene Fragen

Übergaben

Falls der nächste Schritt eine interaktive Installation oder Reparatur ist, übergib an:

• configure-ecc

Falls der nächste Schritt eine Überlappungsbereinigung oder Katalogüberprüfung ist, übergib an:

• skill-stocktake

Falls der nächste Schritt eine breitere Kontextbereinigung ist, übergib an:

• strategic-compact

Ausgabeformat

Gib das Ergebnis in dieser Reihenfolge zurück:

STACK
- Zusammenfassung von Sprache/Framework/Laufzeit

DAILY
- ständig geladene Elemente mit Belegen

LIBRARY
- durchsuchbare/Referenzelemente mit Belegen

INSTALLATIONSPLAN
- was installiert, entfernt oder weitergeleitet werden sollte

ÜBERPRÜFUNG
- ausgeführte Prüfungen und verbleibende Lücken