reverse-skill Claude Code: Tool-Routing prüfen 2026

Dieser Leitfaden zeigt, wie Sie reverse-skill in Claude Code kontrolliert bereitstellen und das automatische Tool-Routing mit bekannten, autorisierten Samples prüfen. Sie erhalten eine Fehlerdiagnose für fehlende Trigger, falsche Methoden, fehlende Werkzeuge, zu weit gefasste Berechtigungen und fehlgeschlagene Rückfälle.

Eine Analyse landet trotz passender Beschreibung im falschen Workflow, oder reverse-skill wird von Claude Code gar nicht geladen.

Die schnellste Lösung: Begrenzen Sie zuerst Scope und Werkzeugrechte, installieren Sie reverse-skill danach in einer isolierten Umgebung und prüfen Sie es mit bekannten, legalen Samples auf Beschreibungsmatching, Werkzeugerkennung, Ausführungsplan und Rückfallverhalten. Die automatische Auswahl bleibt eine Routing-Hilfe. Sie ersetzt weder die Autorisierungsprüfung noch die menschliche Freigabe.

Wer sollte weiterlesen? Dieser Beitrag richtet sich an Sicherheitsforscher, die autorisierte APK- oder Binäranalysen reproduzierbar mit Claude Code durchführen möchten. Ebenso relevant ist er für Entwickler, die Claude Code Skills pflegen, sowie für Teams, die Analysewerkzeuge in einer abgeschotteten Remote-Umgebung betreiben und revisionssicher protokollieren müssen.

Letzte Aktualisierung: 10.08.2026. Die Angaben wurden anhand des aktuellen reverse-skill-Repositorys, der Datei SKILL.md und der aktuellen Claude-Code-Skills-Regeln geprüft.

Das eigentliche Problem hinter dem automatischen Routing

reverse-skill ist kein magischer Werkzeugwähler. Das Paket verbindet Aufgabenbeschreibung, Szenario-Skill, Werkzeugstatus und einen kontrollierten Arbeitsablauf. Das Repository beschreibt eine Kette aus globalen Regeln, Routing, Fallinitialisierung, Szenario-Skill, Werkzeugen, Zeitlinie und Bericht. Welche Analysepfade tatsächlich verfügbar sind, hängt jedoch vom aktuellen README, den Skill-Dateien und der lokalen Umgebung ab. Die Projektübersicht und der beschriebene Routing-Ablauf sind deshalb die erste Referenz.

In der Praxis sehen wir fünf verschiedene Fehlerklassen:

1. Die Skill wird nicht entdeckt. Der Ordner liegt am falschen Ort, SKILL.md fehlt oder Claude Code beobachtet den neu angelegten Skills-Pfad noch nicht.
2. Die Skill wird geladen, aber falsch ausgewählt. Die Beschreibung ist zu allgemein. Begriffe wie „Security“, „Analyse“ oder „Debugging“ passen zu vielen Workflows.
3. Das passende Werkzeug fehlt. Eine Skill kann jadx, apktool, Frida, IDA oder ein anderes Werkzeug vorsehen. Ist es nicht installiert oder nicht im Pfad, darf der Agent nicht einfach eine ungeprüfte Alternative ausführen.
4. Die Berechtigungen sind größer als der Scope. Ein Agent mit Dateisystem-, Netzwerk- oder Geheimniszugriff kann eine korrekte Analyseanweisung in eine unzulässige Aktion verwandeln.
5. Der Fehlerpfad ist unklar. Beschädigte Dateien, unbekannte Formate und fehlgeschlagene Befehle müssen zu einer nachvollziehbaren Rückgabe führen. „Versuchen Sie es erneut“ ist kein Audit-Ergebnis.

Die wichtigste Trennung lautet daher: Discovery, Routing, Tool-Verfügbarkeit, Ausführung und Audit sind fünf unterschiedliche Prüfungen. Wer nur den Endbericht kontrolliert, erkennt nicht, an welcher Stelle der Ablauf falsch abgebogen ist.

Installation und Discovery

Die Installation beginnt nicht mit einem unbeschränkten Agentenlauf, sondern mit einer kontrollierten Kopie. Das Repository nennt für die Ablage zunächst einen Git-Klon und anschließend ein plattformspezifisches Aktualisieren des Werkzeugindexes. Für Linux und macOS wird dafür ein Shell-Skript genannt; für Windows existiert eine PowerShell-Variante. Die Installations- und Indexbefehle im README sollten vor einer Anpassung unverändert geprüft werden.

Für Claude Code ist die Ordnerstruktur entscheidend. Eine Skill benötigt eine Datei namens SKILL.md. Projekt-Skills liegen typischerweise unter .claude/skills/<skill-name>/SKILL.md; persönliche Skills unter ~/.claude/skills/<skill-name>/SKILL.md. Die offizielle Dokumentation beschreibt außerdem Enterprise-, Plugin- und verschachtelte Projektpfade. Die Übersicht zu Skill-Speicherorten und Discovery sollte als Referenz für den konkreten Installationsort dienen.

Claude Code verwendet die description in der YAML-Kopfzeile als wichtigen Hinweis für die automatische Auswahl. Die kombinierte Beschreibung kann in der Skill-Auflistung auf 1.536 Zeichen begrenzt sein. Das ist keine Leistungszahl von reverse-skill, sondern eine dokumentierte Grenze für die Darstellung des Matching-Kontexts. Die offizielle Beschreibung der description- und when_to_use-Felder erklärt diese Begrenzung.

Die erste Installation sollte deshalb in fünf Schritten erfolgen:

1. Repository in ein isoliertes Arbeitsverzeichnis klonen.
2. README.md, RULES.md, skills/SKILL.md und die Routing-Dateien gegen die erwartete Version prüfen.
3. Den lokalen Werkzeugindex aktualisieren, ohne automatisch unpinned Pakete zu installieren.
4. Den Skill-Pfad in Claude Code sichtbar machen und den direkten Aufruf testen.
5. Erst danach einen harmlosen, bekannten Sample-Fall zur automatischen Auswahl verwenden.

Der direkte Slash-Aufruf ist dabei ein Diagnosewerkzeug. Wenn /reverse-skill oder der im Projekt definierte Aufruf funktioniert, aber eine natürlich formulierte Aufgabe die Skill nicht lädt, liegt der Fehler wahrscheinlich im Matching. Funktioniert auch der direkte Aufruf nicht, müssen Pfad, Name, Workspace-Vertrauen und Dateiinhalt geprüft werden.

Routing-Qualität und falsche Methodenwahl

Eine gute Beschreibung sagt nicht nur, dass eine Skill „bei Reverse Engineering“ hilft. Sie muss den Anwendungsfall abgrenzen. Besser ist eine Formulierung mit Dateityp, Ziel und Einschränkung, beispielsweise: „Autorisierte statische Analyse eines selbst erstellten Android-Pakets zur Prüfung von Manifest, Ressourcen und Bytecode; vor dynamischen Aktionen Scope und Freigabe bestätigen.“

Zu breite Trigger erzeugen zwei Risiken. Erstens wird reverse-skill bei Aufgaben geladen, die lediglich Quellcode-Debugging oder Dokumentation betreffen. Zweitens kann eine allgemeine Sicherheitsanfrage in einen Werkzeugpfad für Netzwerk- oder Angriffsketten rutschen. Die Beschreibung muss deshalb positive und negative Grenzen enthalten:

• Positiv: APK, ELF, DLL, JavaScript-Bundle, PCAP oder ausdrücklich definierter CTF-Fall.
• Ziel: statische Analyse, kontrollierte Laufzeitanalyse, Artefaktvergleich oder Berichtserstellung.
• Voraussetzung: lokales, offenes oder schriftlich freigegebenes Sample.
• Ausschluss: kein unbekanntes Drittziel, kein ungeprüfter Netzwerkzugriff, keine Wirkung auf produktive Systeme.

Die Routing-Auswahl sollte nicht nur am Endwerkzeug bewertet werden. Wir empfehlen, Claude Code vor der Ausführung diese vier Punkte ausgeben zu lassen:

1. erkannter Dateityp und Analyseziel,
2. ausgewählte Skill oder Routing-Regel,
3. benötigte Werkzeuge mit Version und Pfad,
4. Aktionen, die eine menschliche Freigabe benötigen.

Das verhindert, dass der Agent direkt von einer groben Aufgabenbeschreibung zu einer Befehlsausführung springt. reverse-skill dokumentiert eine Routing-Matrix sowie einen lokalen Tool-Index. Das Projekt nennt außerdem einen Regressionstest mit 163 Benchmark-Fällen und eine separate Prüfung für Struktur, Kohärenz und Supply-Chain-Pinning. Diese Angaben sind Repository-Angaben, keine unabhängige Leistungsbewertung. Die Test- und Verifikationsbefehle des Projekts sollten nach Änderungen an Routing oder Konfiguration erneut ausgeführt werden.

Bewertungsmatrix für den Bereitstellungsentscheid

Die Bewertung ist eine Arbeitsentscheidung, keine externe Messung. Für produktive Sicherheitsforschung ist die dritte Variante die sinnvolle Zielarchitektur: automatische Klassifikation, aber kontrollierte Ausführung.

Werkzeugindex und Abhängigkeiten

Vor jeder Analyse muss der Agent eine Werkzeugliste ausgeben. Sie sollte mindestens enthalten:

• Name des Werkzeugs,
• erkannte Version,
• absoluter Pfad,
• Rückgabestatus eines harmlosen Prüfaufrufs,
• benötigte Rechte,
• Netzabhängigkeiten,
• vorgesehener Ersatzpfad.

Ein fehlendes Werkzeug ist kein Grund für eine stillschweigende Installation. Auf einem Remote-System kann eine temporäre Installation Paketstände verändern, Systembibliotheken austauschen oder die Reproduzierbarkeit zerstören. Besonders problematisch sind globale Installationen, unpinned Downloads und Skripte, die ohne Protokollierung mit Administratorrechten laufen.

Wir gehen deshalb so vor:

1. Tool-Index aktualisieren.
2. Nur vorhandene Werkzeuge als „verfügbar“ markieren.
3. Fehlende Abhängigkeiten in einer Änderungsdatei erfassen.
4. Installation nur nach menschlicher Freigabe durchführen.
5. Version, Quelle, Prüfsumme und Rückbauweg speichern.
6. Den Routing-Test mit derselben Umgebung wiederholen.

Das Projekt weist selbst darauf hin, dass integrierte Werkzeuge jeweils eigenen Lizenzen unterliegen. Eine Skill-Bereitstellung ist daher keine pauschale Lizenzfreigabe für jedes eingebundene Programm. Die Lizenz- und Abhängigkeitsangaben im Repository gehören in die interne Freigabeprüfung.

Hinweis aus der Praxis: Ein grüner Tool-Index beweist nur, dass ein Programm gefunden wurde. Er beweist nicht, dass das Programm für den konkreten Sample-Typ geeignet ist, mit den erlaubten Rechten läuft oder verwertbare Ergebnisse erzeugt.

Berechtigungen, Datenschutz und Audit

Ein Reverse-Engineering-Agent sollte mit weniger Rechten starten, als die Werkzeugsammlung theoretisch unterstützt. Für lokale Samples genügt häufig ein dedizierter Arbeitsordner mit getrennten Eingabe-, Zwischen- und Ausgabeunterverzeichnissen. Schreibzugriff auf das gesamte Home-Verzeichnis, SSH-Schlüssel, Browserprofile oder Umgebungsvariablen mit Zugangsdaten ist nicht erforderlich.

Die Freigabe sollte vier Grenzen enthalten:

• Dateigrenze: Welche Eingabedateien und Ausgabeordner sind erlaubt?
• Netzgrenze: Ist Netzwerkzugriff vollständig deaktiviert, auf bestimmte Ziele beschränkt oder nur für Paketquellen erlaubt?
• Befehlsgrenze: Welche Programme dürfen ohne Rückfrage laufen?
• Zeitgrenze: Wann endet der Analysefall und wann muss eine neue Freigabe erfolgen?

Für Remote-Umgebungen kommen Stabilitäts- und Datenschutzfragen hinzu. Eine unterbrochene SSH-Sitzung darf keinen unkontrollierten Folgeprozess zurücklassen. Logs müssen gegen nachträgliche Manipulation geschützt und personenbezogene Daten nach dem internen Löschkonzept behandelt werden. Wenn Samples oder Protokolle personenbezogene Informationen enthalten, muss die Verarbeitung mit DSGVO-Vorgaben und den eigenen Auftragsverarbeitungsregeln abgeglichen werden. Unsere Hinweise zum Datenschutz sind für die Prüfung der eigenen Datenflüsse ein sinnvoller Ausgangspunkt.

Das minimale Audit-Paket besteht aus:

• Scope und Autorisierungsnachweis,
• Hash oder eindeutiger Kennung des Samples,
• verwendeter Skill- und Repository-Version,
• Routing-Entscheidung mit Begründung,
• Werkzeugliste und Versionsstand,
• ausgeführtem Plan,
• Befehlen und Rückgabecodes,
• Agent-Ausgaben und Fehlermeldungen,
• menschlichen Freigaben,
• manuellen Änderungen,
• Abschlussstatus und Aufbewahrungsfrist.

Automatisierung darf die Frage „Dürfen wir das?“ nicht beantworten. Sie darf höchstens zeigen, welcher erlaubte nächste Schritt technisch passt.

Fehlerfälle und Rückfallverhalten

Die letzte Prüfung ist absichtlich unangenehm. Wir verwenden nicht nur Samples, die problemlos funktionieren, sondern auch:

1. eine beschädigte Datei,
2. ein unbekanntes oder nicht unterstütztes Format,
3. ein gültiges Sample ohne installiertes Hauptwerkzeug,
4. einen Werkzeugaufruf mit absichtlich fehlerhaftem Rückgabecode,
5. eine Aufgabe ohne ausreichenden Autorisierungsnachweis.

Ein bestandener Test verlangt mehr als eine Fehlermeldung. Der Agent muss erklären, was erkannt wurde, warum der geplante Pfad nicht fortgesetzt wird und welche Information oder Freigabe fehlt. Er darf nicht automatisch auf eine riskantere Methode wechseln.

Ein guter Rückfall sieht so aus:

• Analyse wird gestoppt oder auf eine lesende Prüfung reduziert.
• Der Fehler wird mit Dateikennung, Werkzeug und Rückgabecode protokolliert.
• Kein ungeprüfter Download und keine Erweiterung des Scopes erfolgt.
• Der Agent nennt eine sichere Alternative, etwa manuelle Prüfung oder erneute Bereitstellung.
• Eine menschliche Person kann den Fall übernehmen.

Die README-Datei enthält neben dem Tool-Index auch ein Fallinitialisierungskonzept mit Scope- und Netzwerkprofil. Diese Reihenfolge ist wichtig: Erst der Fallrahmen, dann die Methode, dann die Aktion. Die Routing- und Fallstruktur im Projekt sollte in die eigene Abnahmecheckliste übernommen werden.

Abnahme vor dem ersten echten Einsatz

Vor der Freigabe dokumentieren wir einen Testlauf mit fünf Ergebnissen:

• Discovery: Wird die richtige Skill direkt und automatisch gefunden?
• Klassifikation: Wird ein APK-, Binär-, JavaScript- oder sonstiger Fall korrekt eingeordnet?
• Werkzeuge: Werden vorhandene und fehlende Werkzeuge getrennt gemeldet?
• Berechtigungen: Wird eine nicht freigegebene oder zu weit gefasste Aktion verweigert?
• Rückfall: Bleibt ein defekter oder unbekannter Fall kontrolliert und auditierbar?

Zusätzlich sollte die Beschreibung nach jedem Fehlrouting angepasst werden. Entfernen Sie breite Begriffe, die viele Aufgaben abdecken, und ergänzen Sie klare Ausschlüsse. Bewahren Sie die alte Version der SKILL.md, die Testfälle und die Routing-Ergebnisse auf. Sonst lässt sich später nicht feststellen, ob eine Änderung die Trefferquote verbessert oder nur andere Fehler erzeugt hat.

Für Teams mit mehreren Projekten ist der Scope besonders wichtig. Persönliche Skills gelten projektübergreifend, projektbezogene Skills nur im jeweiligen Repository. Gleichnamige Varianten können sich gegenseitig überlagern. Die offizielle Dokumentation beschreibt außerdem, dass ein neu angelegter Top-Level-Skills-Ordner gegebenenfalls einen Neustart benötigt, während Änderungen in bereits beobachteten Verzeichnissen live übernommen werden. Die Regeln zur Live-Erkennung und Namensauflösung gehören deshalb in den Bereitstellungsrun.

Wer den Agenten auf einem gemieteten Mac oder in einer Remote-Entwicklungsumgebung betreibt, sollte die Umgebung vor der Skill-Installation abnehmen: isoliertes Benutzerkonto, getrennte Arbeitsordner, definierte Netzwerkregeln, nachvollziehbare Sitzungsprotokolle und ein getesteter Wiederherstellungsweg. Für eine temporäre, getrennte Mac-Umgebung können Sie eine geeignete ZekVPS-Umgebung als mögliche Betriebsvariante prüfen; die konkrete Eignung hängt jedoch vom benötigten Werkzeug, der Verbindung und dem Datenschutzmodell ab.

Aktuelle Umgebung oder Mac-Umgebung?

Eine bestehende Windows- oder Linux-Umgebung kann für reverse-skill völlig ausreichend sein, wenn die benötigten Werkzeuge bereits vorhanden sind. Ihre realen Nachteile liegen meist nicht in der Routing-Idee, sondern in wechselnden Paketständen, fehlender Sitzungsstabilität und unklaren Berechtigungen. Ein kurzfristig eingerichteter Rechner erschwert außerdem die Wiederholung eines Befunds.

Eine Mac-Umgebung ist nicht automatisch besser. Sie ist sinnvoll, wenn ein reproduzierbarer Remote-Arbeitsplatz, eine klar getrennte Benutzerumgebung oder ein bestimmter Apple-bezogener Analysepfad benötigt wird. Für langfristige, dauerhaft hohe Last oder Hardwarezugriff bleibt ein eigener Rechner oft die passendere Wahl. Für zeitlich begrenzte Tests, Schulungen und autorisierte Samples kann das Mieten einer vorbereiteten Umgebung dagegen sauberer sein als das spontane Umbauen eines Alltagsrechners.

Entscheidend ist die Reihenfolge: Nicht zuerst mieten und danach über Rechte nachdenken. Erst Scope, Tools und Audit definieren; dann prüfen, welche Umgebung diese Anforderungen ohne zusätzliche Risiken erfüllt. Wer nur einen kurzfristigen Testlauf benötigt, sollte eine isolierte Umgebung nach denselben Kriterien abnehmen wie den Agenten selbst. Dazu gehören ein begrenzter Dateibereich, nachvollziehbare Sitzungen, ein definierter Netzwerkstatus und ein getesteter Rückfall.