{"slug":"danjdewhurst-feedback-triage","name":"feedback-triage","description":"This skill should be used when the user asks to \"process beta reader feedback\", \"alpha reader feedback\", \"feedback round\", \"synthesize reader feedback\", \"reader notes\", \"beta feedback\", \"reader readiness check\", \"review copy\", \"send the draft to readers\", \"share with readers who don't use GitHub\", \"triage the reader panel\", or wants to collect, reconcile, and act on external reader feedback for a story project. NOT for rounds with a professional editor (use editorial-review), or for checking a manuscript is ready to query or publish (use submission or publishing).","long_description":"---\nname: feedback-triage\ndescription: This skill should be used when the user asks to \"process beta reader feedback\", \"alpha reader feedback\", \"feedback round\", \"synthesize reader feedback\", \"reader notes\", \"beta feedback\", \"reader readiness check\", \"review copy\", \"send the draft to readers\", \"share with readers who don't use GitHub\", \"triage the reader panel\", or wants to collect, reconcile, and act on external reader feedback for a story project. NOT for rounds with a professional editor (use editorial-review), or for checking a manuscript is ready to query or publish (use submission or publishing).\n---\n\n# Feedback Triage\n\n## Overview\n\nProcess alpha/beta reader feedback as a structured, reconcilable workflow:\ncollect per-reader feedback files, hold all revision until the round is\ncomplete, synthesize convergent/divergent/single-reader findings into a\ndecision record with a readiness verdict, and hand a concrete revision plan\nto the `revision-continuity` skill.\n\n## Prerequisites\n\nA story project with at least one drafted chapter (or a complete draft) that\nreaders have read. Verify `story.md` exists in the project root.\n\n## When to Use\n\n- Starting a feedback round (recruiting readers, sending chapters out)\n- Recording feedback as it arrives\n- Synthesizing a completed round into decisions\n- NOT for revising the manuscript (use `revision-continuity` with the\n synthesis's revision plan)\n- NOT for the agent's own critique of the draft (use `revision-continuity`\n audits; reader feedback is external input)\n- NOT for producing simulated persona reads (use `reader-panel`; this\n skill synthesises the round it writes)\n\n## Workflow\n\n### 1. Set up the round\n\n1. Decide the round scope: which chapters readers get (`chapters-read` range)\n and how many readers (2–4 per round is typical; one reader is a data\n point, not a round).\n2. Create the round folder: `feedback/round-{N}/`.\n3. Give readers a review copy they can open without a terminal:\n\n ```shell\n git tag feedback-round-{N}\n story build . --format html --stamp feedback-round-{N}\n ```\n\n Tag the commit you share (with the user's approval) so the round's text\n can be rebuilt later. The single-file HTML copy in `dist/` has a table of\n contents, the build stamp at the top, and a paragraph label beside every\n paragraph (`ch03-p12` is chapter 3, paragraph 12). A label is the\n chapter and the paragraph's position in that build, not a permanent id:\n any earlier edit in the chapter renumbers it, and `story move` changes\n its chapter part. Ask readers to cite the label, the build stamp, and the\n paragraph's first few words with each note. For projects on GitHub, the\n `templates/github/review-copy.yml` workflow publishes the HTML copy to\n GitHub Pages on each push to main, stamped with the date and short\n commit, with a **Note** link beside every label (`--note-url`) that\n opens the issue form prefilled with the label, build, and first words, and `templates/github/ISSUE_TEMPLATE/manuscript-note.yml` gives\n readers an issue form with label, build, first few words, note type\n (typo or wording, confusing, continuity, pacing, character, sensitivity\n or authenticity, loved this, other), how much it affected their reading,\n and the note. Create a\n `manuscript-note` label first; GitHub only applies existing labels. Copy them into the story\n repository's `.github/workflows/` and `.github/ISSUE_TEMPLATE/` only with\n the user's approval.\n4. For each expected reader, create a stub file from\n `references/feedback-template.md` at\n `feedback/round-{N}/{reader-kebab}.md` with frontmatter filled in and the\n body sections empty. The stub list is the round's checklist.\n\n### 2. Collect feedback (the discipline)\n\n1. As each reader's notes arrive, record them in their file using the\n template. Quote or closely paraphrase; do not editorialize yet. Keep\n each note's paragraph anchor (`ch03-p12`) in its **Where** line; convert chapter\n or page references from other formats to anchors when the location is\n unambiguous. For notes filed through the issue form, fetch them with\n `gh issue list --label manuscript-note --state open --json number,title,body,author`\n and map the form's \"How much did it affect your reading?\" answer to the\n template's severity: `Made me want to stop reading` is `major` (`blocking`\n when several readers stopped at the same place), `Pulled me out for a\n moment` is `minor`, `Barely noticed` is `nit`, and no answer is left\n blank. A `Typo or wording` note is a `nit` unless the reader says more.\n3. **Map old labels to the current text.** When a note's build is older\n than the manuscript, its label may point at a different paragraph now.\n Resolve every label from the round in one run against the tag (or the\n short commit in the note's build stamp):\n\n ```shell\n story compare . --ref feedback-round-{N} --anchor ch03-p12 --anchor ch07-p4\n ```\n\n Each line gives the current label: `(text unchanged)`, or `(edited, NN%\n similar)` when the paragraph was revised (check it is the one the\n reader meant). `not found in the current text (\"…\")` means the\n paragraph was cut or rewritten past recognition: search the chapter for\n the reader's quoted words, or the words shown, and mark the note\n ambiguous if nothing matches. `no such label` means the label never\n existed in that build: check the note's build and the reader's typing.\n Record the current label in the **Where** line, keeping the reader's\n original label in brackets. Sensitivity and authenticity reads use the same file shape;\n see the `editorial-review` skill for commissioning them.\n4. Run the **canon check** on each problem note: verified against the bible,\n contradicts canon (usually a setup problem — note the canon file), or\n outside canon scope. Record the result in the file.\n5. **Do NOT revise until all feedback for the round is in.** Revising on\n partial feedback optimizes for the first reader and invalidates the\n others' reads. If a reader is late, either wait or formally close the\n round without them (note it in the synthesis) — never silently proceed\n on a partial set.\n\n### 3. Synthesize\n\nOnly when every expected reader file is collected. If the round's files\ncarry `source: simulated`, it is a panel round from the `reader-panel`\nskill: follow \"Simulated rounds\" below as well.\n\n1. Read all reader files for the round.\n2. Sort every finding into exactly one category:\n - **Convergent** — ≥2 readers agree independently. Strongest signal;\n becomes a revision item by default.\n - **Divergent** — readers disagree. Adjudicate: check both sides against\n canon and premise, record which side wins and why.\n - **Single-reader** — one reader only. Weigh by specificity:\n specific + canon-verifiable → investigate or accept; vague +\n taste-based → usually decline.\n - **Declined-with-reason** — explicitly rejected, with a recorded reason\n referencing canon, premise, genre contract, or craft principle.\n3. Write `feedback/round-{N}/synthesis.md` using\n `references/synthesis-template.md`, including the frontmatter readiness\n verdict: `ready` | `needs-revision` | `not-ready`.\n4. Build the numbered revision plan with concrete file targets.\n\n### 4. Hand off the revision plan\n\n1. Present the synthesis summary and readiness verdict to the user.\n2. If the verdict is `needs-revision` or `not-ready`, hand the revision\n plan to the `revision-continuity` skill for execution. The synthesis is\n the input; revision-continuity owns the edits.\n3. If the verdict is `ready`, the round is closed — proceed to the next\n round, the next drafting stage, export, or the `submission` skill.\n\n## Simulated rounds\n\nThe `reader-panel` skill writes persona reads in this skill's file shape,\nwith `source: simulated` and `persona` in the frontmatter. A file without\n`source`, or with `source: human`, is a human reader's. Synthesise a\npanel round as usual, with these differences:\n\n- **Label it.** Set `source: simulated` in the synthesis frontmatter and\n start the readiness line with \"Simulated round:\". Refer to the files by\n persona (\"the line-editor persona\"), never as readers or beta readers.\n- **Personas are not independent.** Several personas run by one model\n agreeing is one signal, not convergence. Sort every simulated finding as\n single-reader or declined-with-reason, weighed by how specific and checkable it is: a quoted POV\n slip or a contradiction with both sides cited is worth acting on; a\n taste note is usually declined.\n- **Check before acting.** Personas leave the canon check to you (they\n cannot read past their range), so run it here, and confirm each\n simulated problem in the text before it enters the revision plan. A note the text does not bear out\n is declined with the reason \"not borne out by the text\".\n- **What `ready` means.** A simulated round's `ready` means ready for\n human readers, nothing more. It never closes a book for submission or\n publication; hand off to a human round, not to `submission`.\n- **Never mix rounds.** Simulated and human reads go in separate rounds.\n If a round holds both, move the simulated files to their own round\n before synthesising. When a later human round repeats a simulated\n finding, the human readers' notes carry it; the earlier panel adds no\n weight.\n- The sensitivity persona only flags passages for a human reader. Its\n notes become items for an `editorial-review` brief, never a finding that\n a portrayal is fine.\n\n## Conventions\n\n- Feedback lives under `feedback/round-{N}/`; `{N}` is a plain integer\n (`round-1`, `round-2`).\n- Reader files use kebab-case reader ids: `feedback/round-1/maria-chen.md`.\n- Locations cite paragraph labels from `story build --format html`\n (`ch03-p12`) where available. Labels are paragraph positions in one\n build, so tag and stamp each round's build, rebuild and resend the review\n copy between rounds, and map an old label to the current text with\n `story compare . --ref --anchor