Generate readme
Skill prathakmalik/agent-standards-kit/skills/generate-readme
Version your team's AI coding standards (skills + rules) as code, auto-sync them into Cursor, Claude Code and Copilot, and keep them fresh with a nudge -> skill -> PR loop. A GitOps-style starter template you can clone in under 5 minutes.
npx -y skills add prathakmalik/agent-standards-kit --skill generate-readmeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 12 days oldThe repository was created 12 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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
Generates or refreshes a repository's README.md by scanning the codebase for its purpose, structure, entry points, setup steps, and key workflows. Use when a repo has no README, a stub README, or the README is stale after significant changes. Trigger phrases: "generate the readme", "refresh the readme", "write a readme for this repo".
SKILL.md
1.8 KB, as published. Nobody here has run it
generate-readme
Produce a clear, human-facing README.md grounded in what the code actually does — not a generic template.
When to use
- New repo with no or stub README.
- After architecture changes (new entry points, services, commands, config).
- When onboarding notes are out of date.
Process
- Scan for signal (do not guess):
- Manifest / build files (
package.json,pyproject.toml,pom.xml,go.mod,Cargo.toml, etc.) for name, scripts, deps. - Entry points, CLI commands, exported modules.
- Config and environment files (redact secret values; list the keys).
- Existing docs, comments, and tests for intent.
- Manifest / build files (
- Draft these sections (skip any that don't apply):
- One-line description (what + who it's for).
- Quick start (install -> run -> verify), copy-paste, minimal.
- Key concepts / architecture (a diagram if the structure is non-trivial).
- Configuration (keys, not secret values).
- How to contribute / run tests.
- Add a diagram when structure is non-trivial. Prefer a Mermaid
flowchartorsequenceDiagram. Keep node names free of spaces. - Write the file and summarize what you inferred so the human can correct it.
Rules
- Ground every claim in something you found in the repo. If unsure, ask or mark it
TODO. - Never paste secret values. List config keys only.
- Match the project's existing tone if one exists.
- Keep the quick start truly runnable — no assumed globals.
Gives 0 of the 12 instructions most readme changelog skills give
Counted across 471 of the 478 authors here whose files we hold, read 2026-08-06
- follow the Keep a Changelog formatin 31 of 471, across 26 files
- omit empty sectionsin 21 of 471
- Run from the git repository rootin 20 of 471, across 7 files
- save output directly to CHANGELOG.mdin 20 of 471, across 7 files
- Group commits into logical categoriesin 19 of 471, across 6 files
- Review the generated changelog before publishingin 19 of 471, across 6 files
- Apply changelog guidelines and brand voicein 18 of 471, across 5 files
- Exclude internal commits like refactoring and testsin 18 of 471, across 5 files
- Specify date ranges for focused changelogsin 17 of 471, across 4 files
- Convert technical commits into customer languagein 17 of 471, across 4 files
- group commits by conventional commit typein 14 of 471
- insert new entry below unreleased sectionin 14 of 471
Said here and by no other author read
- scan manifests and entry points for project facts
- draft a concise project description
- write a copy-paste quick start guide
- document configuration keys
- explain non-trivial architecture in a diagram
- use a mermaid diagram for non-trivial structure
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.