Rewrite README.md and the other prose documents sentence by sentence, on Fable #219

Open
opened 2026-10-22 20:16:29 +02:00 by clawbot · 1 comment
Collaborator

This repo's README.md is 12391 words on next (22 October).

sneak, 22 October (chat), after smallwebwaf's README turned out to fail sentence by sentence: "just file issues on the repos about it, and specify that it has to be fable, and make the issues detailed - include your rules. we're not doing this work today (except on smallwebwaf)". What went wrong there, and the rules below, are on sneak/project-management#39 (comment).

Not today. This waits until the fleet restarts (25 October at the earliest) and the repo's manager has room. It is not urgent, but it comes before this repo's next release-candidate tag.

Who. This must be done by Fable: a genius-bar session (--agent genius-bar --model fable --effort xhigh, on a worker account) that wrote none of the documents. Opus workers do not do this unit.

What.

  1. Read README.md and every other prose document in the repo, such as SPEC.md, DESIGN.md and prose under docs/, sentence by sentence, as a newcomer would. Check each sentence against the rules below.
  2. Rewrite each document that fails from scratch. The old text is only the reference for what a reader needs covered; do not edit it in place. Where the old text is unclear or disagrees with the code on next, the code decides what is true and the spec explains the intent. List any disagreement in the PR body; do not settle it silently.
  3. A document that passes is left alone; say so on this issue.
  4. Leave out anything the code does not do, and describe nothing that is not built.

The rules, sentence by sentence. A sentence fails when a newcomer cannot parse it on first reading. It always fails when it:

  • runs past about 30 words, or chains a list of things with commas where a bulleted list belongs;
  • stacks clauses so the verb or the subject arrives late, for example "refuses a client a blocklist you name lists";
  • paraphrases where a plain common name exists, for example "the bans that broken rate limits lead to" instead of rate-limit bans;
  • narrates the project's own history or plan (milestones, stages, build order, issue links) in a document meant for users;
  • puts an exception or rare edge case before the main rule, or anywhere in the opening.

Also:

  • one idea per sentence; subject and verb early;
  • a false statement fails too, but an inaccurate sentence is fixed by writing a correct short sentence, never by adding qualifiers;
  • the README leads with what the program is, what it is for and how to use it; every setting goes in a reference section after that; development and testing come last;
  • plain words, no coined terms, no jargon a newcomer would not know, and any technical word defined on first use;
  • every identifier, flag, environment variable, path, command and file name in backticks; no markdown tables; no superlatives or praise;
  • read every sentence once more before committing, and rewrite any you would have to read twice.

Definition of done.

  • Every prose document in the repo passes the rules above, read sentence by sentence.
  • Every statement matches the code on next.
  • One PR into next for each rewritten document. The last of them ends its title with (closes #N), N being this issue.
  • Each PR passes an independent pr-reviewer applying agents/pr-reviewer.md step 4 to every sentence, before it is squash-merged.
  • make fmt applied, and script/cibuild green on a fresh clone.

Model: opus-5-5

This repo's `README.md` is 12391 words on `next` (22 October). sneak, 22 October (chat), after smallwebwaf's README turned out to fail sentence by sentence: "just file issues on the repos about it, and specify that it has to be fable, and make the issues detailed - include your rules. we're not doing this work today (except on smallwebwaf)". What went wrong there, and the rules below, are on https://git.eeqj.de/sneak/project-management/issues/39#issuecomment-154280. **Not today.** This waits until the fleet restarts (25 October at the earliest) and the repo's manager has room. It is not urgent, but it comes before this repo's next release-candidate tag. **Who.** This must be done by Fable: a genius-bar session (`--agent genius-bar --model fable --effort xhigh`, on a worker account) that wrote none of the documents. Opus workers do not do this unit. **What.** 1. Read `README.md` and every other prose document in the repo, such as `SPEC.md`, `DESIGN.md` and prose under `docs/`, sentence by sentence, as a newcomer would. Check each sentence against the rules below. 2. Rewrite each document that fails from scratch. The old text is only the reference for what a reader needs covered; do not edit it in place. Where the old text is unclear or disagrees with the code on `next`, the code decides what is true and the spec explains the intent. List any disagreement in the PR body; do not settle it silently. 3. A document that passes is left alone; say so on this issue. 4. Leave out anything the code does not do, and describe nothing that is not built. **The rules, sentence by sentence.** A sentence fails when a newcomer cannot parse it on first reading. It always fails when it: - runs past about 30 words, or chains a list of things with commas where a bulleted list belongs; - stacks clauses so the verb or the subject arrives late, for example "refuses a client a blocklist you name lists"; - paraphrases where a plain common name exists, for example "the bans that broken rate limits lead to" instead of rate-limit bans; - narrates the project's own history or plan (milestones, stages, build order, issue links) in a document meant for users; - puts an exception or rare edge case before the main rule, or anywhere in the opening. Also: - one idea per sentence; subject and verb early; - a false statement fails too, but an inaccurate sentence is fixed by writing a correct short sentence, never by adding qualifiers; - the README leads with what the program is, what it is for and how to use it; every setting goes in a reference section after that; development and testing come last; - plain words, no coined terms, no jargon a newcomer would not know, and any technical word defined on first use; - every identifier, flag, environment variable, path, command and file name in backticks; no markdown tables; no superlatives or praise; - read every sentence once more before committing, and rewrite any you would have to read twice. **Definition of done.** - Every prose document in the repo passes the rules above, read sentence by sentence. - Every statement matches the code on `next`. - One PR into `next` for each rewritten document. The last of them ends its title with (closes #N), N being this issue. - Each PR passes an independent pr-reviewer applying `agents/pr-reviewer.md` step 4 to every sentence, before it is squash-merged. - `make fmt` applied, and `script/cibuild` green on a fresh clone. Model: opus-5-5
Author
Collaborator

Plan.

Scope. README.md only. REPO_POLICIES.md is copied from sneak/prompts and changes only there. TODO.md is the work log the repository workflow requires, not a document for users, so it stays as it is.

Who. One genius-bar session on Fable, on a worker account, that wrote none of the README. It starts once #223 is merged, so the README describes get, get-thumb, files and the thumbnail helper as they now are.

How. The session reads the README sentence by sentence against the rules in this issue, and checks every statement against the code on next. It then writes the README again from scratch, using the old text only as a list of what a reader needs. The sections REPO_POLICIES.md requires stay:

  • a first line naming the project, its purpose, its category, its licence and its author;
  • Getting Started, with a copy-pasteable block;
  • Entrypoints, opening with the Scripts to Rule Them All link;
  • Rationale, Design, TODO, License and Author.

Every place where the old text and the code disagree is listed in the PR body.

Gates. One PR into next, its title ending with (closes #219). An independent pr-reviewer applies step 4 of agents/pr-reviewer.md to every sentence before it is squash-merged. Before the release-candidate tag, a second fresh Fable session that wrote none of it reads the merged README whole and passes it against the same rules.

Model: opus-5-5

Plan. **Scope.** `README.md` only. `REPO_POLICIES.md` is copied from sneak/prompts and changes only there. `TODO.md` is the work log the repository workflow requires, not a document for users, so it stays as it is. **Who.** One genius-bar session on Fable, on a worker account, that wrote none of the README. It starts once https://git.eeqj.de/sneak/quak/issues/223 is merged, so the README describes `get`, `get-thumb`, `files` and the thumbnail helper as they now are. **How.** The session reads the README sentence by sentence against the rules in this issue, and checks every statement against the code on `next`. It then writes the README again from scratch, using the old text only as a list of what a reader needs. The sections `REPO_POLICIES.md` requires stay: - a first line naming the project, its purpose, its category, its licence and its author; - Getting Started, with a copy-pasteable block; - Entrypoints, opening with the Scripts to Rule Them All link; - Rationale, Design, TODO, License and Author. Every place where the old text and the code disagree is listed in the PR body. **Gates.** One PR into `next`, its title ending with (closes #219). An independent pr-reviewer applies step 4 of `agents/pr-reviewer.md` to every sentence before it is squash-merged. Before the release-candidate tag, a second fresh Fable session that wrote none of it reads the merged README whole and passes it against the same rules. Model: opus-5-5
clawbot self-assigned this 2026-10-26 10:44:04 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/quak#219