--- name: editorial-review description: This skill should be used when the user asks for a "sensitivity reader", "authenticity reader", "cultural review", "is this portrayal okay", "real people in my novel", "defamation", "can I use song lyrics", "epigraph permission", "permissions", "quote permission", "fair use", "AI disclosure", "do I need to disclose AI", "send to my editor", "editorial round", "Word file for my editor", "editor review copy", "co-author", "collaborate on a book", "shared world", "back up my book", "does this echo my source", "similarity check", "check overlap with my earlier books", or wants to run human editorial, ethics, permissions, or collaboration workflows around a story project. NOT for contracts or selling rights (use publishing), or reader feedback rounds and review copies for readers, including the GitHub review-copy setup (use feedback-triage). --- # Editorial Review ## Overview Run the workflows that involve people outside the agent: briefing and paying sensitivity and authenticity readers, a real-people and defamation-risk pass, permissions for quoted material, an AI-use disclosure statement, editorial rounds with human editors, and collaboration between co-authors. The skill prepares materials, tracks state in frontmatter, and flags risks. It does not give legal advice, it does not contact anyone, and it never records a permission, review, or disclosure the user has not confirmed. ## Prerequisites A story project with `story.md` in the root and drafted chapters. Git is needed for snapshot tags, `story compare --ref`, and the collaboration workflow; offer `git init` if the project has none. ## When to Use - A book portrays a culture, identity, disability, faith, trade, or experience the author does not share - Fiction features or resembles real, identifiable people or organisations - The manuscript quotes lyrics, poems, epigraphs, or other writers' prose - A passage may echo a source, an earlier book, or another writer too closely - The user needs an AI-use statement for a retailer, agent, or publisher - Sending the manuscript to a human editor, or taking their edits back - Two or more people write or maintain the same book or shared world - NOT for synthesising reader notes into decisions (use `feedback-triage`; this skill hands notes to it) - NOT for fact-checking real-world details (use `research`; this skill adds the review layer on top) - NOT for the agent's own prose edit (use `line-editing`) or structural revision (use `revision-continuity`) - NOT for query letters, synopses, or retailer copy (use `submission`) ## Workflow ### 1. Sensitivity and authenticity reads 1. Find what needs a read: characters, settings, and research notes that touch lived experience the author lacks. Mark the research notes that ground them by adding `cultural` to the note's `risk` list (add `medical`, `legal`, or others as they apply), or open one: ```shell story add research 'Deaf community in 1980s Glasgow' --accuracy must-be-accurate --method expert-review --risk cultural --used-in chapter-04 ``` 2. Prepare the brief with `references/sensitivity-reader-brief.md`: which chapters, which characters, specific questions, the author's research so far, deadline, and fee. Sensitivity reading is paid professional work; help the user budget and find readers, never suggest asking community members to work for free. 3. Build what the reader receives: `story build . --format docx` for readers who comment in Word, or `story build . --format html` for paragraph-anchored notes. A `reader-panel` round's sensitivity persona can point at passages to put in the brief, but it is not a sensitivity read: never record it in `reviewed-by` or treat it as clearing a portrayal. 4. Record the returned notes as a feedback round (`feedback/round-{N}/`) and synthesise them through the `feedback-triage` skill. When the reader's notes are incorporated, add them to the research note's `reviewed-by` (name or role, with their consent to be named). 5. `story validate .` warns when a note with any `risk` is used in a `final` or `complete` chapter and has no `reviewed-by`. ### 2. Real-people and defamation pass For fiction that uses real people, real organisations, or recognisable portraits, follow `references/real-people-and-permissions.md`: list every real or recognisable person, classify each portrayal, and flag the risky ones in a research note by adding `defamation` (or `legal`) to its `risk` list. Say plainly that this is a flagging exercise, not legal advice, and recommend a publishing lawyer's review before publication whenever a living person or a real organisation is shown doing something discreditable. ### 3. Permissions for quoted material 1. Find every quotation of someone else's work: epigraphs, lyrics, poems, extracts, and in-text quotes. Each epigraph or quoted page usually lives in `matter/`. 2. Record state in the matter file's frontmatter: `permission` (`not-needed`, `pending`, `granted`, `public-domain`), `rights-holder`, and `credit` (the exact credit line the rights-holder requires). 3. Apply the cautions in `references/real-people-and-permissions.md`: song lyrics almost always need permission, fair use is a narrow and uncertain defence, and public-domain status depends on country and date. Never set `granted` or `public-domain` without the user's confirmation and, for `granted`, the rights-holder's name. 4. `story validate .` warns when a matter page is `pending` and the story is `complete`, and when `granted` has no `rights-holder`. Whatever the status, `story export` and the builds leave a `pending` page out (the review copy too) and warn `permission-pending-left-out`, unless `--include-pending` is given. ### 4. Overlap with other text When the user worries that a passage echoes a source, an earlier book, or another writer too closely, compare the chapters with that text: ```shell story similarity . --against ../sources story similarity . --against ../book-one --min-words 12 ``` `--against` takes a file, a folder, or a git ref. Each run of shared words is a warning with both locations and the words. Report the result honestly: - Say what was compared and what was not. The check only sees the text passed to `--against`. It says nothing about other books, the web, or sources nobody gave it, so never tell the user a manuscript is "original", "clean", or "plagiarism-free" on its strength. - Shared text is not plagiarism. Stock phrases, a quotation the author meant, and the author's own recurring lines all share words. List each passage with its locations and let the user decide what it is. Never call a passage copied. - A passage quoted on purpose from another writer belongs in the permissions pass (section 3), not in a rewrite. - A passage that should not be there is rewritten by the author, or with the `line-editing` skill at the author's direction. Never paraphrase it quietly to make the match disappear. - Where a matching passage came from AI-assisted drafting, raise it when drafting or revisiting `ai-disclosure` (section 5): the statement describes how AI was used, and the similarity result neither proves nor disproves AI use. ### 5. AI-use disclosure 1. Ask the user how AI tools were used on this book: brainstorming, outlining, drafting prose, editing, research, cover or art, or translation, and roughly how much of the published text was generated rather than written or rewritten by the author. 2. Draft a short plain statement for `ai-disclosure` in `story.md`, for example: `Outlining and line-level editing suggestions used an AI assistant; all prose was written and revised by the author.` Use only what the user confirms; never minimise or inflate it. 3. Tell the user that disclosure expectations differ and change: some retailers ask at publication whether content is AI-generated or AI-assisted, many agents and publishers ask in submission guidelines or contracts, and some magazines do not accept AI-generated work. Ask the user to check the current terms of each retailer, agent, publisher, or market they submit to; do not quote policy text from memory. 4. `story build . --format metadata` includes the statement on the retailer metadata sheet. ### 6. Editorial rounds with a human editor Follow `references/editor-rounds.md`: 1. Snapshot and tag the draft sent (`sent-to-editor-1`). From the book's folder (the one with `story.md`), check that `.gitignore` lists `dist/`, show the user `git status --untracked-files=all -- .`, and ask about any private file it lists (a `.env`, keys, scans). With the user's approval, commit the book's folder only and tag it: `git add -A -- . && git commit -m "…" -- . && git tag sent-to-editor-1`. When the status lists nothing, run only the tag; if the user declines the commit, or it fails, never tag over the uncommitted tree. Then build the file the editor wants: `story build . --format docx` (Word with Track Changes) or `story build . --format shunn` for manuscript format. 2. When edits come back, the author accepts or rejects them in Word; the agent transfers the accepted text into the chapter markdown, chapter by chapter, never by a bulk script. Queries that change events go to `revision-continuity`; editorial letters go through `feedback-triage`. 3. Show how deep the round went: `story compare . --ref sent-to-editor-1`. ### 7. Review copies for non-technical readers For editors, sensitivity readers, or agents who never open a terminal, `story build . --format html` produces one file with a table of contents and a clickable paragraph label on every paragraph (`ch03-p12`), so comments can cite exact places in email, a doc, or an issue. To publish the copy on GitHub Pages with an issue form for notes, follow the GitHub review copy setup in step 1 of the `feedback-triage` workflow, which has the details. Even without that skill, warn first that a public Pages site makes the manuscript public unless the repository and Pages are private, confirm the visibility the user wants, and ask before creating any file in `.github/`. Collect the notes that come back into a feedback round and triage them with `feedback-triage`. Resolve labels from an older build with `story compare . --ref --anchor '