Crafting effective readmes skill
Use when writing or improving README files.
by davila7·MIT license·★ 32,299 Stars on the repo·GitHub ↗
Use now
npx degit davila7/claude-code-templates/cli-tool/components/skills/productivity/crafting-effective-readmes#main ~/.claude/skills/crafting-effective-readmesChecked ·commit main
Files of Crafting effective readmes
SKILL.md
Show the full text79 lines
Crafting Effective READMEs
Overview
READMEs answer questions your audience will have. Different audiences need different information - a contributor to an OSS project needs different context than future-you opening a config folder.
Always ask: Who will read this, and what do they need to know?
Process
Step 1: Identify the Task
Ask: "What README task are you working on?"
| Task | When |
|---|---|
| Creating | New project, no README yet |
| Adding | Need to document something new |
| Updating | Capabilities changed, content is stale |
| Reviewing | Checking if README is still accurate |
Step 2: Task-Specific Questions
Creating initial README:
- What type of project? (see Project Types below)
- What problem does this solve in one sentence?
- What's the quickest path to "it works"?
- Anything notable to highlight?
Adding a section:
- What needs documenting?
- Where should it go in the existing structure?
- Who needs this info most?
Updating existing content:
- What changed?
- Read current README, identify stale sections
- Propose specific edits
Reviewing/refreshing:
- Read current README
- Check against actual project state (package.json, main files, etc.)
- Flag outdated sections
- Update "Last reviewed" date if present
Step 3: Always Ask
After drafting, ask: "Anything else to highlight or include that I might have missed?"
Project Types
| Type | Audience | Key Sections | Template |
|---|---|---|---|
| Open Source | Contributors, users worldwide | Install, Usage, Contributing, License | templates/oss.md |
| Personal | Future you, portfolio viewers | What it does, Tech stack, Learnings | templates/personal.md |
| Internal | Teammates, new hires | Setup, Architecture, Runbooks | templates/internal.md |
| Config | Future you (confused) | What's here, Why, How to extend, Gotchas | templates/xdg-config.md |
Ask the user if unclear. Don't assume OSS defaults for everything.
Essential Sections (All Types)
Every README needs at minimum:
- Name - Self-explanatory title
- Description - What + why in 1-2 sentences
- Usage - How to use it (examples help)
References
section-checklist.md- Which sections to include by project typestyle-guide.md- Common README mistakes and prose guidanceusing-references.md- Guide to deeper reference materials
| 1 | |
| 2 | name crafting-effective-readmes |
| 3 | description Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type. |
| 4 | |
| 5 | |
| 6 | # Crafting Effective READMEs |
| 7 | |
| 8 | ## Overview |
| 9 | |
| 10 | READMEs answer questions your audience will have. Different audiences need different information - a contributor to an OSS project needs different context than future-you opening a config folder. |
| 11 | |
| 12 | **Always ask:** Who will read this, and what do they need to know? |
| 13 | |
| 14 | ## Process |
| 15 | |
| 16 | ### Step 1: Identify the Task |
| 17 | |
| 18 | **Ask:** "What README task are you working on?" |
| 19 | |
| 20 | | Task | When | |
| 21 | |------|------| |
| 22 | | **Creating** | New project, no README yet | |
| 23 | | **Adding** | Need to document something new | |
| 24 | | **Updating** | Capabilities changed, content is stale | |
| 25 | | **Reviewing** | Checking if README is still accurate | |
| 26 | |
| 27 | ### Step 2: Task-Specific Questions |
| 28 | |
| 29 | **Creating initial README:** |
| 30 | What type of project? (see Project Types below) |
| 31 | What problem does this solve in one sentence? |
| 32 | What's the quickest path to "it works"? |
| 33 | Anything notable to highlight? |
| 34 | |
| 35 | **Adding a section:** |
| 36 | What needs documenting? |
| 37 | Where should it go in the existing structure? |
| 38 | Who needs this info most? |
| 39 | |
| 40 | **Updating existing content:** |
| 41 | What changed? |
| 42 | Read current README, identify stale sections |
| 43 | Propose specific edits |
| 44 | |
| 45 | **Reviewing/refreshing:** |
| 46 | Read current README |
| 47 | Check against actual project state (package.json, main files, etc.) |
| 48 | Flag outdated sections |
| 49 | Update "Last reviewed" date if present |
| 50 | |
| 51 | ### Step 3: Always Ask |
| 52 | |
| 53 | After drafting, ask: **"Anything else to highlight or include that I might have missed?"** |
| 54 | |
| 55 | ## Project Types |
| 56 | |
| 57 | | Type | Audience | Key Sections | Template | |
| 58 | |------|----------|--------------|----------| |
| 59 | | **Open Source** | Contributors, users worldwide | Install, Usage, Contributing, License | `templates/oss.md` | |
| 60 | | **Personal** | Future you, portfolio viewers | What it does, Tech stack, Learnings | `templates/personal.md` | |
| 61 | | **Internal** | Teammates, new hires | Setup, Architecture, Runbooks | `templates/internal.md` | |
| 62 | | **Config** | Future you (confused) | What's here, Why, How to extend, Gotchas | `templates/xdg-config.md` | |
| 63 | |
| 64 | **Ask the user** if unclear. Don't assume OSS defaults for everything. |
| 65 | |
| 66 | ## Essential Sections (All Types) |
| 67 | |
| 68 | Every README needs at minimum: |
| 69 | |
| 70 | **Name** - Self-explanatory title |
| 71 | **Description** - What + why in 1-2 sentences |
| 72 | **Usage** - How to use it (examples help) |
| 73 | |
| 74 | ## References |
| 75 | |
| 76 | `section-checklist.md` - Which sections to include by project type |
| 77 | `style-guide.md` - Common README mistakes and prose guidance |
| 78 | `using-references.md` - Guide to deeper reference materials |
| 79 |
Discussion
Browse more free Claude skills.