Crafting Effective Readmes

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

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?

Before finalizing: Do not assert commands without a run check. Actually run every install/usage command you drafted and confirm it works — do not rely on recall of how the tooling behaves. Mark any command you cannot run as [unverified]. (The Reviewing path already checks content against project state; the Creating path must verify the commands it introduces.)

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

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