agentkitco/agentkit-dev-skills

Erstelle eine Einführungskarte eines unbekannten Repositorys, die Zweck, Einstiegspunkte, Ausführung, Hauptmodule, Datenfluss und Risikobereiche mit Dateiverweisen abdeckt. Verwende dies, wenn du aufgefordert wirst, eine Codebasis zu erklären, abzubilden oder einzuarbeiten.

Was ist agentkit-dev-skills?

Diese Fähigkeit ermöglicht es einem KI-Agenten, systematisch ein unbekanntes Code-Repository zu erkunden und eine vertrauenswürdige, kompakte „Karte„ für neue Entwickler zu erstellen. Sie ist besonders nützlich für Entwickler, die in ein neues Projekt einsteigen, oder für KI-Assistenten, die bei der Codebasis-Orientierung helfen. Der Agent folgt einer strengen Reihenfolge: Er beginnt mit Zweck und Benutzern (README, Paketbeschreibung), fährt fort mit Ausführungskommandos (Installation, Tests, Linting), analysiert die Verzeichnisstruktur, identifiziert Einstiegspunkte (main, Server, CLI, Routen), verfolgt einen zentralen Datenfluss durch die Dateien, dokumentiert Schemata und Konfigurationen, listet externe Abhängigkeiten auf und bewertet die Codequalität anhand von Tests, TODOs und kürzlichen Änderungen. Die Ausgabe erfolgt in einem strukturierten Markdown-Format mit einer einseitigen Zusammenfassung, die Dateipfade und Zeilennummern als Belege enthält. Wichtig: Der Agent darf nur über tatsächlich gelesene Dateien berichten, Geheimnisse niemals preisgeben und nicht spekulieren – offene Fragen werden explizit als solche markiert. Diese Skill ist für alle textbasierten KI-Agenten geeignet, die Zugriff auf das Dateisystem haben (z. B. Claude Code, Cursor, Codex).

Funktioniert mit~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/agentkitco/agentkit-dev-skills/tree/HEAD/skills/explain-codebase

Dokumentation

Eine unbekannte Codebasis erklären

Ziel: Einem Neuling eine vertrauenswürdige Karte geben, mit Dateiverweisen, auf wenigen Seiten. Jede Behauptung muss auf eine gelesene Datei verweisen.

Erkunde in dieser Reihenfolge

Zweck und Benutzer: README, Paketbeschreibung, Dokumentationsindex. Welches Problem löst das und für wen?
Ausführen: Installations-, Ausführungs- und Testbefehle aus Manifests, Makefile und CI-Konfiguration. Führe die günstigen aus (Tests, Linting), um zu bestätigen, dass sie funktionieren; sag, welche du nicht ausgeführt hast.
Struktur: Verzeichnisbaum zwei Ebenen tief (ignoriere node_modules, Build-Ausgabe, .git). Notiere Sprache(n), Framework(s), Monorepo-Aufbau.
Einstiegspunkte: main, Server-Startdatei, CLI-Einstieg, Routendefinitionen, geplante Jobs, Event-Handler, bin- und scripts-Einträge.
Einen echten Ablauf von Anfang bis Ende verfolgen: Wähle die zentralste Anfrage, den wichtigsten Befehl oder das wichtigste Ereignis und folge ihm vom Einstieg bis zur Speicherung oder Ausgabe. Liste jede Datei und Funktion in der Reihenfolge auf.
Daten: Schemata, Modelle, Migrationen, Konfigurationsdateien, Umgebungsvariablen, die der Code liest (nur Namen, niemals Werte).
Externe Berührungspunkte: Datenbanken, Warteschlangen, Drittanbieter-APIs, Authentifizierungsanbieter.
Qualitätssignale: Wo Tests leben und was sie abdecken, CI-Prüfungen, Lint-Regeln, Bereiche mit TODOs, sehr große Dateien, kürzliche Änderungen (git log --since="3 Monate ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head).

Ausgabe

# <repo> auf einer Seite
Zweck: ...
Ausführen: <Befehle, verifiziert oder nicht>
Karte: <Verzeichnis -> Verantwortung, eine Zeile pro Eintrag>
Ein Ablauf, Schritt für Schritt: <Datei:Funktion ...>
Daten und Konfiguration: ...
Externe Dienste: ...
Wo mit dem Lesen beginnen: <3 Dateien in Reihenfolge, mit Begründung>
Riskante oder verwirrende Bereiche: <Datei, Grund>
Offene Fragen: <Was du nicht ermitteln konntest>

Regeln

Zitiere Pfad:Zeile oder zumindest Pfad für jede Behauptung. Wenn du etwas abgeleitet hast, kennzeichne es mit „abgeleitet“.
Beschreibe keinen Code, den du nicht geöffnet hast. Rate nicht über den Geschäftskontext; setze es unter offene Fragen.
Gib niemals geheime Werte aus .env-Dateien oder Konfigurationen preis; liste nur Variablennamen auf.
Halte es kurz: Eine Karte, keine Besichtigungstour durch jede Datei.