README Composer

Crafting effective readmes

by davila7 · MIT license · ★ 32,299 on GitHub

Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.

---
name: crafting-effective-readmes
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.
---

# 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?"

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.

Manual install (npx, ZIP)

Claude Codenpx skills add davila7/claude-code-templates --skill crafting-effective-readmes -g -a claude-code

Claude Code (degit)

npx degit davila7/claude-code-templates/cli-tool/components/skills/productivity/crafting-effective-readmes#main ~/.claude/skills/crafting-effective-readmes

Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md2.6 KB

Read SKILL.md here

davila7/main1 file shown

SKILL.md2.6 KB

Browse every file on GitHub↗

SKILL.md

Show the full text79 lines

crafting-effective-readmes/SKILL.md79 lines · 2.6 KB

PreviewCode

Outline

RawView on GitHub

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 type
style-guide.md - Common README mistakes and prose guidance
using-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	1. What type of project? (see Project Types below)
31	2. What problem does this solve in one sentence?
32	3. What's the quickest path to "it works"?
33	4. Anything notable to highlight?
34
35	Adding a section:
36	1. What needs documenting?
37	2. Where should it go in the existing structure?
38	3. Who needs this info most?
39
40	Updating existing content:
41	1. What changed?
42	2. Read current README, identify stale sections
43	3. Propose specific edits
44
45	Reviewing/refreshing:
46	1. Read current README
47	2. Check against actual project state (package.json, main files, etc.)
48	3. Flag outdated sections
49	4. 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	1. Name - Self-explanatory title
71	2. Description - What + why in 1-2 sentences
72	3. 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