agentleFS
d-o-hubd-o-hub/github-template-ai-agents/.agents/skills/readme-best-practices/SKILL.md

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

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
  1. Distinctive:

    Before writing anything, gather context:

    line 35
  2. Distinctive:

    Use the template at assets/logo-template.svg as starting point.

    line 71
  3. Distinctive:

    Follow this exact section order:

    line 75
  4. Very specific:

    Badge placement: All in the <div align="center"> header, on one line, max 6-8 badges.

    line 127
  5. Distinctive:

    Zero-config first: Always show the no-API-key usage first in Quick Start

    line 147
  6. Distinctive:

    Copy-paste ready: Every code block must be directly runnable without editing

    line 148
  7. Distinctive:

    Consistent naming: Use the exact repo slug throughout — never an internal alias

    line 149
  8. Distinctive:

    No lorem ipsum: Every section must contain accurate, real information

    line 151
  9. Distinctive:

    No language specifier on fenced code blocks

    line 159

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 2

Identify:

  • 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 80 at width="320"
  • Dark background pill (#0f172a to #1e293b gradient, rx="14")
  • Domain-specific icon on the left
  • Project acronym in indigo→cyan gradient (#6366f1 to #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. License

See 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 src references
  • Repo name in README matches github.com/owner/repo exactly (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 diagrams
  • agents-md — AGENTS.md best practices

Rationalizations

RationalizationReality
"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-profiles skill for definitions and auto-detection.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.