beta_reader_program v1.0.0

name: beta_reader_program description: Run a beta reader round with real readers on a complete manuscript: recruit and screen readers who match the book's target audience, send one locked packet with a cover letter, a running log, and an end of book form on a deadline, keep readers independent, then merge all returns into patterns, watch items, factual checks, and singles so multi reader evidence drives the revision and one reader's taste does not. Use when someone has a finished draft and asks to find beta readers, run a beta read, write beta reader questions, handle beta feedback, or decide which beta notes to act on. For chunk by chunk drop point testing during revision use reader panel testing; for writers exchanging craft feedback use a critique partner route, not this one.

Beta Reader Program

Purpose

Get a complete draft read the way buyers will read it, by readers who match the audience, and turn their returns into a revision order the author can defend. A beta round fails in two common ways. Friends and fellow writers read it kindly or as writers, so the round reports on the wrong audience. Or six readers return six piles of notes and the author cannot tell a real fault from one person's taste, so everything feels urgent and nothing gets decided. This skill fixes both. It recruits for audience fit with a screening test, runs the round on one locked version with dates and independence rules, asks questions that keep confusion, believability, and taste apart, and merges the returns by counting distinct readers per location and problem type.

Beta readers come after a complete, self revised draft. Alpha readers read during drafting, critique partners are fellow writers trading craft feedback, and editors work after the beta round. Beta readers are none of those. They read as readers and report what happened: where they were hooked, confused, bored, or unconvinced. Sensitivity readers and technical readers are separate paid checks on representation or accuracy, and a beta round never replaces them.

Use reader panel testing instead when the draft is still being revised and the question is the exact point a chapter loses people. Use this skill when the book is whole and the question is how the finished thing lands, end to end, with its real audience.

Workflow

1. Confirm the draft is ready to spend readers on. The manuscript is complete, self revised, and readable as a book, with most typos and known plot holes already fixed. Readers distracted by faults the author could have caught give shallow reports on everything else, and a good reader burned on a rough draft rarely agrees twice. Name the version, freeze it, and send that one version to every reader in the round.

1. Write the round plan before recruiting. One page: genre and age category, word count, the audience the readers must match, what the author most needs to learn (pick at most three questions, for example whether the middle sags, whether the ending pays off, whether a character earns sympathy), the packet dates, and the thank you or payment offered. A round with no stated questions returns general opinion, which merges into nothing.

1. Set the panel size for patterns, not for volume. Plan to finish with 3 to 8 readers who return usable feedback. Three is the minimum that can show a pattern, and past about ten the returns conflict more than they clarify and the merge takes longer than the revision. Recruit 5 to 10 to allow for dropouts, because some recruited readers will give thin feedback or none. If only 2 finish, label every output a 2 reader round. If only 1 finishes, it is a single read, not a round, and no pattern claim can be made from it.

1. Recruit where the target audience already gathers. Use the post in assets/recruiting-and-screening.md. Good sources are the author's own reader list, genre communities and book groups, reader forums for the category, and swap networks where the swap partner still matches the audience. Avoid close family, people who have watched the book being written, and the author's writing group as the core panel. They know too much, or they soften bad news. One writer friend may join, but their notes merge like everyone else's, with no extra weight.

1. Screen with specifics, not enthusiasm. Use the screening form in the same asset. Pass readers who name 2 to 3 recent books in the category with a specific reaction to each, and who commit to the deadline or name a realistic counter date. Fail vague answers with no titles and no date. For a borderline applicant, send chapter 1 only and judge the one paragraph reaction. Close screening in 5 to 7 days, assign IDs R1, R2, and so on, and keep names and emails in the recruiting note, apart from the feedback files.

1. Set a deadline scaled to length, with a midpoint check. Four weeks for a manuscript of about 88,000 words is a common working example. Shorter books can run 2 to 3 weeks, longer books 5 to 6. Put four dates in writing before the packet goes out: send date, midpoint check in, a reminder 72 hours before the deadline, and the deadline itself. Track each reader in a simple table with reader ID, date sent, deadline, and status: not started, reading, returned, stopped, or silent. At the midpoint, a silent reader gets one friendly check and an easy out, and the author decides then whether a replacement is needed, not after the deadline passes.

1. Send one packet: cover letter, manuscript, feedback form. Use assets/packet-cover-letter.md and assets/feedback-form.md. The letter states the job in plain terms: read as a buyer, no copyediting, note the chapter the moment something happens, do not discuss the book with the other readers, quitting is allowed and the stop point counts as a return. Send the questions with the manuscript, not after, so readers can log moments as they go. Questions about a specific late scene that would spoil it if read in advance go in a sealed second form sent on finishing.

1. Protect independence for the whole round. Readers do not see each other's notes, do not meet as a group, and are not told what earlier readers said. The author answers only logistics questions mid round (file problems, date problems) and gives no explanations of intent, no defence of a scene, and no hints about what other readers thought. An explained book can no longer be tested, and a reader who has heard the group view stops reporting their own.

1. Collect returns, including partial ones. A did not finish return with a stop chapter is a complete return for merge purposes. Chase a missing return once after the deadline, then close the round on the date stated and record the true denominator everywhere: readers recruited, packets sent, returns received. Never pad a thin round by splitting one reader's log, form, and messages into separate readers.

1. Transcribe every return into one feedback CSV. Columns: reader, location, category, summary. Categories and splitting rules are in references/merge-method.md: confusion, believability, pacing, character, boredom, emotion, factual, taste, praise. Location is the chapter, or chapter and scene where the form gives it. Split compound notes into one row per problem type. Keep the reader's own short wording in summary and add no fixes at this stage.

1. Merge by counting distinct readers. Run python3 ~/workspace/skills/beta-reader-program/bin/merge_feedback.py feedback.csv --out merge-report.md. The tool groups by location and category and sorts the round into patterns (3 or more distinct readers), watch items (2 readers), verify items (single reader factual notes, which get checked against the draft rather than voted on), protect items (praise from 2 or more readers at one location), and singles (1 reader, taste by default). Read the full method and a worked example in references/merge-method.md before deciding anything.

1. Decide every pattern, in writing, before editing prose. Use assets/decision-log.md. Order of work: comprehension patterns first, because a reader who lost the thread cannot judge anything downstream of the loss; then believability and pacing patterns; then watch items the author promotes after a cold read of the passage; then verified factual fixes. Taste patterns are real data about audience fit and still get a written decision, but a pattern of taste is a positioning choice, not a fault. Every pattern ends as fix, change differently, or stet, and every stet carries a one sentence reason. Record ripple effects: a fix that moves a reveal, a death, or a rule of the world gets a list of later chapters to recheck.

1. Fence the protect list before the first edit. Passages praised by 2 or more readers go on the protect list in the decision log. They do not get cut, shortened, or smoothed down to pay for a nearby fix. If a pattern fix truly has to touch a protected passage, write why in the log before touching it.

1. Validate big changes with a small second packet. Send heavily changed chapters to at least 2 readers, with at least 1 reader who has never seen any version of the book. A returning reader reads the fix through memory of the old draft and the author's intent, so only a fresh reader proves the confusion or drag is gone. Ask the same core questions for those chapters only, merge the small return the same way, and close a decision log item only when its pattern clears.

1. Close the round in writing. File the round plan, the tracker, the raw returns, the feedback CSV, the merge report, and the decision log together, each naming the manuscript version. Tell every reader, in two or three lines, what their feedback changed and thank them with whatever was promised. Readers who hear what their work did give straight answers in the next round. Readers who hear nothing give polite ones.

Output Contract

Deliver, in this order:

1. The round plan: audience definition, the at most three questions the round must answer, panel target, all four dates, and the thank you or payment terms.
2. The recruiting pack as sent: the post, the screening form with pass and fail calls per applicant, and the final panel list by reader ID only.
3. The packet as sent: cover letter, the named frozen manuscript version, and the feedback form, with any book type swaps from references/question-sets.md noted.
4. The merge report from bin/merge_feedback.py, with the true denominators on it: recruited, sent, returned, and did not finish counts.
5. The decision log: every pattern, watch, verify, and protect item with its decision, stet reasons, and ripple checks, plus the validation plan for changed chapters.
6. The close out note sent to readers, and the validation merge result for any chapter that went back out.

Operating Rules

• Never invent reader feedback, reader counts, or quotations. If 3 of 7 readers returned, every document says 3 of 7. Simulated readers with invented personas are not beta readers and their output is not a round.
• Never ask beta readers to copyedit, rewrite scenes, check facts for a living, or judge representation outside their own reading experience. Those jobs belong to editors, technical readers, and sensitivity readers, briefed and paid as experts.
• Never weight a note by who said it loudest, longest, or last. The merge counts distinct readers per location and type. One reader is one reader however many pages they wrote.
• Never treat a suggested fix as the finding. The finding is what happened in the reader: they stopped, skimmed, misread, or disbelieved, at a stated place. The author owns the fix, which may be a different change from the one the reader proposed, or a stet with a reason.
• Never show a reader another reader's feedback before all returns are in, and never argue with a return. A reader cannot be wrong about where they stopped or what they thought was true. They can only be one reader, which the thresholds already handle.
• Keep reader identities out of every merged and decided document. IDs only. Names and contact details live only in the recruiting note.
• State the payment and credit terms before the packet goes out, not after the return arrives. Volunteer rounds are normal for beta reading, and a promised copy, credit, gift, or payment is delivered whether or not the author liked the notes.
• For books aimed at children or teens, recruit through parents, teachers, and librarians. Do not approach minors directly.