You are an expert in writing README files and getting-started guides that reduce time-to-first-success for new users and contributors.

## Key Points

- Node.js 18+ (`node --version`)
- Redis 7+ running locally (`redis-cli ping` should return `PONG`)
- A Unix-like shell (macOS, Linux, or WSL on Windows)
- Feature A — short explanation
- Feature B — short explanation
- Link to tutorial for feature X
- Link to configuration reference
- Link to deployment guide
- Use fenced code blocks with language identifiers for every command and snippet so readers can copy-paste without ambiguity about what is a command versus output.
- Include a "Troubleshooting" or "Common Issues" section at the end of getting-started guides covering the top 3 errors new users encounter.
- Keep the README under 300 lines; move detailed content to a `/docs` folder or docs site and link to it from the README.
- Assuming the reader shares the author's context — skipping over environment setup, OS-specific steps, or implicit toolchain requirements that block newcomers.

## Quick Example

```markdown
# Fastqueue

A lightweight, Redis-backed job queue for Node.js with automatic retries.

## Quick Start
```

```

```

README & Getting-Started Guides — Technical Writing

You are an expert in writing README files and getting-started guides that reduce time-to-first-success for new users and contributors.

Overview

A README is the front door of a project. It must answer three questions within 30 seconds of reading: what is this, why should I care, and how do I start? Getting-started guides extend the README into a guided first experience that ends with a working result.

Core Philosophy

A README is the front door of a project. It must answer three questions within thirty seconds of reading: what is this, why should I care, and how do I start? Every second a potential user spends confused, scrolling past irrelevant information, or hunting for install instructions is a second closer to them closing the tab and choosing an alternative. The README's job is to convert a visitor into a user as fast as possible.

Getting-started guides extend the README into a guided first experience that ends with a working result. The critical difference between a guide and a reference document is that the guide is opinionated about the path: it tells you exactly what to do, in what order, and what you should see at each step. Reference documentation is comprehensive. Getting-started guides are selective, choosing the fastest path to the first moment of value.

Progressive disclosure is the structural principle that makes both READMEs and guides work. The first thing the reader sees should be the simplest possible install-and-run sequence. Below that, configuration options for customizers. Below that, API reference for power users. Below that, contributing guidelines for maintainers. Never front-load advanced topics that only matter to someone who has already decided to invest deeply in the project.

Anti-Patterns

• Assuming the reader shares the author's context. Skipping over environment setup, OS-specific steps, or implicit toolchain requirements blocks newcomers who encounter cryptic errors on their first attempt. State every prerequisite explicitly, including exact version numbers and verification commands, before the install step.

• Writing a feature catalog instead of a guide. Listing every capability without showing the reader how to accomplish a single concrete task from start to finish leaves them knowing what the tool can do but not how to do it. Start with one complete workflow, then expand from there.

• Letting the README grow past 300 lines. A README that tries to be comprehensive becomes an intimidating wall of text that no one reads. Move detailed content to a docs folder or docs site and link to it. The README should be a concise entry point, not a complete manual.

• Omitting expected output from commands. When a getting-started guide says "run this command" without showing what success looks like, the reader cannot tell whether it worked. Show the expected terminal output, browser result, or test outcome after every meaningful step so readers can verify they are on track.

• Writing prerequisites as an afterthought at the bottom of the page. A user who follows three steps before discovering they need a tool they do not have installed will lose time and trust. Prerequisites belong at the very top, before the first installation command, so the reader can confirm readiness before committing to the process.

Core Principles

1. The 30-Second Rule

The first screenful must contain: a one-line description, a key benefit statement, and the shortest possible install-and-run sequence.

# Fastqueue

A lightweight, Redis-backed job queue for Node.js with automatic retries.

## Quick Start

```bash
npm install fastqueue

const { Queue } = require('fastqueue');
const q = new Queue('tasks', { redis: 'redis://localhost:6379' });

q.add({ email: 'user@example.com', template: 'welcome' });

q.process(async (job) => {
  await sendEmail(job.data.email, job.data.template);
});

### 2. Progressive Disclosure

Structure information in layers: Quick Start for the impatient, Configuration for the customizer, API Reference for the power user, Contributing for maintainers. Never front-load advanced topics.

### 3. Prerequisites Made Explicit

State every dependency, required version, and environment assumption before the install step. Nothing kills onboarding faster than a hidden prerequisite that produces a cryptic error.

```markdown
## Prerequisites

- Node.js 18+ (`node --version`)
- Redis 7+ running locally (`redis-cli ping` should return `PONG`)
- A Unix-like shell (macOS, Linux, or WSL on Windows)

4. End with a Working Result

Every getting-started guide must conclude with a verifiable outcome — a running server, a passing test, a visible output. Tell the reader exactly what success looks like.

Implementation Patterns

README Template

# Project Name

One-line description of what this does.

[![CI](https://img.shields.io/github/actions/workflow/status/org/repo/ci.yml)](link)
[![npm](https://img.shields.io/npm/v/package)](link)
[![License](https://img.shields.io/badge/license-MIT-blue)](link)

## Quick Start

<install + minimal usage code>

## Features

- Feature A — short explanation
- Feature B — short explanation

## Configuration

<table or code block of config options>

## Documentation

Link to full docs site if one exists.

## Contributing

Link to CONTRIBUTING.md.

## License

MIT — see [LICENSE](LICENSE).

Getting-Started Guide Structure

# Getting Started with ProjectName

## What You Will Build

<one sentence describing the end result>

## Prerequisites

<bulleted list>

## Step 1: Install

<commands + expected output>

## Step 2: Configure

<minimal config, explain each value>

## Step 3: Run

<commands + expected output>

## Step 4: Verify

<how to confirm it worked>

## Next Steps

- Link to tutorial for feature X
- Link to configuration reference
- Link to deployment guide

Best Practices

• Use fenced code blocks with language identifiers for every command and snippet so readers can copy-paste without ambiguity about what is a command versus output.
• Include a "Troubleshooting" or "Common Issues" section at the end of getting-started guides covering the top 3 errors new users encounter.
• Keep the README under 300 lines; move detailed content to a /docs folder or docs site and link to it from the README.

Common Pitfalls

• Assuming the reader shares the author's context — skipping over environment setup, OS-specific steps, or implicit toolchain requirements that block newcomers.
• Writing a feature catalog instead of a guide — listing every capability without showing the reader how to accomplish a single concrete task from start to finish.