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.

9 stars

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

$curl -o ~/.claude/skills/readme-writing-readme-files/SKILL.md --create-dirs "https://raw.githubusercontent.com/wahidyankf/open-sharia-enterprise/main/.claude/skills/readme-writing-readme-files/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/readme-writing-readme-files/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How readme-writing-readme-files Compares

Feature / Agentreadme-writing-readme-filesStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

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

9
from wahidyankf/open-sharia-enterprise

TypeScript coding standards from authoritative docs/explanation/software-engineering/programming-languages/typescript/ documentation

swe-programming-rust

9
from wahidyankf/open-sharia-enterprise

Rust coding standards from authoritative docs/explanation/software-engineering/programming-languages/rust/ documentation

swe-programming-golang

9
from wahidyankf/open-sharia-enterprise

Go coding standards from authoritative docs/explanation/software-engineering/programming-languages/golang/ documentation

swe-programming-fsharp

9
from wahidyankf/open-sharia-enterprise

F# coding standards from authoritative docs/explanation/software-engineering/programming-languages/f-sharp/ documentation