A README that works

Writes the README from the real code, so a newcomer can start the project without asking anything.

Cuándo se usa

When publishing a repository, or when the current one no longer matches the project.

SKILL.md

# A README that works

A README is written by reading the project, not by imagining it. Before drafting,
look at the package scripts, the config file, the example environment variables
and how the thing is deployed.

## Structure

1. **What it is**, in two sentences, without marketing adjectives.
2. **How to run it**: the exact commands, in order, from a clean clone. If
   environment variables are needed, list all of them and where they come from.
3. **How it is organised**: the four or five folders that matter, one line each.
   Not a full directory tree.
4. **How it is deployed**, if that applies.
5. **How to contribute**, if the project is open.

## Rules

- Every command you write must have been run. A README with a failing command is
  worse than no README.
- No empty sections added out of habit.
- No screenshots that expire the moment the design changes.
- If something is not built, say it is not built, right where it belongs.

When you finish, say which parts were verified by running them and which are
assumed good without testing.