/reader-panel

name: reader-panel
description: This skill should be used when the user asks for a "simulated beta read", "reader panel", "persona read", "first read before my beta readers", "how would a genre reader react", "would a reader keep going", "pre-beta read", "mock beta readers", or wants structured persona reads of a chapter range before human readers see it. NOT for real reader feedback (use feedback-triage), a paid sensitivity or authenticity read (use editorial-review), or the agent's own line edit (use line-editing).

Reader Panel

Overview

Run structured persona reads of a chapter range and write each one as a feedback file in the shape `feedback-triage` already reads, so the existing triage flow takes over unchanged. The panel is a first read before human readers see the draft: it finds the problems a reader would trip on, so the human round spends its attention on what only people can tell you.

Every panel read is simulated. It is written by the agent, marked `source: simulated`, and never presented as feedback from a real reader.

Prerequisites

A story project (`story.md` in the root) with the chapters in range drafted. The `feedback-triage` skill must be available for the synthesis.

When to Use

• Before the first beta round, to catch the obvious problems cheaply
• After a revision, to check a fix landed before sending it to people
• When the user has no readers yet and wants a structured first read
• NOT as a substitute for human readers. A simulated round cannot close

a book as `ready` for submission or publication

• NOT for a sensitivity or authenticity read. The sensitivity persona

only flags passages for a paid human reader (use `editorial-review`)

Personas

Each persona has a reference file listing what it reads for, what it never comments on, and how it rates severity. Load only the personas in the panel.

| Persona | File id | Reads for | Reference | |---------|---------|-----------|-----------| | Target-genre reader | `genre-reader` | Does the book deliver the genre's promises? Pacing sags, missing beats, broken conventions | `references/genre-reader.md` | | Line editor | `line-editor` | Sentence-level craft: POV slips and head-hopping, filter words, repetition, unclear antecedents, voice drift | `references/line-editor.md` | | Sensitivity reader | `sensitivity-reader` | Portrayals that need a human sensitivity or authenticity reader. Flags, never clears | `references/sensitivity-reader.md` | | Continuity-minded reader | `continuity-reader` | Facts, names, objects, timeline, and what each character can know at this point | `references/continuity-reader.md` | | First-page reader | `first-page-reader` | Would they keep going? The opening page, each chapter's first lines, and the last line before they could put it down | `references/first-page-reader.md` |

Workflow

1. Scope the panel

1. Ask the user for the chapter range (default: every drafted chapter) and which personas to run (default: all five). Take genre, form, POV, and tense from the `story context` output in step 2 (its Story essentials section), not from `story.md`, whose Synopsis may describe the ending. The genre reader needs the genre. Take `language` only from the Language contract in that same `story context` output: it is no spoiler, and every persona reads the book as a reader of that language would. 2. Pick the round number: the next `N` that is free under `feedback/` and not yet the name of a tag or snapshot `panel-round-{N}` (`git tag --list 'panel-round-*'` and `story snapshot --list --path .` list them). A panel gets its own round. Never add simulated reads to a round of human readers, so the human synthesis stays independent. 3. Save the text the panel will cite under the name `panel-round-{N}`, so `feedback-triage` can map its labels to a later draft with `story compare` once the chapters change:

• **Git project:** work from the book's folder, the one that holds

`story.md` (`cd` there first), because `-- .` below means the current folder. Check that `.gitignore` lists `dist/` (add the line if it is missing), so earlier review copies stay out of the commit. Then run `git status --untracked-files=all -- .` and show the user what it lists: the copy is built from the working tree, but a tag points at the last commit, so uncommitted changes would make the two differ. Look through it for private files (a `.env`, keys or credentials, scanned documents): unless the user says to commit one, add it to `.gitignore` first. `.gitignore` does not untrack a file git already tracks, so also run `git ls-files -- .` and look for the same kinds of file: if one is listed, the commit below would include its changes, so stop and ask the user before committing. A tag holds only tracked files, so run `git ls-files --others --ignored --exclude-standard -- .` as well: if it lists a markdown file outside `dist/` and `.snapshots/`, or the cover or stylesheet `story.md` names, the build reads a file the tag would miss, so take a snapshot as below instead. Ask before committing and before tagging. With approval, commit the project folder only (skip the commit when the tree is already clean) and tag that commit:

     git add -A -- .
     git commit -m "Simulated reader panel round {N}" -- .
     git tag panel-round-{N}

If the user declines the commit, never tag the last commit over an uncommitted tree: take a snapshot as below, or stop. If `git tag` says the tag already exists, an earlier attempt saved this round: never move it; ask the user, or pick the next free `N`. Never push, and never move or delete a tag, without the user's approval.

• **Project without git, the user declined the commit, or an ignored

file the build reads:** take a snapshot with `story snapshot panel-round-{N} --path .`.

4