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?"
| 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
More from whinc/wechat-miniprogram-skills
miniprogram-automation
Use when working with WeChat mini-program automation (小程序自动化、自动化测试、E2E) via miniprogram-automator, especially for standalone Node scripts or Jest tests involving DevTools launch/connect, page navigation, waitFor, custom-component selectors, wx method mocking, console or exception listeners, screenshots, regression checks, or troubleshooting launch failures, connection timeouts, and element-not-found issues.
127miniprogram-ci
Use when the user wants to automate WeChat mini-program upload, preview, or npm packaging via CI/CD, generate deployment scripts, set up miniprogram-ci workflows, or create preview QR codes automatically. Trigger whenever the user mentions "上传小程序", "预览", "CI 部署", "miniprogram-ci", "自动化上传", "发布小程序版本", "生成预览二维码", "打包npm", "pack-npm", "构建npm依赖", "GitHub Actions 小程序", "pnpm 小程序部署", or asks to integrate WeChat mini-program with continuous integration pipelines (GitHub Actions, GitLab CI, etc.).
106react-effects
React useEffect anti-pattern detection and correction guide. Use this skill whenever writing, reviewing, or modifying any React component that contains useEffect, or when about to add a useEffect hook. Also trigger when you see patterns like "setState inside useEffect", "effect chains", "derived state in effect", or "notify parent in effect". Covers 12 specific scenarios where Effects are unnecessary or misused, with correct alternatives. Even if the useEffect looks reasonable at first glance, consult this skill to verify it's truly needed.
32commit-work
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
30