developmental-editor

Files (9)

• SKILL.md
• openai.yaml · agents/
• evals.json · evals/
• 01-salt-house-notes.md · evals/files/
• 01-salt-house.md · evals/files/
• 02-last-pick.md · evals/files/
• 03-fallboard-notes.md · evals/files/
• 03-fallboard.md · evals/files/
• 04-contusion.md · evals/files/

SKILL.md (first lines)

# Developmental editor

Use for a developmental edit or first-reader pass on fiction, not a line edit or copyedit unless the author asks for one. Before reviewing, read and follow [the editorial contract](../references/editorial-contract.md) and [review conduct](../references/review-conduct.md). They cover reading order, spoiler boundaries, protected style, and proposals versus canon; this skill adds what is specific to developmental and first-reader work.

## Choose the mode and scope

- **Developmental edit:** diagnose what the draft achieves and what it doesn't, and propose directions.
- **First-reader pass:** report one reader's experience up to a spoiler boundary. No diagnoses or fixes unless the author separately asks.

Default to a developmental edit when the request doesn't say. Choose delivery separately from the mode.

As you read, keep a reader ledger: the questions the reader is tracking, the promises and setups the text makes, and the expectations it builds, each with where it opens and where it closes. In a developmental edit, check the ledger at the end for dropped questions, unpaid setups, and payoffs with no setup. In a first-reader pass, it is the raw material for reactions.

When the scope is part of a longer work, say what it can't show, such as arcs and payoffs, and state your assumptions about the unread material. Don't flag missing setup or unresolved threads as flaws when unread chapters could account for them; raise them as Questions instead.

## Developmental edit

### Read the story before the notes

Read the whole scope before consulting author notes, story-bible entries, or other private intentions. Then write the story as read: three or four sentences on what the draft appears to be, covering its promise to the reader, the central question it holds open, what the protagonist wants and what stands in the way, and the effect it seems to be going for. This is the baseline every note is judged against.

Then compare it with any author notes or reference material in scope. The gaps between intent and execution are often the most useful findings. Without author notes, don't ask for intent up front; the story as read lets the author see any gap for themselves. For a large story bible, use [story-bible](../story-bible/SKILL.md) to assemble a context packet for the scope rather than reading the whole bible.

### Read for causes, not impressions

Every note names the reader effect and the structural cause that produces it. "The middle drags" is an impression; "the question of who took the money is answered in scene 2 and nothing replaces it, so the reader has nothing to track until the end" is a note. Look for causes like these:

- **Tension:** the question the reader is tracking is answered early, never clearly posed, or dropped without a new one taking over; stakes are named but never shown to cost anything.
- **Motivation:** a choice the reader hasn't been given grounds for; a want that is stated but never tested; a character acting for the plot's convenience rather than from what the reader knows of them.
- **Agency:** the protagonist only reacts through the climax; the resolution arrives from outside, through coincidence, rescue, or someone else's choice; the decision the story turns on happens off the page.
- **Scene function:** nothing is different at the end of the scene: not the situation, what anyone knows, a relationship, or the reader's understanding; two scenes do the same job.
- **Setup and payoff:** a setup the story never pays off; a payoff with no setup, so it reads as convenience; a payoff signaled so heavily it arrives as confirmation.
- **Emotional turns:** a turn that happens between scenes; a feeling the reader is asked to share before the text has given them grounds for it.
- **Structure and reveal order:** the opening promises one kind of story and the ending delivers another; a reveal withheld until curiosity turns into confusion.
- **Ambiguity:** productive when the text gives the reader enough to hold more than one reading; confusing when it doesn't give enough for any. Flag only the second.

### Avoid default developmental habits

- Don't measure the draft against three-act structure, beat sheets, or genre templates unless the author asks. Measure it against the story as read and the author's stated aims.
- Don't treat open endings, unanswered questions, or unexplained backstory as flaws by default. Check whether the reader has enough to hold them.
- Don't ask for more explanation, backstory, or interiority by reflex. Say what the reader is missing and what that costs.
- Don't push characters toward likability or redemption. Unsympathetic isn't the same as unconvincing.
- Don't fix a focus problem by adding scenes, subplots, or characters.
- Don't call a section slow without naming what the reader is waiting for.

### Give directions, not plot

A direction names what the reader needs and roughly where: "the reader needs a reason she stays before the ferry scene." Don't invent the event, scene, or dialogue that supplies it ("have her find the letter in chapter 2") unless the author asks. For a major issue, offer two or three distinct directions and what each would change, so the choice stays with the author.

### Label each note

- **Premise:** the story's underlying promise, stakes, or central situation.
- **Execution:** how the draft delivers that promise on the page, including gaps between the author's stated intent and the draft.
- **Continuity:** a conflict in chronology, character knowledge, or cause and effect, identified without inventing canon.
- **Taste:** a preference the author may reasonably decline.
- **Protect:** a choice whose effect revision could easily lose. Name the cause of the effect, as with any other note; without it, the note is praise, not editing.
- **Question:** something only the author can answer, where the answer changes the notes.

Mark the few issues most likely to improve the draft as major and leave the rest unmarked. For example:

> **[Dev]** Execution (major): "It was Carys who'd taken the money." The story's question is who took it, and the answer arrives in scene 2, before the reader has a second suspect. The remaining scenes wait for Elin to learn what the reader already knows. Directions: hold the answer until Elin's suspicion has somewhere else to go, or keep the early reveal and give the reader a new question by the end of scene 2. The lease in scene 4 is resolved just as early.

> **[Dev]** Protect: the funeral opens the story and the accident closes it. Because the reader knows from the first page that June dies, every scene with her plays as dread rather than suspense, and the final scene lands as the thing everyone has been avoiding. Chronological order would trade that for a twist.

## First-reader pass

Read in order through the stated boundary only. Don't consult author notes, story-bible entries, or anything past the boundary.

Prefer a fresh reading: a subagent or new session given only the text up to the boundary and no notes. Cut the text at the boundary mechanically, by heading or line number, without reading past it yourself; handing over the whole file with an instruction to stop isn't a fresh reading. If a fresh reading isn't available, or your context already holds spoilers or private intentions, say so without repeating the spoilers, don't claim an independent reading, and label the response a reconstruction with prior knowledge.

Record reactions where they occur: feelings, expectations, questions, surprises, confusion, and changes in interpretation. Don't revise earlier reactions in hindsight; a later reaction can say that an earlier guess changed. Label each one Reaction:

> **[Dev]** Reaction: "The dog wouldn't go past the gate." First moment I'm uneasy rather than curious. Now I expect whatever is in the field to matter more than the argument with Sam.

Close with a brief impression of the whole reading, not a revision plan.

## Deliver the feedback

Deliver both modes as [review conduct](../references/review-conduct.md) describes. Start each inline comment with bold `[Dev]` and the note's label, as in the examples. `[Dev]` identifies the editor; the label identifies the kind of note.

Each developmental note gives a short quote or precise location, the reader effect and its cause, and a direction for issues. Anchor a broader pattern on one representative passage and list the other locations there instead of repeating the note. Prose-level issues belong to a line edit; mention any pattern in one line of the summary instead of commenting on it.

In the closing summary, also include what applies:

- whether a first reading was fresh or a reconstruction;
- the story as read;
- the major issues in priority order, one line each, pointing to their comments;
- findings with no useful inline anchor;
- prose patterns worth a line-edit pass.

When the author chooses chat delivery or asks for an editorial letter, give everything in chat instead: the story as read, major issues with evidence and directions, then other notes, choices to protect, and questions.

From atrnh/skills, MIT.

More from atrnh/skills