Crafting effective readmes skill

Use when writing or improving README files.

by davila7·MIT license·★ 32,299 Stars on the repo·GitHub ↗

Use now

Files of Crafting effective readmes

davila7/main1 file shown
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:

  1. What type of project? (see Project Types below)
  2. What problem does this solve in one sentence?
  3. What's the quickest path to "it works"?
  4. Anything notable to highlight?

Adding a section:

  1. What needs documenting?
  2. Where should it go in the existing structure?
  3. Who needs this info most?

Updating existing content:

  1. What changed?
  2. Read current README, identify stale sections
  3. Propose specific edits

Reviewing/refreshing:

  1. Read current README
  2. Check against actual project state (package.json, main files, etc.)
  3. Flag outdated sections
  4. 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:

  1. Name - Self-explanatory title
  2. Description - What + why in 1-2 sentences
  3. Usage - How to use it (examples help)

References

  • section-checklist.md - Which sections to include by project type
  • style-guide.md - Common README mistakes and prose guidance
  • using-references.md - Guide to deeper reference materials
1---
2name: crafting-effective-readmes
3description: 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 
10READMEs 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:**
301. What type of project? (see Project Types below)
312. What problem does this solve in one sentence?
323. What's the quickest path to "it works"?
334. Anything notable to highlight?
34 
35**Adding a section:**
361. What needs documenting?
372. Where should it go in the existing structure?
383. Who needs this info most?
39 
40**Updating existing content:**
411. What changed?
422. Read current README, identify stale sections
433. Propose specific edits
44 
45**Reviewing/refreshing:**
461. Read current README
472. Check against actual project state (package.json, main files, etc.)
483. Flag outdated sections
494. Update "Last reviewed" date if present
50 
51### Step 3: Always Ask
52 
53After 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 
68Every README needs at minimum:
69 
701. **Name** - Self-explanatory title
712. **Description** - What + why in 1-2 sentences
723. **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