agentkitco/agentkit-dev-skills

Construire une carte d’intégration d’un dépôt inconnu, couvrant son objectif, ses points d’entrée, la façon de l’exécuter, ses modules principaux, son flux de données et les zones risquées, avec des références de fichiers. À utiliser lorsque l’on vous demande d’expliquer, de cartographier ou d’intégrer une base de code.

Qu'est-ce que agentkit-dev-skills ?

Cette compétence pour agents IA (comme Claude Code, Cursor ou Codex) guide l’agent à travers une exploration structurée d’un dépôt inconnu pour en produire une carte fiable en quelques pages. Elle impose un ordre précis : comprendre le problème et ses utilisateurs, exécuter les commandes, visualiser la structure, identifier les points d’entrée, tracer un flux réel, analyser les données, repérer les services externes, et évaluer la qualité du code. Chaque affirmation doit être accompagnée d’une référence de fichier (chemin et ligne) pour garantir la traçabilité. Le résultat est un résumé synthétique sous forme de fiche, qui aide un nouveau développeur à démarrer rapidement, à éviter les zones dangereuses et à comprendre les éléments non résolus.

Compatible avec~Claude Code~Codex CLI~Cursor

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

Documentation

Expliquer une base de code inconnue

Objectif : donner à un nouveau venu une carte fiable, avec des références de fichiers, en quelques pages. Chaque affirmation doit pointer vers un fichier que vous avez lu.

Explorer dans cet ordre

Objectif et utilisateurs : README, description du package, index de documentation. Quel problème cela résout-il et pour qui ?
L’exécuter : commandes d’installation, d’exécution, de test à partir des manifests, du Makefile et de la config CI. Exécutez les commandes légères (tests, lint) pour confirmer qu’elles fonctionnent ; indiquez celles que vous n’avez pas exécutées.
Structure : arborescence des répertoires sur deux niveaux (ignorez node_modules, les sorties de build, .git). Notez le(s) langage(s), framework(s), disposition monorepo.
Points d’entrée : main, fichier de démarrage du serveur, entrée CLI, définitions de routes, jobs planifiés, gestionnaires d’événements, entrées bin et scripts.
Tracer un flux réel de bout en bout : choisissez la requête, commande ou l’événement le plus central et suivez-le depuis l’entrée jusqu’au stockage ou à la sortie, en listant chaque fichier et fonction dans l’ordre.
Données : schémas, modèles, migrations, fichiers de configuration, variables d’environnement que le code lit (noms uniquement, jamais les valeurs).
Points de contact externes : bases de données, files d’attente, API tierces, fournisseurs d’authentification.
Signaux de qualité : où se trouvent les tests et ce qu’ils couvrent, vérifications CI, règles de lint, zones avec des TODOs, très gros fichiers, modifications récentes (git log --since="3 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head).

Résultat

# <dépôt> en une page
Objectif : ...
Comment l’exécuter : <commandes, vérifiées ou non>
Carte : <répertoire -> responsabilité, une ligne chacun>
Un flux, étape par étape : <fichier:fonction ...>
Données et configuration : ...
Services externes : ...
Par où commencer à lire : <3 fichiers dans l’ordre, avec pourquoi>
Zones risquées ou confuses : <fichier, raison>
Questions ouvertes : <ce que vous n’avez pas pu déterminer>

Règles

Citez chemin:ligne ou au moins chemin pour chaque affirmation. Si vous avez déduit quelque chose, étiquetez-le « déduit ».
Ne décrivez pas du code que vous n’avez pas ouvert. Ne devinez pas le contexte métier ; placez-le sous les questions ouvertes.
N’affichez jamais les valeurs secrètes provenant des fichiers .env ou de la configuration ; listez uniquement les noms de variables.
Restez court : une carte, pas une visite de chaque fichier.