Editorial Review

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:

   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:

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.