agent-sort

Agent Sort

Verwende diese Fähigkeit, 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, ECC-Komponenten mit Beweisen aus der tatsächlichen Codebasis zu klassifizieren.

Wann zu verwenden

• Ein Projekt benötigt nur eine Teilmenge von ECC und Vollinstallationen sind zu überladen
• Der Repository-Stack ist klar, aber niemand möchte Skills manuell einzeln kuratieren
• Ein Team möchte eine wiederholbare Installationsentscheidung, die auf grep-Beweisen basiert, anstatt auf Meinungen
• Du musst ständig geladene tägliche Workflow-Oberflächen von durchsuchbaren Bibliotheks-/Referenzoberflächen trennen
• Ein Repository ist in die falsche Sprache, Regel oder den falschen Hook-Set abgedriftet und muss bereinigt werden

Unverhandelbare Regeln

• Verwende das aktuelle Repository als Quelle der Wahrheit, nicht allgemeine Präferenzen
• Jede DAILY-Entscheidung muss konkrete Repository-Beweise anführen
• 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-Inventar
2. LIBRARY-Inventar
3. Installationsplan
4. Verifizierungsbericht
5. optionalen skill-library-Router, falls das Projekt einen wünscht

Klassifizierungsmodell

Verwende nur zwei Buckets:

• DAILY
  • sollte jede Sitzung für dieses Repository geladen werden
  • 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-Fähigkeit oder selektive manuelle Nutzung erreichbar bleiben

Beweisquellen

Verwende repo-lokale Beweise, bevor du eine Klassifizierung vornimmst:

• Dateierweiterungen
• Paketmanager und Sperrdateien
• 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 Überprüfungsdurchläufe

Falls parallele Unteragenten verfügbar sind, teile die Überprüfung in diese 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 keine Unteragenten verfügbar sind, führe dieselben Durchläufe sequenziell aus.

Kern-Workflow

1. Lesen des Repositorys

Ermittle den tatsächlichen Stack, bevor du etwas klassifizierst:

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

2. Erstellen der Beweistabelle

Für jede Kandidatenoberfläche notiere:

• Komponentenpfad
• Komponententyp
• vorgeschlagener Bucket
• Repository-Beweis
• 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. Entscheidung: DAILY vs. LIBRARY

Befördere zu DAILY, wenn:

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

Verschiebe zu LIBRARY, wenn:

• die Komponente außerhalb des Stacks liegt
• das Repository sie später benötigen könnte, aber nicht jeden Tag
• sie Kontext-Overhead ohne unmittelbare Relevanz hinzufügt

4. Erstellen des Installationsplans

Übersetze die Klassifizierung in Aktionen:

• DAILY-Skills -> installieren oder in .claude/skills/ behalten
• DAILY-Befehle -> nur als explizite Shims behalten, falls noch nützlich
• DAILY-Regeln -> nur passende Sprachsets 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. Erstellen des optionalen Library-Routers

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 Auslöseschlüsselwörter
• wo die Bibliotheksreferenzen leben

Dupliziere nicht jeden Skill-Body im Router.

6. Überprüfen des Ergebnisses

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, übergebe an:

• configure-ecc

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

• skill-stocktake

Falls der nächste Schritt eine breitere Kontextkürzung ist, übergebe an:

• strategic-compact

Ausgabeformat

Gib das Ergebnis in dieser Reihenfolge zurück:

STACK
- Sprache/Framework/Laufzeit-Zusammenfassung

DAILY
- immer geladene Elemente mit Beweisen

LIBRARY
- durchsuchbare/referenzierbare Elemente mit Beweisen

INSTALLATIONSPLAN
- was installiert, entfernt oder geroutet werden sollte

VERIFIZIERUNG
- durchgeführte Prüfungen und verbleibende Lücken