readme-best-practices
Skill2 starsChanged 12 days agoMITView on GitHub
Create, audit, and improve GitHub README.md files following 2026 best practices. Use this skill when a user asks to write, rewrite, or review a README.md for a GitHub repository, add shields.io badges, create a project SVG logo, improve documentation structure, or make a repository more discoverable and professional — even if they just say "write the README" or "make the repo look professional". Not for agents-md, architecture-diagram.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- rolandtolnay/llm-toolkittheir own version, first seen Oct 11, 2026
- Mindrally/skillstheir own version, first seen Oct 8, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- Mindrally/skills★ 275same name
- rolandtolnay/llm-toolkit★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository63 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .agents/skills/avoid-ai-writing/AGENTS.mdAGENTS.md
- .agents/skills/do-web-doc-resolver/AGENTS.mdAGENTS.md
- .agents/skills/skill-evaluator/AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms-full.txtllms.txt
- llms.txtllms.txt
- accessibility-auditorSkill
- agent-browserSkill
- agentic-abstentionSkill
- agents-mdSkill
- api-design-firstSkill
- architecture-diagramSkill
- avoid-ai-writingSkill
- cicd-pipelineSkill
- cloudflare-worker-apiSkill
- codacySkill
- codeberg-apiSkill
- code-review-assistantSkill
- css-render-performanceSkill
- database-devopsSkill
- debuggerSkill
- delegateSkill
- dependency-upgradesSkill
- dist-channel-selectionSkill
- docs-hookSkill
- document-rendering-and-locatorsSkill
- dogfoodSkill
- dora-reportSkill
- do-web-doc-resolverSkill
- durable-objectsSkill
- eu-ai-act-complianceSkill
- git-github-workflowSkill
- goap-agentSkill
- implementerSkill
- intent-classifierSkill
- iterative-refinementSkill
- jules-delegatorSkill
- learnSkill
- lifecycle-managementSkill
- local-context-sanitizationSkill
- memory-contextSkill
- migration-refactoringSkill
- nested-build-isolationSkill
- privacy-firstSkill
- progressive-deliverySkill
- pwa-offline-syncSkill
- reader-ui-uxSkill
- secrets-managementSkill
- secure-invite-and-accessSkill
- security-code-auditorSkill
- shell-script-qualitySkill
- skill-creatorSkill
- skill-evaluatorSkill
- static-analysisSkill
- testing-strategySkill
- test-runnerSkill
- triz-solverSkill
- turso-dbSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 35
Before writing anything, gather context:
- Distinctive: line 71
Use the template at assets/logo-template.svg as starting point.
- Distinctive: line 75
Follow this exact section order:
- Very specific: line 127
Badge placement: All in the <div align="center"> header, on one line, max 6-8 badges.
- Distinctive: line 147
Zero-config first: Always show the no-API-key usage first in Quick Start
- Distinctive: line 148
Copy-paste ready: Every code block must be directly runnable without editing
- Distinctive: line 149
Consistent naming: Use the exact repo slug throughout — never an internal alias
- Distinctive: line 151
No lorem ipsum: Every section must contain accurate, real information
- Distinctive: line 159
No language specifier on fenced code blocks
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
README Best Practices (2026)
This skill guides you through creating a best-practice GitHub README.md for 2026, including a custom SVG logo and shields.io badges.
When to Use
- User asks to "write a README", "improve README", "add badges", or "create a logo"
- User asks to analyze or audit an existing README.md
- User wants to make a repository more professional or discoverable
- User asks about GitHub documentation best practices
Step-by-step workflow
1. Analyze the repository
Before writing anything, gather context:
# Detect tech stack
cat package.json 2>/dev/null | head -20
cat Cargo.toml 2>/dev/null | head -20
cat pyproject.toml 2>/dev/null | head -20
ls -1
find . -name "*.md" -maxdepth 2Identify:
- Primary language(s) and tech stack
- What the project does (one sentence)
- Key features (5-10 bullet points)
- Installation method(s)
- Whether a live demo/deployment exists
- License type
- CI/CD system (GitHub Actions workflows)
- Existing screenshots or assets
2. Create the SVG logo
See references/LOGO.md for the full logo creation guide.
Quick pattern:
- ViewBox:
0 0 320 80atwidth="320" - Dark background pill (
#0f172ato#1e293bgradient,rx="14") - Domain-specific icon on the left
- Project acronym in indigo→cyan gradient (
#6366f1to#06b6d4) - Thin divider line below acronym
- Full project name as subtitle (
#94a3b8) - Tech stack chips on the right (colored pills)
- Save to:
assets/logo.svg - Reference:
<img src="assets/logo.svg" alt="..." width="320"/>in README
Use the template at assets/logo-template.svg as starting point.
3. Write README sections (in order)
Follow this exact section order:
1. <div align="center"> header block
- Logo image
- Project title (h1)
- One-line tagline (bold) + secondary sentence
- Shields.io badge row (CI | Release | License | Languages | Demo)
- Navigation links: Demo · Docs · Report Bug · Request Feature
2. "Why [project]?" — 3-4 value-proposition bullets
3. Table of Contents (for READMEs > 100 lines)
4. Quick Start — copy-paste, zero-config first
5. Architecture — ASCII or Mermaid diagram if applicable
6. Features — table: Feature | Description
7. Installation — per interface/language with fenced code blocks
8. Configuration — env vars table: Variable | Required | Default | Notes
9. Usage — per interface with realistic, runnable examples
10. Testing — unit, integration, e2e commands
11. Repository Structure — annotated tree
12. Contributing — numbered steps
13. LicenseSee references/STRUCTURE.md for full copy-paste templates.
4. Add shields.io badges
See references/BADGES.md for the complete badge catalog.
Required badges (always include):
- CI/CD status (
github/actions/workflows/ci.yml/badge.svg) - Latest release version (
shields.io/github/v/release/...) - License
- Primary language(s)
Recommended additions:
- Live demo (Vercel / Netlify)
- PRs Welcome
- Code coverage (if Codecov/Coveralls configured)
Badge placement: All in the <div align="center"> header, on one line, max 6-8 badges.
5. Quality checklist
Before finalising, verify:
- Logo renders in both light and dark GitHub themes
- All badge image URLs are valid (no 404s)
- Quick Start works with zero API keys / credentials
- All fenced code blocks have a language specifier (
```bash,```python, etc.) - All internal links (CONTRIBUTING.md, LICENSE, docs/) exist in the repo
- Table of Contents anchor links match actual heading text
- No broken image
srcreferences - Repo name in README matches
github.com/owner/repoexactly (no old aliases) - README description matches the GitHub repo "About" field
- Installation section has commands for every supported interface
Key principles
- First 3 seconds rule: Logo + tagline + badges must communicate value immediately
- Zero-config first: Always show the no-API-key usage first in Quick Start
- Copy-paste ready: Every code block must be directly runnable without editing
- Consistent naming: Use the exact repo slug throughout — never an internal alias
- Progressive detail: Overview → Quick Start → Full docs (do not front-load everything)
- No lorem ipsum: Every section must contain accurate, real information
Common mistakes to avoid
- Using a stale project name that differs from the current repo slug
- Placing Installation before a "Why use this?" value pitch
- Missing Table of Contents on READMEs longer than 100 lines
- Broken badge URLs pointing to non-existent CI workflow files
- No language specifier on fenced code blocks
- Image paths that work locally but break on GitHub (always use paths from repo root)
- More than 8 badges (becomes noise)
- Forgetting
<div align="center">closing tag
See Also
architecture-diagram— Project architecture diagramsagents-md— AGENTS.md best practices
Rationalizations
| Rationalization | Reality |
| "Any README is better than no README" | A bad README actively damages trust; incomplete or broken docs are worse than none. |
| "Badges are just decoration" | Badges convey CI status, version, and license at a glance — they are functional signals. |
| "I'll update the README when I have time" | Stale READMEs mislead contributors and users; update docs alongside code changes. |
Red Flags
- README contains placeholder text or lorem ipsum
- Badge URLs point to non-existent workflow files
- Quick Start requires API keys or credentials without mention
Voice & Context
- Default:
professional+blog - Reference:
voice-profilesskill for definitions and auto-detection.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

