readme-writing-readme-files
README quality standards for engaging, accessible, scannable content including problem-solution hooks, plain language (no unexplained jargon), acronym context, paragraph limits (≤5 lines), benefits-focused language, visual hierarchy, and progressive disclosure. Essential for creating effective README files that welcome and guide users.
Best use case
readme-writing-readme-files is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
README quality standards for engaging, accessible, scannable content including problem-solution hooks, plain language (no unexplained jargon), acronym context, paragraph limits (≤5 lines), benefits-focused language, visual hierarchy, and progressive disclosure. Essential for creating effective README files that welcome and guide users.
Teams using readme-writing-readme-files should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/readme-writing-readme-files/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How readme-writing-readme-files Compares
| Feature / Agent | readme-writing-readme-files | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
README quality standards for engaging, accessible, scannable content including problem-solution hooks, plain language (no unexplained jargon), acronym context, paragraph limits (≤5 lines), benefits-focused language, visual hierarchy, and progressive disclosure. Essential for creating effective README files that welcome and guide users.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Writing README Files ## Purpose This Skill provides comprehensive guidance for writing **high-quality README files** that are engaging, accessible, and scannable. READMEs serve as the entry point for repositories, projects, and directories, requiring special attention to clarity, structure, and user experience. **When to use this Skill:** - Creating repository README.md files - Writing project/package README files - Creating directory README files for navigation - Updating existing READMEs for clarity - Reviewing READMEs for quality standards ## Core README Principles ### Problem-Solution Hook **Start with WHY**: Begin with a clear problem-solution hook that immediately shows value. ✅ **Good opening**: ```markdown # Project Name **Problem**: Managing enterprise Shariah-compliant rules is complex and time-consuming. **Solution**: Open Sharia Enterprise provides automated, validated rule management. ``` ❌ **Weak opening**: ```markdown # Project Name This is a project that does things. ``` ### Plain Language Requirement **Avoid unexplained jargon**: Use plain language and explain technical terms on first use. ✅ **Good**: ```markdown Uses **Nx** (a monorepo build system) to manage multiple applications. ``` ❌ **Bad**: ```markdown Uses Nx for the monorepo. ← What's Nx? What's a monorepo? ``` **Acronym Context**: Define acronyms on first use. ✅ **Good**: `WCAG (Web Content Accessibility Guidelines)` ❌ **Bad**: `WCAG compliance required` ### Paragraph Length Limit **Maximum 5 lines per paragraph**: Keep paragraphs scannable. ✅ **Good**: ```markdown This project uses Volta for Node.js version management. Volta automatically switches to the correct Node.js and npm versions based on package.json configuration. This ensures all developers have identical environments. Benefits include simplified onboarding and zero version conflicts. ``` ❌ **Bad** (8 lines in one paragraph): ```markdown This project uses Volta for Node.js version management which automatically switches to the correct Node.js and npm versions based on package.json configuration ensuring all developers have identical environments and this provides benefits including simplified onboarding and zero version conflicts and removes the need for manual version switching and solves many common environment-related issues that teams face when working with different Node.js versions across development, staging, and production environments. ``` ### Benefits-Focused Language **Emphasize outcomes, not features**: Show WHAT users gain, not just WHAT the system does. ✅ **Benefits-focused**: ```markdown ## Key Benefits - **Faster Development**: Automated code generation reduces boilerplate by 70% - **Fewer Bugs**: Type-safe APIs catch errors at compile time - **Easier Onboarding**: Standardized structure helps new developers start quickly ``` ❌ **Feature-focused**: ```markdown ## Features - Has code generation - Uses TypeScript - Has standardized folder structure ``` ### Visual Hierarchy and Structure **Use headings, lists, and formatting to create scannable structure:** - **H2 for major sections**: ## Installation, ## Usage, ## Contributing - **Lists for steps**: Use ordered lists for sequential steps - **Bold for emphasis**: Highlight key terms - **Code blocks for commands**: Always format code properly - **Tables for comparisons**: Use tables for structured data ### Progressive Disclosure **Layer information from essential to detailed:** 1. **Above the fold**: Problem, solution, key benefits 2. **Quick start**: Minimal steps to get started 3. **Common use cases**: Typical workflows 4. **Detailed documentation**: Link to full docs 5. **Advanced topics**: Link to in-depth guides ## Standard README Structure ````markdown # Project Name Brief one-line description (what it does, who it's for) [Optional: Badges for build status, version, license] ## Overview Problem-solution hook (2-3 paragraphs max) ## Key Benefits - Benefit 1 - Benefit 2 - Benefit 3 ## Quick Start ```bash # Minimal steps to run npm install npm start ``` ```` ## Installation Detailed installation steps (if different from Quick Start) ## Usage Common use cases with code examples ## Documentation Links to full documentation ## Contributing How to contribute (link to CONTRIBUTING.md) ## License License type with link to LICENSE file ``` ## Common Mistakes ### ❌ Mistake 1: Starting with features, not benefits **Wrong**: Lists features without context **Right**: Shows problem, solution, and benefits first ### ❌ Mistake 2: Unexplained acronyms **Wrong**: "Supports WCAG, ARIA, WAI" **Right**: "Supports WCAG (Web Content Accessibility Guidelines), ARIA (Accessible Rich Internet Applications), and WAI (Web Accessibility Initiative) standards" ### ❌ Mistake 3: Wall of text paragraphs **Wrong**: 10+ line paragraphs that are hard to scan **Right**: Max 5 lines per paragraph, use lists and headings ### ❌ Mistake 4: Missing context for jargon **Wrong**: "Uses Nx monorepo with affected builds" **Right**: "Uses **Nx** (a monorepo build system) to manage multiple apps. The 'affected' feature only rebuilds changed projects, saving time." ### ❌ Mistake 5: No quick start section **Wrong**: Jumps directly into detailed installation **Right**: Provides "Quick Start" with minimal steps, then detailed installation ## Quick Quality Checklist - [ ] Problem-solution hook in first 2-3 paragraphs - [ ] All acronyms explained on first use - [ ] All jargon explained in plain language - [ ] No paragraphs exceed 5 lines - [ ] Benefits emphasized over features - [ ] Clear visual hierarchy (headings, lists, formatting) - [ ] Quick start section with minimal steps - [ ] Code blocks properly formatted with language - [ ] Links to detailed documentation - [ ] Professional, welcoming tone ## References **Primary Convention**: [README Quality Convention](../../../repo-governance/conventions/writing/readme-quality.md) **Related Conventions**: - [Content Quality Principles](../../../repo-governance/conventions/writing/quality.md) - Universal markdown standards - [Accessibility First Principle](../../../repo-governance/principles/content/accessibility-first.md) - Accessibility requirements **Related Skills**: - `docs-applying-content-quality` - Universal content quality standards --- This Skill packages README quality standards for creating engaging, accessible, scannable entry points for repositories and projects. For comprehensive details, consult the primary convention document. ```
Related Skills
plan-writing-gherkin-criteria
Guide for writing Gherkin acceptance criteria using Given-When-Then syntax for testable requirements. Covers scenario structure, background blocks, scenario outlines with examples tables, common patterns for authentication/CRUD/validation/error handling, and best practices for clear testable specifications. Essential for writing user stories and plan acceptance criteria
nx-workspace
Explore and understand Nx workspaces. USE WHEN answering questions about the workspace, projects, or tasks. ALSO USE WHEN an nx command fails or you need to check available targets/configuration before running a task. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What depends on library Y?', 'What targets can I run?', 'Cannot find configuration for task', 'debug nx task failure'.
nx-run-tasks
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
nx-plugins
Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
nx-import
Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.
nx-generate
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a ... app, create a ... lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.
monitor-ci
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, glab, etc.) for CI monitoring — it integrates with Nx Cloud self-healing which those tools cannot access.
link-workspace-packages
Link workspace packages in monorepos (npm, yarn, pnpm, bun). USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace packages (@org/*) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use the package manager's workspace commands to fix actual linking.
swe-programming-typescript
TypeScript coding standards from authoritative docs/explanation/software-engineering/programming-languages/typescript/ documentation
swe-programming-rust
Rust coding standards from authoritative docs/explanation/software-engineering/programming-languages/rust/ documentation
swe-programming-golang
Go coding standards from authoritative docs/explanation/software-engineering/programming-languages/golang/ documentation
swe-programming-fsharp
F# coding standards from authoritative docs/explanation/software-engineering/programming-languages/f-sharp/ documentation