Readme generator
Skill sharklandy/claude-code-starter-kit/skills/process/readme-generator
Skills, subagents et templates /goal//loop//schedule prêts à l'emploi pour Claude Code — installables en une commande via /plugin marketplace add
npx -y skills add sharklandy/claude-code-starter-kit --skill readme-generatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate or incrementally update a project's README.md from an analysis of its structure, dependencies, scripts, tests and CI. Trigger whenever asked to write, generate, or update a README.
SKILL.md
3.3 KB, as published. Nobody here has run it
<!-- Skill générique de la "vague 2" -->
Générer ou mettre à jour un README (générique)
- Détecter si un
README.mdexiste déjà.- S'il existe et contient déjà du contenu substantiel, proposer une mise à jour incrémentale (ajouter/corriger les sections obsolètes ou manquantes) plutôt qu'un remplacement complet par défaut. Ne remplacer entièrement que si l'utilisateur le demande explicitement ou si le fichier existant est un simple stub vide de scaffolding.
- S'il n'existe pas, en générer un nouveau à partir des sections ci-dessous.
- Analyser le projet avant de rédiger :
- Nom et description : déduits du manifeste (
package.json,pyproject.toml,Cargo.toml...) ou du nom du dépôt si absent. - Installation : commande d'installation des dépendances détectée
(
npm install,pip install -r requirements.txt,cargo build...). - Usage : scripts disponibles dans le manifeste (
scriptsdepackage.json, cibles deMakefile...), avec un exemple d'appel pour chacun des plus utilisés (démarrage, build, test). - Structure du projet : dossiers de premier niveau significatifs, avec une phrase par dossier plutôt qu'un simple arbre de fichiers brut.
- Tests et CI : commande de test détectée, et présence d'une CI
(
.github/workflows/,.gitlab-ci.yml...) à mentionner si elle existe. - Contribution : renvoyer vers un
CONTRIBUTING.mdexistant s'il y en a un, sinon proposer une section minimale. - Licence : détectée depuis un fichier
LICENSEexistant si présent.
- Nom et description : déduits du manifeste (
- S'adapter à ce qui existe déjà plutôt que d'imposer un template rigide : si le projet a des sections déjà présentes qui ne correspondent pas exactement à la liste ci-dessus (ex. une section "Architecture" ou "FAQ" spécifique au projet), les conserver plutôt que de les supprimer pour se conformer strictement au gabarit.
- Ne jamais affirmer qu'une commande "fonctionne" ou qu'un test "passe" sans l'avoir réellement vérifié dans cette session — décrire ce que fait la commande d'après le manifeste, pas un résultat non observé.
Gotchas
- Un projet avec plusieurs manifestes (monorepo avec un
package.jsonpar package) ne doit pas être résumé uniquement à partir du manifeste racine — vérifier s'il existe une structure de sous-projets à refléter dans la section "Structure du projet". - Un
README.mdexistant peut contenir des instructions d'installation déjà obsolètes par rapport au manifeste actuel (dépendance renommée, commande de script renommée) — comparer explicitement le contenu existant à l'état réel du manifeste avant de le considérer à jour. - Les sections d'un README existant qui ne se déduisent pas du code (badges, liens vers une doc externe, mentions légales ou de licence commerciale) doivent être préservées telles quelles lors d'une régénération — les recenser avant de générer, sous peine de les détruire silencieusement.